Co je Bug?
Chyba je důsledkem / výsledkem chyby kódování.
Vada v testování softwaru
Defekt v testování softwaru je variace nebo odchylka softwarové aplikace z požadavků koncového uživatele nebo původními požadavky podnikatelů. Softwarová vada je chyba v kódování, která způsobuje nesprávné nebo neočekávané výsledky softwarového programu, který nesplňuje skutečné požadavky. Testeři by se při provádění testovacích případů mohli s takovými vadami setkat.
Tyto dva pojmy mají velmi tenkou linii odlišnosti. V tomto odvětví jsou to chyby, které je třeba opravit, a proto je některými testovacími týmy interchangebaly používají.
Když testeři provedou testovací případy, mohou narazit na takové výsledky testů, které jsou v rozporu s očekávanými výsledky. Tato variace výsledků testu se označuje jako softwarová vada. Tyto vady nebo variace jsou v různých organizacích označovány různými názvy, jako jsou problémy, problémy, chyby nebo incidenty.
V tomto výukovém programu se naučíte
- Zpráva o chybě
- Proces správy vad
- Objev
- Kategorizace
- Rozlišení
- Ověření
- Uzavření
- Hlášení
- Důležité metriky defektů
Zpráva o chybě při testování softwaru
Bug Report v testování softwaru je podrobný dokument o chybách zjištěných v softwarové aplikaci. Hlášení o chybě obsahuje každý detail o chybách, jako je popis, datum, kdy byla chyba nalezena, jméno testera, který ji našel, jméno vývojáře, který ji opravil atd. Hlášení o chybě pomáhá v budoucnu identifikovat podobné chyby, aby se jim dalo vyhnout.
Při hlášení chyby vývojáři by vaše hlášení o chybě mělo obsahovat následující informace
- Defect_ID - jedinečné identifikační číslo vady.
- Popis defektu - Podrobný popis defektu včetně informací o modulu, ve kterém byl defekt nalezen.
- Verze - Verze aplikace, ve které byla nalezena chyba.
- Kroky - Podrobné kroky spolu se snímky obrazovky, pomocí kterých může vývojář chyby reprodukovat.
- Datum zvýšeno - Datum, kdy je vada vznesena
- Reference - kde ve vás Uveďte odkaz na podobné dokumenty. požadavky, design, architektura nebo dokonce snímky obrazovky s chybou, které pomohou porozumět vadě
- Detected By - Jméno / ID testera, který defekt vyvolal
- Stav - stav vady, více o tom později
- Opraveno - Jméno / ID vývojáře, který jej opravil
- Datum zavřeno - Datum, kdy je závada uzavřena
- Závažnost, která popisuje dopad vady na aplikaci
- Priorita související s naléhavostí opravy defektu. Priorita závažnosti může být vysoká / střední / nízká na základě naléhavosti nárazu, při které by měla být vada odstraněna
Pokud video není přístupné, klikněte sem
Zdroje
Stáhněte si vzorovou šablonu hlášení vad
Zvažte následující jako správce testů
Váš tým našel chyby při testování projektu Guru99 Banking.
Po týdnu vývojář odpoví -
Příští týden tester odpoví
Stejně jako ve výše uvedeném případě, pokud se komunikace vady provádí ústně, brzy se věci velmi zkomplikují. K ovládání a efektivní správě chyb potřebujete životní cyklus vady.
Co je proces správy defektů?
Správa defektů je systematický proces k identifikaci a opravě chyb. Cyklus správy defektů obsahuje následující fáze 1) Zjištění defektu, 2) Kategorizace defektů 3) Oprava defektu vývojáři 4) Ověření testery, 5) Uzavření defektu 6) Hlášení defektů na konci projektu
Toto téma vás provede tím, jak aplikovat proces správy defektů na webovou stránku projektu Guru99 Bank. Při správě závad můžete postupovat podle následujících kroků.
Objev
Ve fázi zjišťování musí projektové týmy objevit co nejvíce závad , než je konečný zákazník může objevit. Porucha se říká, že je objevena a změna stavu přijata, když je potvrzena a přijata vývojáři
Ve výše uvedeném scénáři objevili testeři 84 defektů na webu Guru99.
Pojďme se podívat na následující scénář; váš testovací tým objevil nějaké problémy na webu Guru99 Bank. Považují je za vady a nahlásili je vývojovému týmu, ale došlo ke konfliktu -
Co v takovém případě jako testovací manažer uděláte?
A) Souhlasím s týmem testů, že jde o vadu
B) Správce testu převezme roli rozhodčího, aby rozhodl, zda je problém vadný nebo ne
C) Dohodněte se s vývojovým týmem, který není vadou Správně Nesprávně
V takovém případě by měl být k vyřešení konfliktu použit proces řešení, vy budete mít roli soudce, který rozhodne, zda je problém s webem vadou či nikoli.
Kategorizace
Kategorizace defektů pomáhá vývojářům softwaru stanovit priority svých úkolů. To znamená, že tento druh priority pomáhá vývojářům nejprve opravit ty závady, které jsou velmi důležité.
Vady jsou obvykle kategorizovány Správcem testů -
Pojďme udělat malé cvičení následovně Drag & Drop priority defektů níže
- Kritický
- Vysoký
- Střední
- Nízký
| 1) Výkon webu je příliš pomalý |
|
| 2) Funkce přihlášení na webu nefunguje správně |
|
| 3) Grafické uživatelské rozhraní webu se na mobilních zařízeních nezobrazuje správně |
|
| 4) Web si nemohl vzpomenout na relaci přihlášení uživatele |
|
| 5) Některé odkazy nefungují |
|
Zde jsou doporučené odpovědi
| Ne. | Popis | Přednost | Vysvětlení |
|---|---|---|---|
| 1 | Výkon webu je příliš pomalý | Vysoký | Chyba výkonu může uživateli způsobit obrovské potíže. |
| 2 | Funkce přihlášení na webu nefunguje správně | Kritický | Přihlášení je jednou z hlavních funkcí bankovního webu, pokud tato funkce nefunguje, jedná se o závažné chyby |
| 3 | Grafické uživatelské rozhraní webu se na mobilních zařízeních nezobrazuje správně | Střední | Vada má vliv na uživatele, který používá Smartphone k prohlížení webových stránek. |
| 4 | Web si nepamatoval relaci přihlášení uživatele | Vysoký | Jedná se o vážný problém, protože uživatel se bude moci přihlásit, ale nebude moci provádět žádné další transakce |
| 5 | Některé odkazy nefungují | Nízký | Jedná se o snadnou opravu pro vývojáře a uživatel může i nadále přistupovat na web bez těchto odkazů |
Řešení závad
Řešení závad při testování softwaru je krok za krokem při opravě závad. Proces řešení defektů začíná přiřazením defektů vývojářům, poté vývojáři naplánují opravu defektu podle priority, pak jsou defekty opraveny a nakonec vývojáři pošlou zprávu o řešení správci testů. Tento proces pomáhá snadno opravit a sledovat vady.
K odstranění závady můžete postupovat podle následujících kroků.
- Přiřazení : Přiřazeno vývojáři nebo jinému technikovi k opravě a změněn stav na Odpovědět .
- Oprava plánu : V této fázi převezme odpovědnost strana vývojáře. Vytvoří plán pro opravu těchto defektů, v závislosti na prioritě defektů.
- Opravit vadu : Zatímco vývojový tým opravuje vady, Správce testů sleduje proces opravy vady ve srovnání s výše uvedeným plánem.
- Nahlásit rozlišení : Po vyřešení vad obdržíte od vývojářů zprávu o rozlišení.
Ověření
Poté, co vývojový tým chybu opravil a nahlásil , testovací tým ověří, zda jsou vady skutečně vyřešeny.
Například ve výše uvedeném scénáři, když vývojový tým oznámil, že již opravil 61 defektů, váš tým znovu otestoval, aby ověřil, zda byly tyto defekty skutečně opraveny nebo ne.
Uzavření
Jakmile je závada vyřešena a ověřena, stav závady se změní jako uzavřená . Pokud tomu tak není, zašlete vývojovi oznámení, abyste závadu znovu zkontrolovali.
Hlášení vad
Hlášení vad při testování softwaru je proces, při kterém vedoucí testů připravují a zasílají zprávu o vadách řídícímu týmu, aby získali zpětnou vazbu o procesu správy defektů a stavu vad. Poté vedoucí tým zkontroluje hlášení o závadě a v případě potřeby zašle zpětnou vazbu nebo v případě potřeby poskytne další podporu. Hlášení vad pomáhá lépe komunikovat, sledovat a podrobně vysvětlovat vady.
Správní rada má právo znát stav vady. Musí porozumět procesu správy defektů, aby vás v tomto projektu podpořili. Proto je musíte nahlásit aktuální situaci závady, abyste od nich získali zpětnou vazbu.
Důležité metriky defektů
Zpět výše uvedený scénář. Vývojové a testovací týmy zkontrolují nahlášené závady. Zde je výsledek této diskuse
Jak měřit a hodnotit kvalitu provedení testu?
To je otázka, kterou chce vědět každý manažer testů. Existují 2 parametry, které můžete považovat za následující
Ve výše uvedeném scénáři můžete vypočítat poměr odmítnutí zběhnutí (DRR) je 20/84 = 0,238 (23,8%).
Další příklad, předpokládá se, že web Guru99 Bank má celkem 64 závad, ale váš testovací tým zjistil pouze 44 závad, tj. Zmeškali 20 závad. Proto můžete vypočítat poměr úniků vad (DLR) je 20/64 = 0,312 (31,2%).
Závěrem lze říci, že kvalita provedení testu je hodnocena pomocí následujících dvou parametrů
Čím menší hodnota DRR a DLR je, tím lepší je kvalita provedení testu. Jaké rozmezí poměrů je přijatelné ? Tento rozsah může být definován a přijat v základu cíle projektu nebo můžete odkazovat na metriky podobných projektů.
V tomto projektu je doporučená hodnota přijatelného poměru 5 ~ 10%. To znamená, že kvalita provedení testu je nízká. Měli byste najít protiopatření ke snížení těchto poměrů, jako je
- Zlepšit testovací dovednosti člena.
- Věnujte více času provádění testování, zejména kontrole výsledků provádění testu.