Menu

Kritéria pro ukončení testování

Abychom se vyhnuli předčasnému ukončení testování v situaci, kdy to ještě není vhodné, nebo naopak utrácení prostředků a času v situaci, kdy to už potřebné není, musíme definovat jasná kritéria, při jejichž splnění můžeme testování ukončit (tzv. výstupní kritéria, angl. exit criteria). Tato kritéria je potřeba stanovit pro každou úroveň testování.

Je to důležité hned z několika důvodů:

  • Potřebujeme nastavit jasný cíl testů
  • Jakmile jsou definovány podmínky pro konec úrovně testování, můžeme vůči těmto podmínkám měřit postup testů
  • Může předejít nesprávnému rozhodnutí pod tlakem. Investoři projektu mohou testování ukončit předčasně, pokud však máme jasně stanovená kritéria pro ukončení testování a všechny strany jsou s nimi seznámené, můžeme lépe upozornit na rizikovost takovéhoto rozhodnutí. V případě splnění kritérií můžeme také testování ukončit dříve s dřívějším předaním zákazníkovi

Obecně můžeme kritéria pro ukončení testování rozdělit do těchto kategorií:

  • Kritéria určující minimální testovací pokrytí (např. pokrytí požadavků)
  • Kritéria určující maximální počet defektů
  • Kritéria vztažené k procesu
  • Kritéria vztažené k ceně
  • Kritéria definovaná dalšími rozhodnutími managementu

Pojďme se na tato kritéria nyní podívat ve větším detailu:

Kritéria určující minimální testovací pokrytí

Každý testovací plán musí obsahovat specifikaci kritérií určujících minimální požadované pokrytí. Jedním ze základních poslání testování je informovat sponzory projektu o schopnostech a vlastnostech software. Pokud je úroveň testovacího pokrytí příliš nízká, testovací tým jednoduše nemá dostatek informací k formulaci kvalifikovaného doporučení pro investora projektu.

Příklad: Kritéria definující pokrytí pro jednotlivé úrovně testování mohou vypadat takto:

Úroveň testováníKritéria, které lze použít
Jednotkové testy (Unit testy)• Pokrytí řádek kódu
• Pokrytí větví v kódu
• Pokrytí rozhodovacích podmínek v kódu
Integrační testy• Přehled API, které musí být pokryté testy
• Kritérium pokrytí kombinací vstupních dat, se kterým mají být otestovány konkrétní API
Uživatelské akceptační testy• Pokrytí případů užití
• Pokrytí požadavků
• Pokrytí testů procesů (např. úroveň N-switch coverage nebo Test-depth level)

Kritéria určující maximální počet defektů

Kritéria určující maximální počet defektů přirozeně doplňují kritéria pro minimální úroveň testovacího pokrytí.
Kritéria definující minimální úroveň testovacího pokrytí zabezpečují, že testovací tým hledal chyby ve všech oblastech funkcionality, kde to jejich priorita vyžadovala a kritéria určující maximální počet defektů zaručují, že jsou nalezené chyby opravené.
I když nepracujete s testovacím týmem, který má zkušenost s testováním předchozí verze softwarového produktu, jež je aktuálně testované velice blízká ve všech ohledech, maximální možný počet defektů je možné odhadnout.
Můžete použít následující vodítko:

Chyby se závažností:Vyžadujte následující:
VysokáMusí být všechny opraveny
StředníPro všechny defekty, které nebudou včas opraveny musí být připraven plán řešení obsahující osobu (tým) odpovědnou za řešení, akci, která k vyřešení povede a termín, do kterého bude defekt vyřešen.
Zástupci investora (typicky business uživatelé) musí plán schválit.
NízkáDefinované procento defektů musí být opraveno do nasazení software do provozu.
Zbytek bude vyřešen do konce záruční doby.

Tip: Vždy doporučujeme oddělit kritéria pro minimální pokrytí a maximální počet defektů. Je to přehlednější, jednodušší na pochopení a daleko lépe specifikující tým, který za ty které kritéria odpovídá. Testovací tým se může lehce ztotožnit s kritérií určujícími minimální pokrytí a vývojový tým rychle vezme za své kritéria na maximální počet defektů. Minimalizuje se možnost výmluv na „ovlivnění výsledku“ někým jiným a zrychlí osvojení si odpovědnosti.

Kritéria vztažená k procesu

Kritéria vztažené k procesu mají v plánu své nezastupitelné místo. Zabraňují přehlédnutí nějakého procesního kroku, nebo výstupu v okamžiku, kdy pracujeme pod tlakem a ve stresu kvůli splnění termínů.
Příklady kritérií vztažených k procesu:

  • Vedení projektu formálně odsouhlasilo testovací report
  • Veškerá testovací dokumentace je uložena v projektové složce
  • Dodání všech výstupů testování bylo písemně potvrzeno jejich adresáty
Kritéria vztažené k ceně

Tyto kritéria jsou klíčová pro udržení rovnováhy mezi cenou za testy a potenciální cenou za neodhalené chyby.
S tím, jak se v průběhu testování opravami software zkvalitňuje, nachází testovací tým méně a méně defektů. Je to logické, defektů v systému zůstává méně, navíc (za podmínky správně nastaveného pokrytí) testovací tým nachází méně a méně závažné defekty. Náklady vynaložené na objevené defekty o určité závažnosti se tedy zvyšují, až dosáhnou bodu, kdy se další testování s ohledem na hodnotu objevených defektů již nevyplatí.

Příklad: Pokud testujeme datovou migraci, dává smysl skončit testy v okamžiku, kdy je korektně přemigrováno 97% dat. Náklady na další testování by totiž byly vyšší, než náklady na ruční migraci zbytku.

Typické komplikace při definici kritérií pro ukončení testování

Pokud testujeme rozsáhlý systém s velikým množstvím funkcí s různou úrovní kritičnosti, může být definice kritérií pro ukončení testování na začátku projektu náročná.
Rozhodnutí, zda je nebo není kvalita konkrétní části software již dostatečná je typicky výsledkem diskuzí různých zájmových skupin zapojených do projektu. V průběhu těchto diskuzí musí všichni účastníci zvážit množství faktorů:

  • Jaké části konkrétní části software fungují a jaké ne
  • Jaké jsou externí termíny, například kdy vstupuje v platnost nová legislativa, která vynucuje spuštění projektu
  • Dostupnost náhradních řešení
  • Pracnost související s náhradními řešeními
  • Cena za neúspěch, nebo zdržení projektu
  • Zdržení v souvisejících projektech
  • Nemožnost pokrýt obchodní příležitosti kvůli zdržení v dodávce systému
  • Dopady případného nesouladu systému se zákonnými regulacemi
  • Možné pokuty

V takovémto případě je lepši dospět k finálnímu stanovisku diskuzí a procesem rozhodování, než lpět na dopředu stanovených kritériích. Testovací tým poskytne pro tento rozhodovací proces argumentaci a k výsledku dojdeme diskuzí těchto argumentů v širším plénu, typicky na schůzce vedení projektu, nebo programu.

Vstupní (angl. Entry) kritéria pro začátek testování

Před začátkem testování každé testovací úrovně je nutné splnit určité kritéria a provést některé aktivity. Jejich potřeba nemusí být jasná každému, navíc můžou znamenat nezanedbatelné náklady, nebo pracnost. Pokud taková situace nastane, dbejte na její důslednou dokumentaci jak potřeb, které aktivity vyžadují, tak jejich důsledků.

A co si pod takovýmito aktivitami představit? Například:

  • Instalace funkcionalit do testovacího prostředí je úspěšně dokončena
  • Testovací prostředí je dostatečně stabilní a výkonné do míry, aby neomezovalo výkon testerů
  • Pro všechny testovatelné objekty testování jsou k dispozici testovací scénáře
  • Pro všechny testovací scénáře jsou připravené testovací data
  • Lidské zdroje alokované na testování jsou k dispozici
  • Dodaná funkcionalita je v testovatelném stavu – jsou opravené veškeré blokující defekty z předchozích úrovní testování

Příklad: Představte si projekt, kde je testovací tým zformován pozdě, až v době, kdy by už měla probíhat testovací analýza. Po sestavení týmu nezbývá čas na revizi podkladů pro testování (angl. Test Basis) a testovací tým se pustí rovnou do analýzy. Může se ale stát, že při analýze narazí na problémy s nízkou kvalitou vstupních dokumentů (požadavky, specifikace, manuály…)
Takovouto situaci je vhodné ošetřit vstupnými kritérií. Dokud nebudou mít podklady pro testování odpovídající kvalitu, není efektivní vytvářet testovací scénáře.

Kritéria pro pozastavení testování a požadavky pro obnovení testů

I v nejlépe naplánovaném projektu se můžou vyskytnout neočekávané okolnosti a pokračování v testování by bylo plýtváním peněz, či dalších zdrojů.
V této sekci popíšeme, jak takovýto okamžik rozeznat a jak naopak rozpoznat okamžik, od kterého může testování opět pokračovat.

Příklad: Dodavatelská firma, která má na starost vývoj software ve snaze stihnout termín dodávky přeskočila téměř veškeré testování. Testovací tým odběratele v dodaném software při prvních testech objevil množství defektů, které měly být zjevně odhalené ještě v průběhu dodavatelských testů.
Jelikož je v testovacím týmu odběratele řada specialistů na obchodní procesy organizace z řad budoucích uživatelů, pokračování v testech software postrádajícího základní funkčnost by bylo plýtváním jejich času.

ISTQB popisuje zádržná kritéria jako kritéria, sloužící pro pozastavení části, nebo všech testovacích aktivit.
Stejně tak popisuje požadavky pro pokračování testů jako testovací aktivity, které je nutné zopakovat, když v testech, které jsme pozastavili, opětovně pokračujeme.

K takovým situacím může dojít, například, když:

  • Testovací tým čeká na okamžik, až jiný tým dokončí svoji práci, nebo doběhne proces, na kterém testování závisí
  • Výkon testovacího týmu je výrazně nižší, než bylo předpokládáno v plánu a domluveno
  • Pokud až v průběhu testů zjistíme, že výkon nového systému je neakceptovatelný a systém má pro testování příliš velké odezvy

V reálném životě se v průběhu projektu objeví řada rizik, které testování ohrozí, nicméně jejich včasná identifikace, eskalace a řešení zamezí tomu, aby přerostly do incidentů. Pro tyto rizika zádržná kritéria nepotřebujeme.
Nicméně, na některé incidenty nás dopředu nic neupozorní a přijdeme na ně až v průběhu testování. Proto nám nezbývá nic jiného, než být připravený na to, že v případě nutnosti testování pozastavíme (aktivace zádržných kritérií).

Příklad: Testovací tým předpokládá, že 85% všech defektů bude opraveno napoprvé (to znamená, že jejich přetestování proběhne úspěšně). Skutečná úspěšnost opravy chyb ale nejde zjistit jinak, než že se pustíme do testování a proto je takovýto předpoklad ideálním kandidátem na ošetření pomocí zádržných kritérií – není efektivní dále testovat, pokud nebude požadovaný podíl chyb opraven.

Jak popsat zádržná kritéria:

Pro každé z identifikovaných zádržných kritérií definujte:

  • Popis kritéria
  • Proč jsou jeho parametry důležité – stačí stručné zdůvodnění
  • Jak zjistíte, že situace popsaná v kritériu nastala
  • Co bude testovací tým dělat, pokud kritéria dosáhneme
  • Jak dlouho bude trvat mimořádný režim
  • Koho je nutné informovat
  • Kdy obnovíme běžné aktivity
  • Jaké aktivity je po obnovení normální aktivity zopakovat a jaký je pro tyto aktivity odhad pracnosti

Existuje několik druhů zádržných aktivit:

  • Zastavení všech testovacích aktivit
  • „Zastavení stopek“
  • Zastavení testovacích aktivit pouze v určitých oblastech

Zastavení všech testovacích aktivit
Výhodou tohoto druhu aktivity je její jednoznačnost a přehlednost. Pokud říkáme, že zastavujeme veškeré testovací aktivity, je to jednoduše pochopitelné pro všechny osoby zúčastněné na projektu. Neplýtvá se časem, jelikož testeři nečekají na to, až se situace zlepší. Abychom toto řešení ale mohli prakticky využít, testeři musí mít jinou alternativní práci po dobu přerušení testovacích aktivit.

Příklad: Organizace outsourcuje veškerý vývoj na projektu na externího dodavatele a provádí pouze akceptační testování na finálním produktu. Součástí smlouvy je, že odběratel provede jedno akceptační testování hned po dodání. Pokud je testování neúspěšné, je další testování na straně odběratele pozdrženo do doby, než dodavatel dodá opravu a odběratel provede (tentokrát už úspěšné) akceptační testování. Nicméně, odběratel hradí náklady pouze na první kolo akceptačního testování. Každé další kolo jde k tíze dodavatele.

Zjevnou nevýhodou této varianty je čas a úsilí, které je potřeba k obnovení testovacích aktivit. Není jednoduché opětovně sestavit testovací tým a namotivovat ho tak, aby dosahoval požadované výkonnosti.

Jednou z možností jak tuto možnost zjednodušit je definice minimálního intervalu mezi testovacími okny. Například: Dodavatelský (vývojový) tým nemůže požadovat nové testovací okno v 4 až 6ti týdnech po neúspěšném akceptačním testu.

To testovacímu manažerovi dává dostatek času na reorganizaci potřebných testerů. Zároveň to motivuje dodavatelský tým k tomu, aby příští dodávku dodal kvalitně napoprvé – speciálně v okamžiku, kdy je úspěšný akceptační test zároveň platebním milníkem pro platbu za dodávku.

To vše je ale možné pouze v okamžiku, kdy jsou tyto pravidla součástí kontraktu. Jako testeři nepodceňujte proto fázi přípravy kontraktu a aktivně do ní vstupujte!

„Zastavení stopek“
Kompletní zastavení testovacích aktivit je v praxi často těžce dosažitelné. Odhlédneme-li od požadavků na smluvní úpravu podmínek, často je taková situace neakceptovatelná i ze strany projektového manažera.
Ten může mít řadu důvodů, proč testovací aktivity kompletně nezastavit, například:

  • Externí testeři jsou nasmlouvaní na určité období a stejně by je bylo nutné zaplatit
  • Bylo velmi náročné získat plnou pozornost a kapacitu business expertů pro testy a příště by to bylo ještě složitější
  • Pokud se blíží datum nasazení do produkce, nicnedělání není sponzory akceptovatelné
  • Projekt je jednoznačně mimo plán a kontrolu a zpětná vazba od testerů je nepostradatelná k tomu, abychom ho pod kontrolu dostali

Ačkoliv výše uvedené důvody jsou pochopitelné, nic to nemění na tom, že manažer testování je postaven do velice složité situace: Testovací tým musí pracovat ve ztížených podmínkách, členové týmu jsou demotivováni, často uvažují nad tím, že „někdo jiný neudělal svoji práci pořádně“ a musí se s tím vypořádat.
Je proto pochopitelné, že v takovéto situaci je těžké dodržet rozpočet a harmonogram vyhrazený na testování.

Dobrým kompromisem v takovéto situaci může být „Zastavení stopek“:

  • Testovací tým pokračuje v hlášení defektů, nicméně opouští naplánovanou sadu testovacích scénářů a zaměří se na průzkumné testování (angl. Exploratory Testing), nebo ad-hoc testování
  • Čas a prostředky použité v tomto módu nejsou považovány za součást odhadů. Test manažer proto nemůže být odpovědný za vzniklou situaci, která je mimo jeho plán
  • V okamžiku, kdy dojde ke zlepšení situace na projektu, obnoví testovací tým standardní režim práce dle plánu
  • Pokud je termín nasazení do produkce pevně daný, může být nutné revidovat priority, aby došlo ke kompenzaci ztraceného času pro testování

Zastavení testovacích aktivit pouze v určitých oblastech

Dříve, než zastavíte všechny testovací aktivity, zkuste se zamyslet nad tím, zda nelze vyřešit problém změnou pořadí testovacích aktivit. Pokud jsou potíže lokalizované do určité oblasti dodávky je to často možné, navíc takovéto limitované zastavení aktivit má mnohem menší dopad na harmonogram a rozpočet projektu, než zastavení všech testovacích aktivit.

Pokud máte zvládnutý monitoring, odhady a kontrolu testování, dokážete celkem přesně odhadnout, jak dlouho bude mít testovací tým „co dělat“ než dojdeme k bodu, kdy bude moci pracovat už pouze na zablokovaných oblastech.
Takovýto odhad může dopomoct například ke zjištění, že oprava nemusí být dodaná do druhého dne, ale vývojový tým může pracovat delší čas na opravdu kvalitním a permanentním řešení.

Požadavky pro obnovení testů

Předtím, než obnovíme testování, může být nutné provést některé aktivity. Jejich potřeba nemusí být jasná každému, navíc můžou znamenat nezanedbatelné náklady, nebo pracnost. Pokud taková situace nastane, dbejte na její důslednou dokumentaci jak potřeb, které aktivity vyžadují, tak jejich důsledků.

A co si pod takovýmito aktivitami představit? Například:

  • Přeplánování zapojení business testerů – může se stát, že budou moci být zapojeni až později, nebo jejich kapacitu pro testování nezískáme vůbec kvůli zvýšenému vytížení jejich primárními business aktivitami
  • Regresní testování nově dodaného systému
  • Přeplánování nového testovacího okna po domluvě s externím dodavatelem
  • Úprava dat v systémech – obnovení dat ze zálohy, migrace dat…
  • Znovuvytvoření transakcí, jejichž platnost vypršela

Comments

Dear user, this website uses cookies to ensure you get the best experience on our website. More about cookies
I give my consent to processing of my personal data. More info