Menu

Závažnost a priorita defektu při testování s příklady a rozdíly

defect severity priority testing with examples

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

V tomto kurzu se dozvíte, co je Defektní závažnost a Priorita v testování, jak nastavit prioritní úroveň a závažnost defektu pomocí příkladů, abyste jasně pochopili koncept.

Podrobně se také budeme zabývat tím, jak klasifikovat vady podle různých segmentů a jejich význam v cyklu Defekt Life. Rozhodující roli klasifikace pokryjeme také živým příkladem.

Registrování vad je velmi nedílnou součástí součást životního cyklu testování softwaru . Existuje definováno několik osvědčených postupů efektivní hlášení chyb přes internet nebo v organizacích.

Závažnost a priorita vady

Co se naučíte:

Přehled sledování vad

Jedním z důležitých aspektů životního cyklu defektů na obecné úrovni je sledování defektů. To je důležité, protože testovací týmy otevírají několik vad při testování softwaru, který se znásobí, pouze pokud je konkrétní testovaný systém složitý. V takovém scénáři může být správa těchto defektů a analýza těchto defektů za účelem uzavření disku skličující úlohou.

V souladu s procesy údržby defektů, když kterýkoli tester zaznamená defekt - kromě metody / popisu k reprodukci viděného problému, musí také poskytnout některé kategorické informace, které by pomohly nepřesné klasifikaci defektu. To by zase pomohlo v efektivních procesech sledování / údržby defektů a také by to bylo základem pro rychlejší dobu zpracování defektů.

Dva hlavní parametry, které tvoří základ pro efektivní sledování a řešení defektů, jsou:

  • Priorita defektu při testování
  • Závažnost defektu při testování

Jedná se často o matoucí koncept a jsou téměř zaměnitelně používány nejen mezi testovacími týmy, ale také vývojovými týmy. Mezi nimi je tenká čára a je důležité si uvědomit, že mezi nimi skutečně existují rozdíly.

V následující části si stručně vysvětlíme teoretické definice těchto dvou parametrů.

Co je závažnost a priorita defektu?

Priorita podle anglické definice se používá při srovnání dvou věcí nebo podmínek, kde jedné musí být přikládána větší důležitost než ostatním (ostatním) a musí být nejprve vyřešena / vyřešena, než bude pokračovat k dalším (dalším). V kontextu vad by tedy priorita vady naznačovala naléhavost, s níž by ji bylo třeba napravit.

Závažnost podle anglické definice se používá k popisu závažnosti nežádoucího výskytu. Pokud tedy jde o chyby, závažnost chyby by naznačovala účinek, který má na systém, pokud jde o jeho dopad.

bezplatná aplikace pro plánování příspěvků na instagramu

Kdo je definuje?

QA klasifikuje vadu podle příslušné závažnosti na základě složitosti a kritičnosti vad.

Prioritu vad definují jakékoli obchodní zúčastněné strany, včetně projektových manažerů, obchodních analytiků a vlastníků produktů.

Níže uvedený obrázek znázorňuje roli, která vlastní a klasifikuje kritičnost a závažnost vad.

ZÁVAŽNOST A PRIORITA

Jak si vybrat tyto úrovně?

Jak jsme již diskutovali, parametr závažnosti posuzuje tester, zatímco parametr priority posuzuje hlavně produktový manažer nebo v zásadě třídící tým. I když tomu tak je, závažnost vady je rozhodně jedním z rozhodujících a ovlivňujících faktorů pro upřednostnění vady. Proto je důležité jako tester zvolit správnou závažnost, aby nedošlo k záměně s vývojovými týmy.

Rozdíl mezi závažností a prioritou

Priorita je spojena s plánováním a „závažnost“ je spojena se standardy.

„Priorita“ znamená, že je něčemu věnováno nebo si zaslouží předchozí pozornost; priorita stanovená podle pořadí důležitosti (nebo naléhavosti).

„Závažnost“ je stav nebo kvalita závažnosti; přísné znamená dodržování přísných standardů nebo vysokých zásad a často naznačuje tvrdost; závažné je poznamenáno nebo vyžaduje přísné dodržování přísných standardů nebo vysokých zásad, Například, přísný kodex chování.

Při sledování chyb se objevují slova priorita a závažnost.

K dispozici je řada komerčních softwarových nástrojů pro sledování a správu problémů. Tyto nástroje s podrobným vstupem inženýrů pro testování softwaru poskytují týmu úplné informace, aby vývojáři mohli pochopit chybu, získat představu o její „závažnosti“, reprodukovat ji a opravit.

Opravy vycházejí z projektu „Priority“ a „Závažnosti“ chyb.

„Závažnost“ problému je definována v souladu s posouzením rizik zákazníka a zaznamenána v jeho vybraném nástroji pro sledování.

Buggy software může „vážně“ ovlivnit plány, což může vést k přehodnocení a opětovnému projednání „priorit“.

Co je to priorita?

Priorita, jak název napovídá, je o stanovení priority defektu na základě obchodních potřeb a závažnosti defektu. Priorita znamená důležitost nebo naléhavost odstranění závady.

Při otevírání vady tester obvykle přiřadí prioritu zpočátku, když se dívá na produkt z pohledu koncového uživatele. V souladu s nimi existují různé úrovně:

Obecně lze Prioritu vad klasifikovat takto:

Priorita č. 1) Okamžitá / kritická (P1)

To musí být opraveno okamžitě do 24 hodin. K tomu obvykle dochází v případech, kdy je blokována celá funkce a v důsledku toho nemůže pokračovat žádné testování. Nebo v určitých jiných případech, pokud dojde k významným únikům paměti, je obecně vada klasifikována jako priorita -1, což znamená, že program / funkce je v aktuálním stavu nepoužitelná.

Jakákoli závada, která vyžaduje okamžitou pozornost a která ovlivňuje proces testování, bude klasifikována do bezprostřední kategorie

Všechny Kritická závažnost vady spadají do této kategorie (pokud nebudou znovu upřednostněny obchodem / zúčastněnými stranami)

Priorita č. 2) Vysoká (P2)

Jakmile jsou kritické vady opraveny, je vadou s touto prioritou další kandidát, který musí být opraven pro jakoukoli testovací aktivitu, aby odpovídal kritériím „ukončení“. Normálně, když funkce není použitelná tak, jak má být, kvůli vadě programu nebo novému kódu, který je třeba napsat, nebo někdy dokonce kvůli tomu, že je třeba prostřednictvím kódu vyřešit nějaký problém s prostředím, může se vada kvalifikovat pro prioritu 2 .

Toto je vada nebo problém, který by měl být vyřešen před vydáním. Tyto vady by měly být vyřešeny, jakmile budou vyřešeny kritické problémy.

Všechny Hlavní, důležitý vážnost vady spadají do této kategorie.

Priorita č. 3) Střední (P3)

Poruchu s touto prioritou je třeba ve hře opravit, protože by mohla řešit i problémy s funkčností, které nejsou podle očekávání. Někdy dokonce kosmetické chyby, jako je očekávání správné chybové zprávy během selhání, se mohou kvalifikovat jako vada priority 3.

Tato vada by měla být vyřešena po opravě všech závažných chyb.

Jakmile jsou chyby Critical a High priority hotové, můžeme přejít na chyby se střední prioritou.

Všechny Méně důležitý vážnost vady spadají do této kategorie.

Priorita č. 4) Nízká (P4)

Porucha s nízkou prioritou naznačuje, že určitě existuje problém, ale nemusí být opraven, aby odpovídal kritériím „ukončení“. To však musí být opraveno před provedením GA. Typicky zde mohou být kategorizovány některé chyby při psaní nebo dokonce kosmetické chyby, jak byly popsány výše.

Někdy se také otevřou defekty s nízkou prioritou, aby se navrhla některá vylepšení stávajícího designu nebo požadavek na implementaci malé funkce pro vylepšení uživatelské zkušenosti.

Tuto vadu lze vyřešit v budoucnu a nevyžaduje žádnou okamžitou pozornost a Nízká závažnost vady spadají do této kategorie.

Jak již bylo řečeno, priorita určuje, jak rychle musí být doba zpracování závady. Pokud existuje více závad, priorita rozhodne, která závada musí být opravena a okamžitě ověřena oproti které závadě lze opravit o něco později.

Úrovně priority a závažnosti vad

Co je to závažnost?

Závažnost definuje, do jaké míry by konkrétní vada mohla mít dopad na aplikaci nebo systém.

Závažnost je parametr, který označuje dopad defektu na systém - jak kritický je defekt a jaký je dopad defektu na funkčnost celého systému? Závažnost je parametr nastavený testerem, když otevírá defekt, a je hlavně pod kontrolou testeru. Různé organizace mají opět různé nástroje, které lze použít pro vady, ale na obecné úrovni se jedná o následující úrovně závažnosti:

Například, Zvažte následující scénáře

  • Pokud se uživatel pokusí provést online nakupování a aplikace se nenačte nebo se zobrazí zpráva o nedostupnosti serveru.
  • Uživatel provede přidání položky do košíku, počet přidaných množství je nesprávný / přidá se nesprávný produkt.
  • Uživatel provede platbu a po provedení platby zůstane objednávka v košíku jako rezervovaná, místo toho bude potvrzena.
  • Systém objednávku přijme, ale nakonec objednávku zruší po půl hodině kvůli problémům.
  • Systém přijímá „Přidat do košíku“ pouze dvojitým kliknutím, nikoli jediným kliknutím.
  • Tlačítko Přidat do košíku je napsáno jako Přidat do košíku.

Jaká by byla uživatelská zkušenost, kdyby došlo k některému z výše uvedených scénářů?

Vady lze obecně klasifikovat takto:

# 1) Kritické (S1)

Vada, která zcela ztěžuje nebo blokuje testování produktu / funkce, je kritickou vadou. Příkladem by byl případ testování uživatelského rozhraní, kde po průchodu průvodcem uživatelské rozhraní pouze zablokuje v jednom podokně nebo nepřejde dále ke spuštění funkce. Nebo v některých jiných případech, když funkce vyvinutá sama chybí v sestavení.

Z jakéhokoli důvodu, pokud dojde k chybě aplikace nebo se stane nepoužitelnou / nebude schopna pokračovat dále, může být vada klasifikována pod kritickou závažností.

Jakákoli katastrofická selhání systému by mohla uživatele vést k nepoužitelnosti aplikací, které lze klasifikovat pod kritickou závažnost

Například, U poskytovatele e-mailových služeb, jako je Yahoo nebo Gmail, po zadání správného uživatelského jména a hesla, místo přihlášení, dojde k chybě systému nebo se zobrazí chybová zpráva, je tato vada klasifikována jako kritická, protože tato vada způsobí nepoužitelnost celé aplikace.

Scénář uvedený výše v bodě 1 lze klasifikovat jako kritický defekt, protože online aplikace se stává zcela nepoužitelnou.

# 2) Hlavní (S2)

Jakoukoli implementovanou hlavní funkci, která nesplňuje její požadavky / případy použití a chová se jinak, než se očekávalo, lze ji klasifikovat pod hlavní závažnost.

Hlavní chyba nastane, když funkce funguje hrubě od očekávání nebo nedělá to, co by měla dělat. Příklad může být: Řekněme, že na přepínači je třeba nasadit VLAN a používáte šablonu uživatelského rozhraní, která tuto funkci spouští. Když tato šablona pro konfiguraci VLAN selže na přepínači, bude klasifikována jako nevýhoda závažné funkce.

Například, Pokud u poskytovatele e-mailových služeb, jako je Yahoo nebo Gmail, nemáte povoleno přidat do sekce CC více než jednoho příjemce, je tato vada klasifikována jako hlavní vada, protože hlavní funkce aplikace nefunguje správně.

Co se očekává od chování sekce CC v e-mailu, mělo by to uživateli umožnit přidat více uživatelů. Pokud tedy hlavní funkce aplikace nepracuje správně nebo se chová jinak, než se očekávalo, jedná se o hlavní vadu.

Scénáře popsané výše v bodech 2 a 3 lze klasifikovat jako závažné defekty, protože se očekává hladký přechod objednávky do další fáze životního cyklu objednávky, ale ve skutečnosti se liší v chování.

Jakoukoli vadu, která by mohla vést k nesprávnému přetrvávání dat, problémům s daty nebo nesprávnému chování aplikace, lze obecně klasifikovat pod hlavní závažnost.

# 3) Menší / Střední (S3)

Jakoukoli implementovanou funkci, která neplní své požadavky / případy použití a chová se jinak, než se očekávalo, ale dopad je do určité míry zanedbatelný nebo nemá zásadní dopad na aplikaci, lze klasifikovat podle menší závažnosti.

Mírná vada nastane, když produkt nebo aplikace nesplňují určitá kritéria nebo stále vykazují nepřirozené chování, na funkčnost jako celek to však nemá vliv. Například v nasazení šablony VLAN výše by došlo k mírné nebo normální závadě, když je šablona úspěšně nasazena na přepínači, uživateli však není odeslána žádná indikace.

Například, U poskytovatele e-mailových služeb, jako je Yahoo nebo Gmail, existuje možnost s názvem „Podmínky“ a v této možnosti bude několik odkazů týkajících se podmínek a podmínek webu. Pokud jeden z více odkazů nefunguje, nazývá se to jako menší závažnost, protože ovlivňuje pouze malou funkčnost aplikace a nemá velký dopad na použitelnost aplikace.

Scénář v bodě 5 popsaný výše lze klasifikovat jako menší vadu, protože nedochází ke ztrátě dat nebo selhání v pořadí toku systému, ale k mírné nepříjemnosti, pokud jde o uživatelskou zkušenost.

Tyto typy vad vedou k minimální ztrátě funkčnosti nebo uživatelské zkušenosti.

příklad testovacího případu junit v zatmění Java

# 4) Nízká (S4)

Veškeré kosmetické vady, včetně pravopisných chyb nebo problémů se zarovnáním nebo velikostí písma, lze klasifikovat pod Nízkou závažností.

Drobná chyba nízké závažnosti nastane, když nemá téměř žádný dopad na funkčnost, ale stále se jedná o platný defekt, který by měl být opraven. Příkladem toho mohou být pravopisné chyby v chybových zprávách vytištěných uživatelům nebo vady, které vylepšují vzhled a chování prvku.

Například, U poskytovatele e-mailových služeb, jako je Yahoo nebo Gmail, byste si všimli „Licenční stránky“. Pokud se na stránce vyskytnou nějaké pravopisné chyby nebo nesprávné zarovnání, je tato vada klasifikována jako Nízká.

Scénář v bodě 6 popsaný výše by mohl být klasifikován jako Low Defect, protože tlačítko Přidat je zobrazeno v nesprávných případech. Tento druh vady nebude mít žádný dopad na chování systému nebo prezentaci dat nebo ztrátu dat nebo tok dat nebo dokonce na uživatelskou zkušenost, ale bude velmi kosmetický.

Priorita a závažnost defektu

Abychom to shrnuli, následující obrázek znázorňuje širokou klasifikaci defektů na základě závažnosti a priority:

Klasifikace defektů

Příklady

Jak již bylo zmíněno, protože různé organizace používají různé druhy nástrojů pro sledování defektů a související procesy - stává se společným sledovacím systémem mezi různými úrovněmi řízení a technickým personálem.

Vzhledem k tomu, že závažnost defektu spadá spíše do působnosti této funkce, nastaví testovací inženýr závažnost vady. Vývojáři se občas podílejí na ovlivňování závažnosti vady, ale většinou to závisí na testeru, který hodnotí, jak moc může konkrétní funkce ovlivnit celkové fungování.

Na druhou stranu, pokud jde o nastavení priority defektu, ačkoli zpočátku určuje původce vady prioritu, je ve skutečnosti definován produktovým manažerem, protože má celkový pohled na produkt a jak rychle musí být konkrétní vada vyřešena . Tester není ideální osoba pro stanovení priority defektu.

Šokující, jak se to může zdát, existují dva odlišné příklady, proč:

Příklad č. 1) Zvažte, že existuje situace, kdy uživatel najde chybu v pojmenování samotného produktu nebo nějaký problém s dokumentací uživatelského rozhraní. Tester by za normálních okolností otevřel menší / kosmetickou vadu a jeho odstranění by bylo velmi jednoduché, ale pokud jde o vzhled a chování produktu / uživatelské zkušenosti, mohlo by to mít vážný dopad.

Příklad č. 2) Mohou existovat určité podmínky, za kterých se vyskytne konkrétní vada, která může být v prostředí zákazníka extrémně vzácná nebo nemusí být zasažena. I když se to z hlediska funkčnosti může testeru zdát jako defekt s vysokou prioritou, vzhledem k jeho vzácnosti výskytu a vysokým nákladům na opravu - bylo by to klasifikováno jako defekt s nízkou prioritou.

Proto je priorita defektu obecně stanovena produktovým manažerem na schůzce s „defektem“.

Různé úrovně

Priorita a závažnost mají mezi sebou některá klasifikace, které pomáhají při určování toho, jak se s vadou musí zacházet. Mnoho různých organizací má různé nástroje pro zaznamenávání defektů , takže úrovně se mohou lišit.

Pojďme se podívat na různé úrovně pro prioritu i závažnost.

  • Vysoká priorita, vysoká závažnost
  • Vysoká priorita, nízká závažnost
  • Vysoká závažnost, nízká priorita
  • Nízká závažnost, nízká priorita

Následující obrázek znázorňuje klasifikaci kategorií v jednom fragmentu.

klasifikace kategorií

# 1) Vysoká závažnost a vysoká priorita

Do této kategorie bude automaticky povýšeno jakékoli kritické / závažné selhání obchodního případu.

Jakékoli závady, kvůli kterým testování nemůže za každou cenu pokračovat nebo způsobí závažné selhání systému spadající do této kategorie. Například, kliknutí na konkrétní tlačítko nenačte samotnou funkci. Nebo provedení určité funkce způsobí, že server bude důsledně spuštěn a způsobí ztrátu dat. Červené čáry na výše uvedeném obrázku označují tyto druhy vad.

Například,

Systém se zhroutí poté, co jste provedli platbu, nebo pokud nemůžete přidat položky do košíku, tato vada je označena jako vada vysoké závažnosti a vady vysoké priority.

Další příklad by byla funkce prodejní měny bankomatu, kde po zadání správného uživatelského jména a hesla stroj nevydá peníze, ale odečte převedené z vašeho účtu.

# 2) Vysoká priorita a nízká závažnost

Do této kategorie budou automaticky povýšeny jakékoli závady menší závažnosti, které by mohly přímo ovlivnit uživatelskou zkušenost.

Do této kategorie patří defekty, které je třeba opravit, ale nemají vliv na aplikaci.

Například, očekává se, že funkce zobrazí uživateli konkrétní chybu s ohledem na její návratový kód. V tomto případě funkčně kód vyvolá chybu, ale zpráva bude muset být relevantnější pro generovaný návratový kód. Modré čáry na obrázku označují tyto druhy vad.

Například,

Logo společnosti na titulní stránce je chybné, považuje se za Vysoká priorita a nízká závažnost přeběhnout .

Příklad 1) Když je na webu Online nakupování napsáno špatně logo FrontPage, například místo Flipkartu je to napsáno jako Flipkart.

Příklad 2) V logu banky je místo ICICI napsáno jako ICCCI.

Z hlediska funkčnosti to nic neovlivňuje, takže můžeme označit jako Nízkou závažnost, ale má to dopad na uživatelskou zkušenost. Tento druh defektu je třeba zafixovat na vysokou prioritu, přestože mají na straně aplikace velmi malý dopad.

# 3) Vysoká závažnost a nízká priorita

Do této kategorie se automaticky povýší jakákoli závada, která funkčně nesplňuje požadavky nebo nemá žádné funkční důsledky pro systém, ale je vyloučena ze strany zúčastněných stran, pokud jde o obchodní kritičnost.

jak otevřít torrentované soubory na Androidu

Vady, které je třeba opravit, ale ne okamžitě. K tomu může konkrétně dojít během testování ad-hoc. To znamená, že funkce je ovlivněna do značné míry, ale je pozorována pouze při použití určitých neobvyklých vstupních parametrů.

Například, konkrétní funkci lze použít pouze na novější verzi firmwaru, aby to bylo možné ověřit - tester ve skutečnosti downgraduje svůj systém a provede test a sleduje závažný problém s funkčností, který je platný. V takovém případě budou vady zařazeny do této kategorie označené růžovými čarami, protože u koncových uživatelů se obvykle očekává vyšší verze firmwaru.

Například,

Na webu sociálních sítí, pokud je vydána beta verze nové funkce s tím, že od dnešního dne tuto funkci nevyužívá mnoho aktivních uživatelů. Jakoukoli závadu nalezenou na této funkci lze klasifikovat jako nízkou prioritu, protože tato funkce se vrací z důvodu obchodní klasifikace jako nedůležité.

Ačkoli tato funkce má funkční vadu, protože nemá přímý dopad na koncové zákazníky, může zúčastněná strana v podnikání klasifikovat vadu s nízkou prioritou, i když má závažný funkční dopad na aplikaci.

Toto je chyba vysoké závažnosti, ale lze ji upřednostnit na nízkou prioritu, protože ji lze opravit v příštím vydání jako požadavek na změnu. Obchodní partneři také upřednostňují tuto funkci jako zřídka používanou funkci a nemají vliv na žádné další funkce, které mají přímý dopad na uživatelskou zkušenost. Tento druh vady lze zařadit pod Vysoká závažnost, ale nízká priorita kategorie.

# 4) Nízká závažnost a nízká priorita

Jakékoli pravopisné chyby / velká a malá písmena v písmenu v odstavci 3rdnebo 4thna stránce aplikace a ne na hlavní nebo přední stránce / názvu.

Tyto vady jsou klasifikovány v zelených liniích, jak je znázorněno na obrázku, a vyskytují se, když nedojde k žádnému dopadu na funkčnost, ale přesto v malé míře nesplňují normy. Obecně jsou zde klasifikovány kosmetické chyby nebo řekněme rozměry buňky v tabulce v uživatelském rozhraní.

Například,

Pokud zásady ochrany osobních údajů na webu obsahují pravopisnou chybu, je tato vada nastavena jako Nízká závažnost a nízká priorita.

Pokyny

Níže uvádíme určité pokyny, které se musí každý tester snažit dodržovat:

  • Nejprve dobře pochopte koncepty priority a závažnosti. Nezaměňujte jeden s druhým a nepoužívejte je zaměnitelně. V souladu s tím postupujte podle pokynů závažnosti zveřejněných vaší organizací / týmem, aby byli všichni na stejné stránce.
  • Vždy vyberte úroveň závažnosti podle typu problému, protože to ovlivní jeho prioritu. Některé příklady jsou:
    • U kritického problému, jako je například selhání celého systému a nic nelze udělat - tato závažnost by se neměla používat k řešení vad programu.
    • U problému, který je zásadní, například v případech, kdy funkce nefunguje podle očekávání - lze tuto závažnost použít k řešení nových funkcí nebo ke zlepšení stávajícího fungování.
      Nezapomeňte, že výběr správné úrovně závažnosti bude mít za následek vadu, je to náležitá priorita.
  • Jako tester - pochopit, jak konkrétní funkce, spíše podrobněji - pochopit, jak by konkrétní scénář nebo testovací případ ovlivnil koncového uživatele. To zahrnuje hodně spolupráce a interakce s vývojovým týmem, obchodními analytiky, architekty, vedoucím testu, vedoucím vývoje. Ve svých diskusích musíte také zohlednit, kolik času by trvalo odstranění závady na základě její složitosti a času k ověření této závady.
  • Konečně , je to vždy vlastník produktu, který má právo veta vydání, vada by měla být opravena. Jelikož však relace třídění vad obsahují různé členy, kteří prezentují svůj pohled na vadu případ od případu, v případě synchronizace vývojářů a testerů to rozhodně pomůže při ovlivňování rozhodnutí.

Závěr

Při otevírání vad je odpovědností testera, aby vadám určil správnou závažnost. Nesprávná závažnost a tudíž mapování priorit může mít velmi drastické důsledky pro celkový proces STLC a produkt jako celek. Na několika pracovních pohovorech - je kladeno několik otázek o prioritě a závažnosti, aby bylo zajištěno, že jako tester budete mít tyto pojmy ve své mysli dokonale čisté.

Také jsme viděli živé příklady toho, jak klasifikovat vadu do různých segmentů závažnosti / priority. Teď bych si přál, abyste měli dostatek vysvětlení ohledně klasifikace defektů jak u skupin závažnosti / priority.

Doufám, že tento článek je úplným průvodcem k pochopení úrovně priority a závažnosti vady. Sdělte nám své myšlenky / dotazy v komentářích níže.

Doporučené čtení

^