3 strategies dealing with blocker defect
Poruchy blokátorov zvyšujú množstvo dramatických udalostí v inak bežných testovacích dňoch.
V tomto článku by som chcel priblížiť niektoré kroky, ktoré môže tester podniknúť pri svojich rokovaniach.
Budem predpokladať, že naši drahí čitatelia už hlboko chápu závažnosť a prioritu porúch. Potrebujete rýchlu rekapituláciu? Pozri na toto.
Teraz to vždy znamená, že ak narazíme na problém s blokovaním, musíme úplne prestať testovať?
V niektorých prípadoch „áno“, ale možno nie vždy. Môžu sa vyskytnúť prípady, keď je možná nejaká testovacia aktivita.
obrázok zdroj
Ďalej uvádzam niekoľko situácií, ktoré som zažil počas svojej kariéry testera. Som pevne presvedčený, že na uľahčenie tohto procesu je potrebné dodržať kroky uvedené nižšie (neskôr konsolidované do vývojového diagramu).
Poďme priamo do toho.
Kroky, ktoré by ste mali podniknúť, keď narazíte na poruchu blokátora
Krok 1: Keď narazíte na problém, investujte čas na nájdenie hlavnej príčiny.
Som pevne presvedčený, že ako tester naša práca nekončí hlásenie závad . Ak to čas dovoľuje, mali by sme preskúmať, čo mohlo spôsobiť problém. Možno nebudeme vždy schopní poukázať na presnú problémovú oblasť, ale snažte sa problém vyriešiť čo najviac. Rovnaké podrobnosti je možné v defekte aktualizovať ako ďalšie komentáre.
Vo svojich projektoch som toho urobil veľa a vyústilo to do rýchlej opravy. Výhody analýzy hlavných príčin sú:
- Ako pridaná hodnota môže vývojárovi určite poskytnúť lepšie smerovanie pri opravovaní chýb.
- Tester QA tiež dokáže rozpoznať, či je tento problém vytvorený samostatne (problémy so zadaním údajov alebo s ľudským využitím), a ak áno, môže byť opravený samotným testerom. Keď sa takéto chyby nahlásia vývojárom bez toho, aby sme ich skontrolovali z konca QA, sú považované za nevydanie a mohlo by to viesť k negatívnej povesti testera.
Navrhujem teda, aby sme pred prihlásením chyby vždy dvakrát skontrolovali náš koniec.
Tu uvádzam niekoľko príkladov z mojich projektov v reálnom čase, ktoré posilnia vyššie uvedené body:
Pracoval som na projekte, kde by naše testovanie vyžadovalo, aby sme súbor presunuli na určené miesto. Premenujte ho tak, aby zodpovedal názvu v konfigurácii. Naplánovaná úloha by vyzdvihla dátový súbor a načítala údaje do systému. Potom by sme overili údaje v databáze a klientskom rozhraní.
1 nf 2 nf 3 nf
Zvykli sme sa stretávať s problémami, kde by úloha bežala, ale dáta by sa nenačítali, a po prešetrení to bolo preto, že tester nezmenil názov, keď súbor umiestnil na miesto.
Toto bolo pre nás blokovanie, ale nie niečo, čo si vyžadovalo pozornosť vývojárov. Museli sme venovať pozornosť detailom a vyhnúť sa takým malým chybám.
Nasleduje niekoľko bežných kategórií, základné príčiny a nápravné opatrenia:
# 1) Súbor hostiteľov Problém - Povedzme, váš súbor hostiteľov má parametre, ktoré sú nesprávne a spôsobujú problém. V takom prípade môžete buď aktualizovať hostiteľský súbor sami, alebo vyhľadať pomoc od niekoho, kto má prístup k aktualizácii a pokračovať v vykonaní testu.
Mal by sa zvýšiť nedostatok toho istého, aby vývojári prešetrili, ale s riešením tohto problému bude funkčné testovanie pokračovať.
Poznámka: Skôr ako tak urobíte, sa poraďte so svojimi projektovými tímami, či je v poriadku, aby tím QA vykonal tieto zmeny.
# 2) Konfigurácia - Často sme zaznamenali problémy s konfiguráciou, ako napríklad neukazovanie na správne prostredie alebo iné problémy s nastavením, ktoré blokujú problémy. Aj v takýchto prípadoch môžu testeri vykonať zmeny a pokračovať v testovaní.
Poznámka: Skôr ako to urobíte, vyhľadajte povolenie.
najlepšia bezplatná aplikácia na stiahnutie mp3 pre Android
# 3) Vydanie kódu - Ak máte pocit, že problém je spôsobený kódom, testéri nemôžu nič moc urobiť. Zaznamenajte chybu blokátora a počkajte, kým oprava bude pokračovať v testovaní.
# 4) Problém s nasadením - Zlé nasadenie je ďalšou častou príčinou problémov s blokovaním a tieto môžu byť zachytené počas testu prípustnosti. Aj tu by sa malo testovanie okamžite zastaviť, kým sa neprijme nové zostavenie.
# 5) Prostredie nadol - Ak je prostredie vypnuté, povedzme, že sa databáza nepripojuje k serveru alebo URL nefunguje v prípade webových stránok; testéri v týchto prípadoch nemôžu urobiť nič iné, iba nahlásiť poruchu a počkať, kým bude systém v prevádzke.
Ak teda existuje riešenie, použite ho na pokračovanie v testovaní. Jediným spôsobom, ako zistiť, či dané riešenie existuje, je preskúmanie hlavnej príčiny. Častejšie môže byť alternatíva.
Krok 2: Pri vyšetrovaní hlavnej príčiny je veľmi ľahké spadnúť do nekonečnej slučky. Uistite sa teda, že to nie je náročné na celý deň a všetko úsilie.
Tu je niekoľko rád:
- Nájdite rovnováhu a rozpoznajte bod zastavenia, keď sa tam dostanete.
- Skúsenosti a odborné znalosti testera sú rozhodujúce pre úspešný RCA. V prípade potreby je však dobré zapojiť tím a vedenie tímu.
- Ak máte pocit, že RCA je časovo náročná, najskôr problém okamžite nahláste a poskytnite čo najviac informácií. Screenshot je vždy užitočný.
- V prípade potreby pokračujte. Zašlite e-mail správcovi alebo vývojárovi, aby ste upozornili na kritický problém.
- Po upozornení potrebných strán pokračujte v riešení problémov.
Dôvod, prečo by sa mali chyby blokátora hlásiť okamžite:
- Vedenie by malo byť informované o všetkých prestojoch, ak sa jedná o chybu typu showstopper. Tieto informácie musia byť odovzdané klientovi a môžu tiež vyžadovať aktualizáciu plánu projektu (časové osi QA), zmenu dodávok atď.
- Akékoľvek oneskorenie dodávok QA musí byť doložené dôkazom. Vždy je lepšie komunikovať čo najskôr, namiesto čakania na koniec dňa.
Krok č: Teraz prejdeme k poslednému kroku, keďže sme dokončili analýzu problému a jeho komunikáciu, čo bude ďalej?
- Ak problém blokuje prístup do jednej funkčnej oblasti, skontrolujte, či to nemá vplyv na ďalšie oblasti
- Ak je klientska aplikácia nefunkčná, skontrolujte, či je možné pokračovať v testovaní backendu, middlewaru alebo databázy.
- Ak sa nemôže uskutočniť žiadna aktivita vykonania testu, skúste to pracovať na nejakej dokumentácii súvisiace s vaším projektom.
- Môžete tiež vyskúšať určiť oblasti pre automatizáciu ak ručne opakujete veľa práce. Automatizácia nemusí vždy používať nástroj. Povedzme, generovanie prehľadov je pre vás monotónna úloha, to je oblasť, ktorú je možné automatizovať jednoduchými makrami programu Excel a podobne.
- Venujte čas poznatkom o nástrojoch otvoreného zdroja, ktoré je možné implementovať do vášho projektu
- Posledný ale nie najmenší , pracovať na inováciách, mantre, ktorá v súčasnosti vládne svetu!
Nakoniec , vývojový diagram, ktorý sumarizuje celú diskusiu!
Vývojový diagram: Kroky na odstránenie chyby blokátora
Autor : Tento úžasný článok píše člen tímu STH Priya R.
Aké kroky podniknete, keď narazíte na poruchu blokátora?
Odporúčané čítanie
- Čo je to technika testovania na základe chýb?
- Čo je životný cyklus chyby / chyby v testovaní softvéru? Výukový program pre poruchu životného cyklu
- Proces správy defektov: Ako efektívne riadiť defekty
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Ukážka hlásenia chyby pre webové a produktové aplikácie
- Ako reprodukovať nereprodukovateľný nedostatok a dosiahnuť, aby vaše testovacie úsilie stálo za to
- Testovanie softvéru je predovšetkým o nápadoch (a o tom, ako ich generovať)
- 7 princípov testovania softvéru: zhlukovanie defektov a Paretov princíp