Proces správy defektů v testování softwaru
Thomas Hamilton
⚡ Chytré shrnutí
Proces správy defektů v testování softwaru je strukturovaný rámec pro identifikaci, kategorizaci, řešení, ověřování, uzavírání a hlášení chyb. Umožňuje předvídatelnou komunikaci mezi testery a vývojáři, zlepšuje kvalitu vydání a snižuje počet úniků na produkční úrovni v celém životním cyklu projektu.
Co je to proces správy defektů?
Jedno Proces správy defektů je systematický přístup používaný v testování softwaru k identifikaci, klasifikaci, opravě a ověřování chyb před vydáním softwaru. Životní cyklus zahrnuje šest základních fází: 1) Objevení defektu, 2) Kategorizace, 3) Řešení vývojáři, 4) Ověření testery, 5) Uzavření a 6) Hlášení defektu na konci projektu.
Tento článek vysvětluje, jak aplikovat proces správy defektů pomocí GuruPříklad webových stránek banky 99, aby začátečníci i středně pokročilí testeři mohli pochopit každý krok v kontextu reálného projektu.
Proč potřebujete proces správy defektů?
Představte si, že váš tým při testování našel několik chyb. Guru99 Bankovní projekt. Bez strukturovaného procesu probíhá komunikace mezi testery a vývojáři verbálně nebo prostřednictvím rozptýlených zpráv.
O týden později vývojář reaguje s jiným pochopením problému.
Následující týden tester znovu odpoví, což způsobí ještě větší zmatek.
Pokud se komunikace o závadách řeší ústně nebo neformálně, věci se velmi rychle komplikují. Pro kontrolu a efektivní správu chyb potřebujete definovaný životní cyklus závad, který standardizuje způsob, jakým týmy hlásí, track a uzavřít problémy.
Krok 1) Objevování
v objev Ve fázi musí projektový tým identifikovat co nejvíce vad, než se s nimi koncový zákazník setká. Vada je považována za „objevenou“, jakmile ji vývojový tým uzná a akceptuje, načež se její stav změní na Přijato.
V daném příkladu testeři objevili 84 defektů na GuruWebové stránky banky 99.
Testeři a vývojáři se však ne vždy shodnou. Podívejte se na následující případ, ve kterém testovací tým identifikuje problémy na Guru99 Webové stránky banky a hlásí je, ale vývojový tým zpochybňuje, zda se jedná o vady:
Co byste v takovém případě jako manažer testování měli dělat?
A) Souhlaste s testovacím týmem, že se jedná o vadu.
B) Ujměte se role soudce a rozhodněte, zda je problém vadou či nikoli.
C) Souhlasit s vývojovým týmem, že se nejedná o vadu.
Správný přístup je možnost B. K vyřešení konfliktu by měl být použit proces řešení a manažer testování by měl problém nestranně vyhodnotit, než rozhodne, zda se kvalifikuje jako vada.
Krok 2) Kategorizace
Kategorizace vad pomáhá vývojářům stanovit priority jejich práce tak, aby se nejdříve opravily ty nejkritičtější problémy z hlediska podnikání. Kategorizaci obvykle provádí manažer testování a je založena na závažnosti a dopadu na podnikání.
Vady se obvykle seskupují do čtyř úrovní priority: Kritický, vysoký, střední a nízkýZkuste přiřadit správnou prioritu každému z následujících defektů:
- Výkon webových stránek je příliš pomalý.
- Funkce přihlášení na webu nefunguje správně.
- Grafické uživatelské rozhraní webových stránek se nezobrazuje správně. mobilní zařízení.
- Webová stránka si nepamatuje přihlašovací relaci uživatele.
- Některé odkazy nefungují.
Zde jsou doporučené odpovědi:
| Ne. | Description | Priorita | Vysvětlení |
|---|---|---|---|
| 1 | Výkon webu je příliš pomalý | Vysoký | Problémy s výkonem způsobují koncovým uživatelům značné nepříjemnosti. |
| 2 | Funkce přihlášení nefunguje správně | kritický | Přihlášení je klíčovou funkcí bankovních webových stránek. Pokud selže, celá cesta uživatele je zablokována. |
| 3 | Grafické uživatelské rozhraní se na mobilních zařízeních nezobrazuje správně. | Střední | Chyba postihuje uživatele, kteří si prohlížejí webové stránky na chytrých telefonech. |
| 4 | Webová stránka si nepamatuje přihlašovací relaci uživatele | Vysoký | Uživatelé se mohou přihlásit, ale nemohou provádět žádné další transakce. |
| 5 | Některé odkazy nefungují | Nízké | Snadná oprava pro vývojáře a uživatelé mají stále přístup ke zbytku webu. |
Krok 3) Řešení defektů
Rozlišení vad V testování softwaru je proces opravy defektů krok za krokem. Proces řešení začíná přiřazením defektů vývojářům, kteří poté naplánují opravy na základě priority, implementují korekce a nakonec odešlou zprávu o řešení zpět manažerovi testování. Tato sekvence umožňuje vyřešit defekty. trackrál transparentní a odpovědný.
K opravě vady můžete postupovat takto:
- Úkol: Závada je přiřazena vývojáři nebo technikovi a její stav se změní na Reagovat.
- Oprava harmonogramu: Vývojový tým převezme kontrolu a vytvoří plán oprav na základě priority vady.
- Opravte vadu: Zatímco vývojáři opravují chyby, manažer testování tracks postupuje proti plánovanému harmonogramu.
- Nahlásit usnesení: Vývojáři zasílají zprávu potvrzující, které vady byly opraveny a jakým způsobem.
Krok 4) Ověření
Poté, co vývojový tým stanovena a hlášeny vady, testovací tým ověřuje že problémy byly vyřešeny.
Například když vývojový tým oznámí, že bylo opraveno 61 defektů, testovací tým každou z nich znovu otestuje, aby potvrdil, zda opravy fungují správně za stejných podmínek, které způsobily původní selhání.
Krok 5) Uzavření
Jakmile je závada opravena a ověřena, její stav se změní na ZavřenoPokud vada během ověřování není řádně vyřešena, musíte vývojovému týmu poslat oznámení, aby ji znovu prošetřil. Uzavření znamená, že vada již v systému není aktivní.
Krok 6) Hlášení závad
Hlášení závad V testování softwaru je testování proces, při kterém manažeři testování připravují a sdílejí stav vad s manažerským týmem. Manažerský tým zprávu zkontroluje a v případě potřeby poskytne zpětnou vazbu nebo další podporu. Hlášení vad zlepšuje komunikaci, trackrál a viditelnost kolem vad.
Vedení má právo rozumět stavu závad, aby mohlo projekt efektivně podporovat. Proto musíte pravidelně informovat o aktuálním stavu závad, aby vám mohlo poskytnout rady a zdroje.
Metriky důležitých vad
Vrátíme-li se k původnímu scénáři, vývojářské a testovací týmy společně zkontrolují vady. Kombinované výsledky jsou uvedeny níže.
Jak můžete měřit a hodnotit kvalitu provedení testů?
To je kritická otázka každého Správce testů chce odpovědět. Obvykle se používají dva klíčové parametry:
Ve výše uvedeném scénáři, Poměr odmítnutí vad (DRR) se vypočítá jako 20/84 = 0.238 (23.8 %).
Jako další příklad si představme, že GuruWebové stránky banky 99 mají celkem 64 vady, ale testovací tým detekuje pouze 44 — význam 20 vady byly přehlédnuty. Poměr úniku vad (DLR) se vypočítá jako 20/64 = 0.312 (31.2 %).
Stručně řečeno, kvalita provedení testu se hodnotí pomocí dvou níže uvedených parametrů:
Čím menší jsou hodnoty DRR a DLR, tím lepší je kvalita provedení testu. Přijatelný rozsah je obecně definován cíli projektu nebo porovnáván s podobnými projekty. V tomto příkladu je doporučený přijatelný rozsah 5% až 10%Aktuální provedení je mimo tento rozsah, což signalizuje, že kvalita testů by měla být zlepšena pomocí následujících opatření:
- Zvýšit testovací dovednosti členů týmu.
- Trávit více času na provádění testů, zejména při kontrole výsledků provádění.
Nejlepší postupy pro efektivní správu vad
Dodržování strukturovaných osvědčených postupů odlišuje propracovaný proces správy defektů od chaotického. Cílem není jen opravit chyby, ale vytvořit systém, který zabrání jejich úniku do produkčního prostředí a minimalizuje komunikační výpadky mezi testery a vývojáři.
Zde jsou osvědčené postupy, které by si měli začínající a středně pokročilí testeři ihned osvojit:
- Standardizujte šablonu defektu: Použijte šablonu hlášení o vadách s pevnou adresou, která obsahuje pole jako ID vady, Description, kroky k reprodukci, závažnost, priorita, prostředí a přílohy. Konzistence snižuje komunikaci mezi testery a vývojáři.
- Před přiřazením stanovte priority: Před odesláním vývojářům vždy roztřiďte vady podle závažnosti a priority. Tím zajistíte, že kritické problémy neuvíznou za kosmetickými.
- Před nahlášením reprodukovat: Před vyzvednutím defektu jej alespoň dvakrát reprodukujte v čistém prostředí. Reprodukovatelné defekty se rychleji uzavírají a snižují míru odmítnutí.
- Přijměte vadu trackrálovský nástroj: Používejte nástroje jako např PROHLÍDKA, Bugzillanebo Mantis centralizovat trackrál, historie a reportáž.
- Provádějte triážní schůzky: Pořádejte krátké, cílené schůzky zaměřené na třídění vad, abyste sladili priority mezi týmy QA, vývoje a produktů.
- Měření úniku a odmítnutí: Track DLR a DRR v každém sprintu nebo cyklu. Rostoucí míra úniku je včasným varováním, že pokrytí testy je neúplné.
- Proveďte analýzu hlavní příčiny: U opakujících se nebo vysoce závažných vad spusťte analýzu hlavní příčiny, aby se stejná třída chyb v budoucích verzích neopakovala.
- Uzavřete cyklus pomocí reportingu: Sdílejte týdenní přehledy závad se zúčastněnými stranami, aby problémy zůstaly viditelné a řešitelné.
Při důsledném uplatňování tyto postupy stabilizují životní cyklus defektů a zvyšují celkovou kvalitu každého vydání.
Zdroje:
Stáhněte si vzorovou šablonu hlášení závad
