Lekce 10 - Přístupy k testování založené na spolupráci

V předchozím kvízu, Kvíz - Revize, návrh testů a white-box testing, jsme si ověřili nabyté zkušenosti z předchozích lekcí.

V dnešní lekci o přístupech testování založených na spolupráci si ukážeme poslední techniku testování. Podíváme se na společné psaní uživatelských scénářů, probereme si acceptance criteria a acceptance test-driven development.

Přístupy collaborative testingu

Každá z předchozích technik testování má za cíl identifikaci defektů, přístupy collaborative testingu (testování založeného na spolupráci) se namísto toho zaměřují spíše na prevenci výskytu defektů. Tyto přístupy využívají spolupráci a komunikaci k dosažení lepších výsledků v oblasti kvality softwaru.

Společné psaní uživatelských scénářů

Uživatelský scénář popisuje funkci softwaru, která má pro uživatele nebo vlastníka softwaru určitou hodnotu:

Uživatelské scénáře jsou strukturovány podle tzv. 3C:

• karta (card) – médium popisující uživatelský scénář,
• konverzace (conversation) – vysvětlení, jak bude software používán,
• potvrzení (confirmation) – acceptance criteria pro ověření správnosti scénáře.

Typický formát uživatelského scénáře je:

Jako [ROLE] chci, aby [CÍL], protože [byznysová HODNOTA].

Spolu s tím jsou stanovena acceptance criteria. Společné psaní scénářů může zahrnovat techniky jako brainstorming nebo tvorba myšlenkových map a podporuje týmovou spolupráci mezi byznysem, vývojem a testováním, což vede k jasnější vizi cíle projektu.

INVEST princip

INVEST princip slouží jako vodítko ke tvorbě správných scénářů. Scénáře by měly být:

• nezávislé (Independent),
• schůdné (Negotiable),
• hodnotné (Valuable),
• odhadnutelné (Estimable),
• malé (Small),
• testovatelné (Testable).

Pokud není scénář jasný nebo jej nelze snadno otestovat, může to naznačovat, že scénář není dostatečně specifický, nemá pro zainteresované strany hodnotu nebo je zapotřebí pomoct stranám s definováním způsobu testování.

Praktický příklad

Karta:

Jako správce e-shopu chci mít možnost upravit ceny produktů hromadně, protože to zrychlí proces aktualizace cen a sníží manuální chyby.

Konverzace:

Správce e-shopu bude potřebovat možnost vybrat skupinu produktů podle různých filtrů (např. kategorie, značka, skladová dostupnost) a provést hromadnou změnu cen jedním kliknutím. Software by měl umožnit nastavit různé typy změn cen (procentuální sleva, pevná částka) a zobrazit přehled o provedených změnách. Uživatel by měl být schopen akci potvrdit před jejím definitivním provedením.

Potvrzení:

• Správce může filtrovat produkty podle kategorií, značek a skladové dostupnosti.
• Správce může aplikovat hromadnou změnu cen na vybranou skupinu produktů.
• Správce musí vidět náhled změn před jejich potvrzením.
• Po potvrzení se ceny produktů aktualizují a systém zaznamená, kdo a kdy změny provedl.

Acceptance criteria

Acceptance criteria jsou podmínky, které musí být splněny, aby byla implementace uživatelského scénáře přijata zainteresovanými stranami. Fungují jako testovací podmínky, které je třeba prověřit během testování. Acceptance criteria vznikají na základě konverzace a slouží k:

• definování rozsahu uživatelského scénáře,
• dosažení shody mezi zainteresovanými stranami,
• popisu pozitivních i negativních scénářů,
• stanovení základní definice acceptance testingu,
• přesnějšímu test planningu a odhadování testování.

Nejběžnějšími formáty acceptance kritérií jsou ty, jež se orientují na scénáře, a ty, které se orientují na pravidla. Tyto formáty umožňují dokumentovat většinu acceptance kritérií, ale lze využít i jiné, jsou-li kritéria dobře definovaná a jednoznačná.

Praktický příklad

Představme si tým, který vyvíjí aplikaci pro rezervaci hotelů a pracuje na funkci pro vyhledávání dostupných pokojů.

Jako uživatel chceme vyhledat dostupné hotelové pokoje v určitém městě a datu, abychom si mohli rezervovat ubytování.

Formát orientovaný na scénáře:

• Pozitivní scénář – Uživatel zadá platné město, datum příjezdu i odjezdu. Systém zobrazí seznam dostupných hotelových pokojů pro zadané období.
• Negativní scénář – Uživatel zadá neexistující město nebo uplynulý termín. Systém zobrazí chybovou zprávu „Žádné dostupné pokoje pro zadané parametry“.

Formát orientovaný na pravidla:

• Systém musí vyhledat dostupné pokoje na základě zadaného města a termínu.
• Systém zobrazí chybovou zprávu, pokud není nalezen žádný pokoj nebo pokud jsou vstupní údaje neplatné.

Acceptance test-driven development

Acceptance test-driven development (ATDD) je přístup, kde jsou test casy vytvořeny před implementací uživatelského scénáře. Týmy složené z různých členů, jako jsou zákazníci, vývojáři či testeři, společně připravují testy, které mohou být prováděny manuálně nebo automatizovaně.

Prvním krokem je obvykle schůzka nad specifikacemi, kde tým analyzuje a dokumentuje uživatelské scénáře a jejich acceptance criteria. Tento proces pomáhá odstranit nejasnosti, nejednoznačnosti či defekty ve scénářích.

Následuje vytvoření test casů, což může provádět celý tým nebo pouze testeři. Testy jsou založeny na acceptance kritériích a slouží jako příklady správného chování softwaru. První test casy jsou obvykle pozitivní, tedy zaměřené na potvrzení správného chování, a pokrývají případy bez výjimečných situací. Po těchto případech tým vytváří negativní testy a testy zaměřené na nefunkční požadavky.

Test casy by měly být srozumitelné pro všechny zainteresované strany a měly by popisovat vstupní podmínky, vstupy a výstupní podmínky. Důležité je, aby každý test case pokrýval jiný aspekt uživatelského scénáře a nepřekračoval jeho rámec.

Pokud jsou acceptance criteria popsána ve formátu podporovaném automatizačním nástrojem, mohou vývojáři testy automatizovat současně s implementací. V takovém případě se acceptance tests stávají spustitelnými požadavky, které jsou součástí procesu vývoje.

Praktický příklad

Tým pracuje na nové funkci e-shopu, která má automaticky poskytovat 10% slevu při nákupu nad 1000 Kč.

Na schůzce se zástupci byznysu vývojáři a testeři upřesní požadavky.

Hlavní scénář – Zákazník nakoupí za více než 1000 Kč a dostane automaticky slevu.

Pozitivní test – Zákazník nakoupí zboží za 1200 Kč, systém aplikuje 10% slevu a zákazník zaplatí 1080 Kč.

Negativní test – Zákazník nakoupí za 950 Kč, sleva se neaplikuje.

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 testování, se detailněji zaměříme na plánování testování, 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 testovacích případů a nakonec probereme testovací pyramidu a kvadranty.