Čo je Bug?
Chyba je dôsledkom / výsledkom chyby kódovania.
Porucha v testovaní softvéru
Defekt v testovanie softvéru je variácia alebo odchýlka softvérové aplikácie z požiadaviek koncového užívateľa alebo pôvodnými požiadavkami podnikateľov. Softvérová chyba je chyba v kódovaní, ktorá spôsobuje nesprávne alebo neočakávané výsledky softvérového programu, ktorý nespĺňa skutočné požiadavky. Testéri sa môžu s takýmito chybami stretnúť pri vykonávaní testovacích prípadov.
Tieto dva pojmy majú veľmi tenkú líniu rozdielov. V priemysle sú to chyby, ktoré je potrebné opraviť a niektoré testovacie tímy ich preto môžu interchangebaly používať.
Keď testéri vykonajú testovacie prípady, môžu sa stretnúť s takými výsledkami testov, ktoré sú v rozpore s očakávanými výsledkami. Táto variácia výsledkov testu sa označuje ako chyba softvéru. Tieto chyby alebo variácie sú v rôznych organizáciách označované rôznymi názvami, ako sú problémy, problémy, chyby alebo incidenty.
V tomto návode sa naučíte
- Správa o chybe
- Proces správy defektov
- Objav
- Kategorizácia
- Rozhodnutie
- Overenie
- Uzavretie
- Podávanie správ
- Dôležitá metrika defektu
Správa o chybe pri testovaní softvéru
Bug Report v testovanie softvéru je podrobný dokument o chybách zistených v softvérovej aplikácii. Hlásenie o chybe obsahuje všetky podrobnosti o chybách, ako je popis, dátum, kedy bola chyba nájdená, meno testera, ktorý ju našiel, meno vývojára, ktorý ju opravil, atď. Hlásenie o chybe pomáha v budúcnosti identifikovať podobné chyby, aby sa im dalo vyhnúť.
Pri hlásení chyby vývojárovi by vaše hlásenie o chybe malo obsahovať nasledujúce informácie
- Defect_ID - jedinečné identifikačné číslo chyby.
- Popis chyby - Podrobný popis chyby vrátane informácií o module, v ktorom bola chyba nájdená.
- Verzia - Verzia aplikácie, v ktorej sa zistila chyba.
- Kroky - Podrobné kroky spolu so snímkami obrazovky, pomocou ktorých môže vývojár chyby reprodukovať.
- Dátum zvýšenia - Dátum, kedy sa vyskytne chyba
- Referencia - kde vo vás Uveďte odkaz na podobné dokumenty. požiadavky, dizajn, architektúru alebo dokonca snímky obrazovky s chybou, ktoré pomôžu pochopiť poruchu
- Detected By - Meno / ID testera, ktorý upozornil na chybu
- Stav - Stav chyby, o tom neskôr
- Opravil - Meno / ID vývojára, ktorý to opravil
- Dátum uzavretia - Dátum, kedy je porucha uzavretá
- Závažnosť, ktorá popisuje vplyv chyby na aplikáciu
- Priorita, ktorá súvisí s urgentnosťou odstránenia chyby. Priorita závažnosti môže byť vysoká / stredná / nízka na základe naliehavosti nárazu, pri ktorej by sa mala chyba opraviť
Ak video nie je prístupné, kliknite sem
Zdroje
Stiahnite si vzor šablóny hlásenia defektov
Nasledujúce položky považujte za manažéra testov
Váš tím našiel chyby pri testovaní projektu Guru99 Banking.
Po týždni vývojár odpovie -
Budúci týždeň odpovie tester
Rovnako ako v predchádzajúcom prípade, ak sa komunikácia o chybe uskutoční ústne, čoskoro sa veci veľmi skomplikujú. Na kontrolu a efektívnu správu chýb potrebujete životný cyklus chyby.
Čo je proces správy defektov?
Správa defektov je systematický proces na identifikáciu a opravu chýb. Cyklus správy defektov obsahuje nasledujúce etapy 1) Zistenie chyby, 2) Kategorizácia chyby 3) Oprava chyby vývojármi 4) Overenie testermi, 5) Uzávierka chyby 6) Hlásenie chýb na konci projektu
Táto téma vás prevedie tým, ako aplikovať proces správy defektov na webovú stránku projektu Guru99 Bank. Pri správe chýb môžete postupovať podľa nasledujúcich krokov.
Objav
Vo fáze objavovania musia projektové tímy odhaliť čo najviac defektov , skôr ako ich konečný zákazník odhalí. Porucha sa údajne objaví a zmena stavu sa prijme, keď ju vývojári uznajú a prijmú
Vo vyššie uvedenom scenári testéri odhalili 84 defektov na webe Guru99.
Pozrime sa na nasledujúci scenár; váš testovací tím zistil nejaké problémy na webovej stránke Guru99 Bank. Považujú ich za chyby a nahlásili ich vývojovému tímu, ale došlo ku konfliktu -
Čo v takom prípade urobíte ako manažér testu?
A) Dohodnite sa s testovacím tímom, že má chybu
B) Vedúci testu prevezme úlohu sudcu, ktorý rozhodne, či je problém vadný alebo nie
C) Dohodnite sa s vývojovým tímom, že nejde o chybu. Správne Nesprávne
V takom prípade by sa mal na vyriešenie konfliktu použiť postup riešenia problému. Vy rozhodujete o tom, či je problém na webovej stránke závadou, alebo nie.
Kategorizácia
Kategorizácia chýb pomáha vývojárom softvéru uprednostniť svoje úlohy. To znamená, že tento druh priority pomáha vývojárom pri odstraňovaní tých najdôležitejších chýb.
Poruchy zvyčajne kategorizuje Správca testov -
Poďme na malé cvičenie podľa nasledujúceho postupu Drag & Drop priority defektov
- Kritické
- Vysoký
- Stredná
- Nízka
| 1) Výkon webových stránok je príliš pomalý |
|
| 2) Funkcia prihlásenia na webovú stránku nefunguje správne |
|
| 3) GUI webovej stránky sa na mobilných zariadeniach nezobrazuje správne |
|
| 4) Webová stránka si nemohla pamätať reláciu prihlásenia používateľa |
|
| 5) Niektoré odkazy nefungujú |
|
Tu sú odporúčané odpovede
| Č. | Popis | Priorita | Vysvetlenie |
|---|---|---|---|
| 1 | Výkon webových stránok je príliš pomalý | Vysoký | Chyba vo výkone môže spôsobiť používateľovi obrovské nepríjemnosti. |
| 2 | Funkcia prihlásenia na webe nefunguje správne | Kritické | Prihlásenie je jednou z hlavných funkcií bankového webu, ak táto funkcia nefunguje, jedná sa o vážne chyby |
| 3 | GUI webu sa na mobilných zariadeniach nezobrazuje správne | Stredná | Porucha ovplyvňuje používateľa, ktorý používa smartphone na prezeranie webových stránok. |
| 4 | Web si nemohol spomenúť na reláciu prihlásenia používateľa | Vysoký | Toto je vážny problém, pretože používateľ sa bude môcť prihlásiť, ale nebude môcť vykonávať ďalšie transakcie |
| 5 | Niektoré odkazy nefungujú | Nízka | Toto je ľahká oprava pre vývojových pracovníkov a používateľ má stále prístup na web bez týchto odkazov |
Riešenie chyby
Riešenie chýb v testovaní softvéru je krok za krokom proces odstraňovania chýb. Proces riešenia chyby začína priradením chýb vývojárom, potom vývojári naplánujú opravu chyby podľa priority, potom sa chyby opravia a nakoniec vývojári pošlú správu o riešení správcovi testov. Tento proces pomáha ľahko opraviť a sledovať chyby.
Podľa nasledujúcich pokynov môžete chybu opraviť.
- Priradenie : Pridelené vývojárovi alebo inému technikovi na opravu a stav sa zmenil na Odpovedať .
- Oprava rozvrhu : V tejto fáze prevezme kontrolu strana vývojárov. Vytvoria plán na opravu týchto defektov, v závislosti od priority defektov.
- Opravte chybu : Zatiaľ čo vývojový tím chyby opravuje, Správca testov sleduje proces opravy chyby v porovnaní s vyššie uvedeným harmonogramom.
- Nahlásiť riešenie : Po odstránení chýb získate od vývojárov správu o riešení.
Overenie
Po tom, čo vývojový tím chybu napravil a nahlásil , testovací tím overí, či sú chyby skutočne vyriešené.
Napríklad vo vyššie uvedenom scenári, keď vývojový tím uviedol, že už opravilo 61 chýb, váš tím znova otestuje, či tieto chyby boli opravené alebo nie.
Uzavretie
Po vyriešení a overení chyby sa stav chyby zmení na uzavretý . Pokiaľ nie, pošlete vývojárovi oznámenie o opätovnej kontrole chyby.
Hlásenie porúch
Hlásenie defektov pri testovaní softvéru je proces, v rámci ktorého manažéri testov pripravujú a odosielajú správy o chybách riadiacemu tímu, aby získali spätnú väzbu o procese správy defektov a stave defektov. Potom riadiaci tím skontroluje správu o chybe a v prípade potreby pošle spätnú väzbu alebo poskytne ďalšiu podporu. Hlásenie chýb pomáha lepšie komunikovať, sledovať a podrobne vysvetľovať chyby.
Správna rada má právo poznať stav chyby. Musia pochopiť proces správy defektov, aby vás podporili v tomto projekte. Preto im musíte nahlásiť aktuálnu poruchovú situáciu, aby ste od nich dostali spätnú väzbu.
Dôležitá metrika defektu
Späť uvedený scenár. Vývojové a testovacie tímy skontrolujú nahlásené chyby. Tu je výsledok tejto diskusie
Ako merať a hodnotiť kvalitu vykonania testu?
To je otázka, ktorú chce vedieť každý manažér testov. Existujú 2 parametre, ktoré môžete považovať za nasledujúce
Vo vyššie uvedenom scenári môžete vypočítať pomer odmietnutia defekcie (DRR) 20/84 = 0,238 (23,8%).
Ďalším príkladom je predpokladaná webová stránka banky Guru99 Bank, ktorá má celkom 64 defektov, váš testovací tím však zistí iba 44 defektov, tj zmeškali 20 defektov. Preto môžete vypočítať pomer úniku chyby (DLR) je 20/64 = 0,312 (31,2%).
Záverom je možné hodnotiť kvalitu vykonania testu pomocou nasledujúcich dvoch parametrov
Čím menšia hodnota DRR a DLR je, tým lepšia je kvalita vykonania testu. Aký rozsah pomerov je prijateľný ? Tento rozsah je možné definovať a akceptovať v cieľovom objekte projektu alebo môžete odkázať na metriky podobných projektov.
V tomto projekte je odporúčaná hodnota prijateľného pomeru 5 ~ 10%. To znamená, že kvalita vykonania testu je nízka. Mali by ste nájsť protiopatrenie na zníženie týchto pomerov ako napr
- Zlepšiť testovacie schopnosti člena.
- Venujte viac času vykonaniu testu, najmä kontrole výsledkov vykonania testu.