Lekce 11 - Management testování

V předchozí lekci, Přístupy k testování založené na spolupráci, jsme si ukázali poslední techniku – přístupy k testování založené na spolupráci, které zahrnují společné psaní uživatelských scénářů, akceptační kritéria a vývoj řízený akceptačními testy.

V dnešní lekci základů testování softwaru se detailněji zaměříme na test planning, projdeme si přínos testerů při plánování iterací a vstupní i výstupní kritéria. Ukážeme si techniky pro odhadování, nevynecháme ani prioritizaci test casů a nakonec probereme testovací pyramidu a testovací kvadranty.

Test planning

Plán testování stanovuje cíle, zdroje a procesy pro testování projektu. Takový plán pak obsahuje:

• způsob dosažení cílů a harmonogram testování,
• zajištění splnění testovacích kritérií,
• komunikaci s týmem a zainteresovanými stranami,
• soulad s politikou a strategií testování.

Test planning pomáhá testerům při řešení výzev souvisejících s riziky, harmonogramy, zdroji a náklady:

Slouží jako nástroj k analýze pracnosti potřebné k dosažení testovacích cílů. Obvykle zahrnuje:

• kontext testování,
• předpoklady a omezení testovacího projektu,
• definici zainteresovaných stran,
• plán komunikace,
• registr rizik,
• přístup k testování,
• rozpočet a harmonogram.

Přínos testerů při plánování iterací a vydání

V iterative development modelech SDLC existují dva hlavní druhy plánování – plánování vydání a plánování iterace.

Plánování vydání se zaměřuje na budoucí vydání produktu, definuje a upravuje produktový backlog a rozděluje větší uživatelské scénáře na menší části. Tento proces je základem pro definici přístupu k testování a plánu testování napříč všemi iteracemi. Testeři se podílejí na specifikaci testovatelných uživatelských scénářů, tvorbě acceptance kritérií, analýze projektových a produktových rizik, odhadech pracnosti a test planningu souvisejícího s vydáním. Tester například spolupracuje s týmem na rozdělení komplexních uživatelských scénářů do menších, snadno testovatelných částí. Během plánování tester také navrhuje acceptance criteria, která budou použita k ověření správnosti každé části produktu.

Plánování iterace se zaměřuje na dokončení jedné iterace a pracuje s backlogem iterace. Testeři zde provádějí podrobnou analýzu rizik, stanovují testovatelnost uživatelských scénářů, rozkládají scénáře na úkoly, odhadují pracnost testování a přispívají k přesnému určení funkcionálních či nefunkcionálních aspektů testovaného objektu. Tester například rozděluje uživatelské scénáře na konkrétní testovací úkoly a odhaduje potřebný čas k jejich provedení. Zároveň analyzuje potenciální rizika spojená s testováním, aby zajistil efektivní průběh iterace.

Vstupní a výstupní kritéria

Vstupní kritéria jsou podmínky, které musí být splněny před zahájením testovací činnosti. Pokud nejsou kritéria splněna, testování může být obtížnější, časově náročnější a rizikovější. Typická vstupní kritéria zahrnují dostupnost zdrojů, testwaru a počáteční úroveň kvality testovaného objektu:

Výstupní kritéria stanovují podmínky, které musí být dosaženy, aby bylo možné testování ukončit. Patří mezi ně míra důkladnosti, kritéria dokončení, případně vyčerpání času nebo finančních prostředků, přičemž rizika jsou akceptována zainteresovanými stranami.

V agile developmentu se výstupní kritéria označují jako definice hotového a vstupní kritéria jako definice připravenosti. Tato kritéria by měla být stanovena pro každou úroveň testování a mohou se lišit podle cílů testu.

Techniky pro odhadování

Odhad pracnosti testování představuje očekávané množství práce potřebné k dosažení cílů testování v projektu. Je důležité upozornit, že odhady vycházejí z momentálních předpokladů a mohou být zatíženy chybou. Odhady pro menší úkoly bývají přesnější, proto je vhodné rozdělit rozsáhlé úkoly na drobnější. Existují čtyři hlavní techniky odhadování.

Odhad na základě poměrů využívá metriky z předchozích projektů, aby odvodil poměry pro projekt nový. Pokud vývoj trval například 600 člověkodnů a testování v předchozích projektech mělo k vývoji poměr 2 : 3, lze testování odhadnout na 400 člověkodnů.

Extrapolace je založená na metrikách z aktuálního projektu, kde se brzy začínají měřit data. Tyto údaje se poté extrapolují, například podle průměrné pracnosti z předchozích iterací v iterative development modelu SDLC.

Wideband Delphi je technika, u které experti odhadují pracnost nezávisle. Odhady se porovnávají, diskutují se rozdíly a proces se opakuje, dokud není dosaženo shody. Variantou je plánovací poker, běžný v agile developmentu, kde se používají karty s čísly symbolizujícími rozsah pracnosti.

Tříbodový odhad je technika, při které experti poskytují tři odhady: nejoptimističtější (a), nejpravděpodobnější (m) a nejpesimističtější (b). Výsledný odhad (E) se vypočítá jako vážený aritmetický průměr:

E = (a + 4 * m + b) / 6

Výhodou této metody je, že umožňuje expertům vypočítat chybu měření, a to obvykle ve formě směrodatné odchylky. Ta se vypočítá vzorcem:

SD = (b - a) / 6

Je-li tedy například nejoptimističtější odhad a = 6, nejpravděpodobnější odhad m = 9 a nejpesimističtější odhad b = 18, výsledný odhad je pak E = 10 člověkohodin a směrodatná odchylka SD = 2, což znamená rozsah od 8 do 12 člověkohodin, protože:

E = (6 + 4 * 9 + 18) / 6 = 10

a

SD = (18 - 6) / 6 = 2

Prioritizace test casů

Po vytvoření a sestavení test casů do testovacích sad je třeba určit pořadí spouštění na základě různých faktorů:

Mezi nejčastěji používané strategie prioritizace patří:

• Prioritizace na základě rizik, kde jsou testy seřazeny podle rizikové analýzy, přičemž nejprve se spouštějí testy pokrývající nejdůležitější rizika.
• Prioritizace na základě pokrytí, kde se test casy, které dosahují nejvyššího pokrytí, provádějí jako první. Následují testy, které přinášejí největší dodatečné pokrytí.
• Prioritizace na základě požadavků, kde jsou testy řazeny podle priorit požadavků definovaných zainteresovanými stranami. Test casy související s nejdůležitějšími požadavky jsou prováděny jako první.

Praktický příklad

Představme si tým, který testuje novou funkci platební brány e-shopu. Nejprve se provádějí testy související s bezpečnostními riziky, jako je ochrana platebních údajů, tedy dle prioritizace na základě rizik. Následně jsou dle prioritizace na základě pokrytí spuštěny testy, které pokrývají co nejvíce různých platebních metod. A nakonec jsou testovány méně kritické požadavky s nižší prioritou, jako je například rychlost zpracování platby, a sice dle prioritizace na základě požadavků.

Navzdory tomu, že by se testy měly v ideálním případě provádět podle jejich priority, pořadí mohou ovlivnit závislosti mezi testy. Například test s vyšší prioritou může záviset na testu s nižší prioritou, který proto musí být proveden nejdříve. Také je nutné zohlednit dostupnost zdrojů, jako jsou testovací nástroje, prostředí nebo kapacita týmových členů.

Testing pyramid

Testing pyramid (testovací pyramida) je model, který ukazuje různou granularitu testů a pomáhá určit vhodný poměr automatizovaných testů. Umožňuje týmům rozložit pracnost v různých úrovních automatizace a dosáhnout cílů každé úrovně:

Spodní vrstva pyramidy obsahuje malé, izolované a rychlé testy, které ověřují jednotlivé části funkcionality. Obvykle je jich pro dosažení rozumného pokrytí potřeba velké množství.

Horní vrstva pyramidy obsahuje komplexní end-to-end (E2E) testy, které jsou pomalejší a ověřují větší část funkcionality. Pro pokrytí stačí jen několik takových testů.

Model pyramidy se může lišit podle projektu. Původní model zahrnuje tři vrstvy, zatímco jiné modely mohou zahrnovat jednotkové testy, component integration testing či end-to-end testy.

Praktický příklad

Představme si vývoj týmu, který pracuje na webové aplikaci pro online nákupy. Tým používá testing pyramid k definování správného poměru automatických testů. Spodní vrstvu tvoří jednotkové testy (unit tests). Tým má velké množství jednotkových testů, které ověřují malé části kódu, například funkci pro výpočet celkové ceny objednávky po aplikaci slevy. Jednotkové testy jsou rychlé, izolované a zaměřují se na správnost jednotlivých metod.

Střední vrstvu tvoří component integration tests. Integrační testy ověřují správnou interakci mezi komponentami. Tým testuje, zda modul pro přidání položek do košíku správně komunikuje s platebním modulem. Těchto testů je méně než jednotkových, ale stále jsou klíčové pro ověření vzájemné spolupráce částí systému.

Horní vrstvu potom tvoří end-to-end testy. Tým jich má několik. Simulují kompletní proces nákupu od přidání položek do košíku až po úspěšné dokončení platby. Tyto testy jsou nejpomalejší, protože ověřují celý proces a interakci mezi všemi komponentami systému. Testing pyramid v tomto příkladu zajišťuje, že většina testů je rychlá a efektivní, zatímco několik end-to-end testů pokrývá kritické scénáře na vyšší úrovni.

Testing quadrants

Testing quadrants (testovací kvadranty), definované Brianem Marickem, spojují úrovně testování s příslušnými typy testů, technikami a pracovními produkty v agile developmentu. Tento model pomáhá managementu testování zajistit, aby všechny relevantní typy a úrovně testů byly zahrnuty do SDLC, a umožňuje testerům lépe pochopit, které testy jsou pro určité úrovně vhodnější:

Model rozlišuje testy podle osy Y (byznysové nebo technologické zaměření) a osy X (testy zaměřené na podporu týmu nebo kritiku produktu), což vytváří čtyři kvadranty:

• Kvadrant Q1 – Obsahuje component testing a component integration tests. Tyto testy jsou automatizované a začleněné do procesu CI. Například při každém odeslání změn do repozitáře se automaticky spouští testy, které ověřují správnou funkčnost jednotlivých modulů aplikace. Jde tedy např. o kontrolu správného výpočtu cen objednávek.
• Kvadrant Q2 – Zahrnuje functional testing, příklady, testy uživatelských scénářů, UX prototypy, testování API a simulace. Testy ověřují acceptance criteria a mohou být manuální i automatizované. Tester zde kupř. ručně ověřuje, zda uživatel může dokončit celý proces nákupu na e-shopu, včetně přidání produktu do košíku a platby, a to dle acceptance kritérií.
• Kvadrant Q3 – Zaměřuje se na exploratory testing, testování použitelnosti a uživatelské acceptance testy. Tyto testy jsou obvykle manuální a orientované na uživatele. Tester například zkoumá novou mobilní aplikaci pro rezervace restaurací a hledá případné nedostatky v uživatelském rozhraní, jako jsou nejasné navigační prvky.
• Kvadrant Q4 – Obsahuje smoke testy a nefunkcionální testy, často automatizované. Před nasazením nové verze aplikace do produkce se automaticky spouští výkonové testy, aby se ověřilo, že systém zvládne vysokou zátěž uživatelů.

Zdrojem této lekce jsou Učební osnovy – Certifikovaný tester základní úrovně ver. 4.0. Copyright © 2023 autoři verze 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (předseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (místopředseda), Eshraka Zakaria

V příští lekci, Management rizik, se detailněji zaměříme na definici rizika a jeho atributy, rozlišíme si projektová a produktová rizika a také si ukážeme, co je to analýza a řízení produktových rizik. Ve druhé části se zaměříme na metriky používané v testování a také na účel, obsah a cílové skupiny reportů z testování.