Kdy zastavit testování (opuštění kritérií při testování softwaru)

when stop testing

Kritéria ukončení při testování:

„Dobře začátek je z poloviny hotový“ - Platí všude, dokonce i testování softwaru.

Na začátku projektu často vidíme testery softwaru velmi nadšené. Tvoříme testování dokumentů jako testovací strategie, testovací plán nebo testovací případy dychtivě a nadšeně.

Pak se dostaneme k testování softwaru s BANG! To je jen umocněno zajímavými vadami, které najdeme na začátku projektu. Jejich vyřešení jen přispěje k našemu úspěchu.

Když zjistíme spoustu závad a dokončíme první běh, přejdeme k další fázi. Když se dostaneme do druhého běhu, trochu se uvolníme a stejně jako je tomu u lidské obecné tendence nudit se testováním stejné věci ve druhém běhu.

testování jednotky testování integrace testování systému

Mnoho testerů má pocit, že se to stalo monotónní práce v pozdějších bězích a začít ztrácet zájem o testování stejného softwaru znovu a znovu. Když dosáhneme třetího běhu, začíná nás pronásledovat jedna otázka: „Kdy přestat testovat software?“

Vsadím se, že jste to museli cítit stejně a alespoň jednou se zeptali: „Kdy přestat testovat?“ Řekl bych, že otázka zní 'Kdy, kde a jak zastavit testování?' :)

Koncepčně jsme četli a mnoho testerů věří, že nemůže existovat konkrétní podmínka nebo rovnice, která by rozhodovala „Kdy přestat testovat?“ Než dospějeme k závěru k této otázce, je třeba vzít v úvahu řadu faktorů.

V dnešním článku bych se chtěl podělit o své myšlenky, jak uzavřít testovací aktivity, když dosáhneme bodu v našem testovacím cyklu, kde můžeme říci, že toto testování stačí. Uděláme to pomocí několika příkladů z reálného života v typickém testovacím cyklu.

Co se naučíte:

• Kdy je to dost testování?
• Zastavení, když jsou nalezeny všechny vady: Je to možné?
• Rozhodnutí o ukončení testování: Kritéria ukončení
• Co jsou kritéria dokončení nebo ukončení?
• Co by mělo být ve výstupních kritériích?
• Testování lze zastavit, když:
• Závěr:
• Doporučené čtení

Kdy je to dost testování?

Kdy můžeme říci, že tolik testování stačí? Lze někdy testování dokončit?

Abychom mohli odpovědět na tyto otázky, budeme muset analyzovat testovací aktivity od začátku do konce. Vezměte prosím na vědomí, že - tyto aktivity budu definovat laicky - ne technicky vymyšleným způsobem.

Uvažujme, že začínáte s testováním nového projektu.

Počáteční aktivity:

• Testovací tým obdrží požadavky.
• Spustí se testovací tým plánování a projektování.
• Dokumenty o počátečním testu jsou připraveny a zkontrolovány.

Testovací běh č. 1)

• Testovací tým zahájí provádění testu jakmile obdrží vyvinutý produkt.
• Během fáze testování provádějí různé scénáře, aby rozbili software a našli mnoho defektů. (Také míra vad je zde vyšší, protože aplikace je nová a prochází vůbec poprvé hodnocením.)
• Vady jsou opraveny vývojáři a vráceny zpět testovacímu týmu k opětovnému testování.
• Testovací tým provede opakované testování vad a provede regresi.
• Jakmile je většina závad vysoké závažnosti vyřešena a software vypadá stabilně, vývojový tým vydává další verzi.

Testovací běh č. 2)

• Testovací tým zahájí druhý běh testování a podobné aktivity jsou prováděny jako běh 1.
• V tomto procesu je během druhého testování spuštěno několik dalších defektů.
• Vady jsou opraveny vývojáři a vráceny zpět testovacímu týmu k opětovnému testování.
• Testovací tým znovu testuje vady a provádí regrese .

To může pokračovat navždy. Běh 3, běh 4 a dále, dokud nebudou nalezeny všechny vady softwaru a software nebude bez chyb.

Pokud chceme pro tyto aktivity nakreslit vývojový diagram, bude vypadat zhruba takto:

Z výše uvedeného vývojového diagramu můžeme jasně usoudit, že testování může pokračovat, dokud nebudou nalezeny všechny vady softwaru.

Otázka však zní - je možné v softwaru najít každou jednotlivou vadu? Zkusme najít odpověď na tuto otázku za milion dolarů :).

Zastavení, když jsou nalezeny všechny vady: Je to možné?

Většina softwaru je složitá a má obrovský rozsah testování. Nelze najít všechny vady softwaru, ale bude to trvat věčně.

I po nalezení mnoha chyb v softwaru nikdo nyní nemůže zaručit, že software je bez vad. Nemůže nastat situace, kdy můžeme s jistotou říci, že jsme dokončili testování, našli všechny vady softwaru a ten již nemá žádné chyby.

Účelem testování navíc není najít všechny vady softwaru. Účelem testování softwaru je dokázat, že software funguje tak, jak bylo zamýšleno, a to rozbitím nebo nalezením odchylky mezi jeho aktuálním chováním a očekávaným chováním.

Software má neomezené vady, a proto je nepraktické jej testovat, dokud nenajdeme všechny vady, protože nikdy nemůžeme vědět, která vada je poslední. Pravdou je, že nemůžeme záviset na nalezení všech závad v softwaru, abychom mohli dokončit naše testování.

Upřímně řečeno, testování je nekonečné a testovací cykly budou pokračovat, dokud nebude rozhodnuto, kdy a kde přestat. Nyní je ještě komplikovanější dospět k rozhodnutí ukončit testování. Pokud „zastavení při zjištění všech vad“ není kritériem pro ukončení testování, na jakém základě by mělo být rozhodnuto?

Rozhodnutí o ukončení testování: Kritéria ukončení

Zkusme to pochopit - Jaké jsou nejdůležitější faktory, které je třeba vzít v úvahu při ukončení testovacích aktivit? Cítím, že rozhodnutí přestat s testováním většinou závisí Čas, rozpočet a rozsah testování.

Nejběžnějším přístupem je zastavení, když je čas / rozpočet vyčerpán nebo jsou provedeny všechny testovací scénáře. S tímto přístupem však budeme dělat kompromisy ohledně kvality testování, což neposkytne dostatečnou důvěru v software; jak?

Uvidíme spříklad.

Scénář testu:

Předpokládejme, že testujete softwarový modul. Byl vám přidělen určitý rozpočet na jeho pokrytí. Časové osy projektu jsou měsíc. Celkový počet testovacích scénářů je 200. Tento modul testujete pouze vy.

Scénář č. 1)

1. týden: Zjistíte závadu showstopper / závažnost 1 v den 1 a celé testování je blokováno po dobu 3 dnů. Z tohoto důvodu nejste schopni provést žádný ze scénářů, dokud nebude vyřešen nedostatek závažnosti 1. Po ztrátě 3 dnů je blokátor vyřešen a vy pokračujete v provádění.

Na konci týdne dokončíte 20 scénářů s několika důležitějšími prioritní vady .

2. týden: Začnete testovat software a více se zaměřujete na hledání vad. Během druhého týdne a na konci týdne otevřete několik dalších závad závažnosti 1, závažnosti 2 a závažnosti 3 a budete schopni pokrýt 70 scénářů.

3. týden: Na začátku 3^rdza týden vyřešíte všechny defekty s vysokou prioritou, takže spolu s provedením nevyřízených scénářů nyní musíte znovu otestovat všechny defekty, které přistály v testovacím segmentu. Pokračováním dobrého pokroku pokryjete 120 scénářů s dalšími vadami.

Do této doby jsou již všechny závady s vysokou prioritou nalezeny a nahlášeny. Takže nyní vám zbývají jen závady Závažnosti 3, které se mají najít.

4. týden: Do 4. týdne musíte znovu otestovat většinu otevřených vad a zbývajících 80 scénářů. S tímto do konce 4. týdne jste schopni dokončit až 180 scénářů se všemi defekty vysoké a střední priority opravenými a znovu otestovanými.

Uvedení těchto informací ve formě tabulky:

Měli byste se tady zastavit?

Důvod, který jste vyčerpali Čas testování úplně a nahlásili a opravili většinu vad s vysokou prioritou. Poskytne vám zastavení v tomto okamžiku důvěru v software? Ne opravdu kvůli níže uvedeným důvodům:

• Scénáře se nespouštějí úplně.
• Několik toků není testováno ani jednou.
• Všechny zahrnuté scénáře se provedou pouze jednou.
• Software má stále vady.
• Regrese není pokryta.

Scénář č. 2)

1. týden: Zjistíte závadu závažnosti 1 v den 1 a úplné testování je blokováno po dobu 3 dnů. Z tohoto důvodu nejste schopni provést žádný ze scénářů, dokud nebude vyřešen nedostatek závažnosti 1. Po ztrátě 3 dnů je blokátor vyřešen a vy pokračujete v provádění.

Na konci týdne dokončíte 20 scénářů s několika dalšími defekty. Tento týden zůstává stejný jako u scénáře 1.

2. týden: Během druhého týdne otevřete několik dalších závad závažnosti 1, závažnosti 2 a závažnosti 3, ale cílem je pokrýt více scénářů, které pokryjí nevyřízené položky z týdne 1. Na konci týdne budete moci pokrýt 120 scénářů.

3. týden: Na začátku 3^rdza týden vyřešíte všechny otevřené vady, takže spolu s provedením nevyřízených scénářů nyní musíte znovu otestovat všechny vady, které jsou uloženy v testovacím kbelíku. Na konci stále s dobrým pokrokem se počet dokončených scénářů změní na 200 s dalšími vadami.

Nyní můžete hlásit pouze závady závažnosti 2 a závažnosti 3.

Uvedení těchto informací ve formě tabulky:

Měli byste se tady zastavit?

Ty máš pokrylo všechny testovací scénáře úplně jednou a otevřeli několik zásadních vad. Poskytne vám zastavení v tomto okamžiku důvěru v software?

Ne opravdu kvůli níže uvedeným důvodům:

• Všechny scénáře se provedou pouze jednou.
• Software má stále mnoho závažných vad.
• Regrese není pokryta.

Vidíme, že v obou scénářích je kvalita ohrožena. Nejlepším přístupem bude nalezení bodu, kde jsou pokryty všechny faktory ze scénáře 1 a scénáře 2 a kvalita také není ohrožena. Abychom toho dosáhli, budeme muset na začátku testování definovat určitá kritéria.

Tato kritéria se označují jako kritéria dokončení nebo ukončení. Je to odpověď na naši otázku - 'Kdy zastavit testování?'

Co jsou kritéria dokončení nebo ukončení?

Kritéria ukončení se vyhodnotí na konci testovacího cyklu a jsou definována v plánu testování. Jedná se o soubor podmínek nebo činností, které musí být splněny, aby bylo možné dokončit testování.

Kritéria ukončení definují, kolik testování stačí a kdy lze testovací aktivity prohlásit za dokončené. Dosah a kritéria dokončení jsou kombinována a definují výstupní kritéria pro testování.

vyzkoušejte, kolik testů denně

Co by mělo být ve výstupních kritériích?

V ideálním případě je kritérium ukončení nebo zastavení definováno kombinací různých faktorů, a proto je jedinečné pro všechny projekty. Závisí to na požadavcích projektu, a proto by mělo být definováno během plánování testů; na začátku projektu. Parametry v něm definované by měly být co nejvíce kvantifikovány.

Níže je několik ukazatelů, které je třeba vzít v úvahu při definování výstupních kritérií v případě funkčního nebo systémového testování. Můžete kombinovat několik nebo všechny níže uvedené faktory při rozhodování o tom, kde zastavit testování podle potřeb vašeho projektu.

Testování lze zastavit, když:

Požadavky:

• Bylo dosaženo 100% pokrytí požadavků.

Vady:

• Bylo dosaženo počtu definovaných / požadovaných vad.
• Všechny chyby Zobrazit zátky nebo blokátory jsou opraveny a Žádná známá chyba Kritická / Závažnost 1 není v otevřeném stavu.
• Všechny vady s vysokou prioritou jsou identifikovány a opraveny.
• Míra vad klesne pod definovanou přijatelnou míru.
• Velmi málo defektů se střední prioritou je otevřených a má zavedené řešení.
• Velmi málo otevřených vad s nízkou prioritou, které nemají vliv na využití softwaru.
• Všechny defekty s vysokou prioritou jsou znovu testovány a uzavřeny a odpovídající scénáře regrese jsou úspěšně provedeny.

Pokrytí testu:

• Mělo by být dosaženo 95% pokrytí testu.
• Míra úspěšnosti testovacího případu by měla být 95%. To lze vypočítat podle vzorce
  • (Celkový počet úspěšných TC / Celkový počet TC) * 100.
• Všechny kritické testovací případy jsou předány.
• 5% testovacích případů může selhat, ale neúspěšné testovací případy mají nízkou prioritu.
• Je dosaženo úplného funkčního pokrytí.
• Všechny hlavní funkční / obchodní toky jsou úspěšně prováděny s různými vstupy a fungují dobře.

Termíny:

• Je dosaženo termínu projektu nebo termínu dokončení testu.

Zkušební dokumenty:

• Všechny zkušební dokumenty / výstupy (příklad - Souhrnná zpráva o testu ) jsou připravovány, recenzovány a publikovány napříč.

Rozpočet:

• Kompletní testovací rozpočet je vyčerpán.

Setkání „Go / No Go“:

• ' Go / No Go ' Setkání byla provedena se zúčastněnými stranami a bylo rozhodnuto, zda by projekt měl jít do výroby, nebo ne.

Závěr:

Pojďme si to na konci velmi zjednodušit.

Odpovězte prosím na otázky jednoduchým Ano nebo Ne.

Pokud získáte většinu odpovědí jako Ano, znamená to, že v tomto okamžiku můžete testování zastavit. Pokud je většina odpovědí Ne, znamená to, že musíte zkontrolovat, co při testování chybí, což vám pomůže najít unikající výrobní vadu :)

• Jsou všechny testovací případy provedeny alespoň jednou?
• Je míra úspěšnosti testovacího případu definována?
• Je dosaženo úplného pokrytí testu?
• Jsou všechny funkční / obchodní toky provedeny alespoň jednou?
• Je dosaženo rozhodnutého počtu vad?
• Jsou všechny hlavní vady s vysokou prioritou pevné a uzavřené?
• Byly všechny závady znovu otestovány a uzavřeny?
• Byla provedena regrese pro všechny otevřené vady?
• Vyčerpali jste rozpočet na testování?
• Byl dosažen čas ukončení testování?
• Jsou všechny výsledky testu zkontrolovány a zveřejněny?

O autorovi: Toto je hostující článek Renuky K. Má více než 11 let zkušeností s testováním softwaru.

Doufám, že vám tento článek pomohl. Také bych rád slyšel vaše myšlenky / komentáře k tématu.

Šťastné testování!

Doporučené čtení

• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Úloha pomocníka QA při testování softwaru
• Osnova kurzu testování softwaru - podrobný plán školení online
• Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
• Výběr testování softwaru jako vaší kariéry
• Práce na volné noze se softwarem pro testování technického obsahu Writer
• Některé zajímavé otázky týkající se testování softwaru
• Zpětná vazba a recenze kurzu testování softwaru