10. diel - Prístupy k testovaniu založenému na spolupráci

V predchádzajúcom kvíze, Kvíz - Revízia, návrh testov a white-box testing, sme si overili nadobudnuté skúsenosti z predchádzajúcich lekcií.

V dnešnej lekcii o prístupoch testovania založených na spolupráci si ukážeme poslednú techniku testovania. Pozrieme sa na spoločné písanie užívateľských scenárov, preberieme si acceptance criteria a acceptance test-driven development.

Prístupy collaborative testingu

Cieľom každej z predchádzajúcich techník testovania je identifikáciu defektov, prístupy collaborative testingu (testovania založeného na spolupráci) sa namiesto toho zameriavajú skôr na prevenciu výskytu defektov. Tieto prístupy využívajú spoluprácu a komunikáciu na dosiahnutie lepších výsledkov v oblasti kvality softvéru.

Spoločné písanie užívateľských scenárov

Užívateľský scenár popisuje funkciu softvéru, ktorá má pre používateľa alebo vlastníka softvéru určitú hodnotu:

Užívateľské scenáre sú štruktúrované podľa tzv. 3C:

• karta (card) – médium popisujúce užívateľský scenár,
• konverzácia (conversation) – vysvetlenie, ako bude softvér používaný,
• potvrdenie (confirmation) – acceptance criteria pre overenie správnosti scenára.

Typický formát užívateľského scenára je:

As [ROLE], I want to [OBJECTIVE] because [business VALUE].

Spolu s tým sú stanovené acceptance criteria. Spoločné písanie scenárov môže zahŕňať techniky ako brainstorming alebo tvorba myšlienkových máp a podporuje tímovú spoluprácu medzi biznisom, vývojom a testovaním, čo vedie k jasnejšej vízii cieľa projektu.

Princíp INVEST

Princíp INVEST slúži ako návod k tvorbe správnych scenárov. Scenáre by mali byť:

• nezávislé (Independent),
• diskutovateľné (Negotiable),
• hodnotné (Valuable),
• odhadnuteľné (Estimable),
• malé (Small),
• testovateľné (Testable).

Ak nie je scenár jasný alebo ho nemožno ľahko otestovať, môže to naznačovať, že scenár nie je dostatočne špecifický, nemá pre zainteresované strany hodnotu alebo je potrebné pomôcť stranám s definovaním spôsobu testovania.

Praktický príklad

Karta:

Ako správca e-shopu chcem mať možnosť upraviť ceny produktov hromadne, pretože to zrýchli proces aktualizácie cien a zníži manuálne chyby.

Konverzácia:

Správca e-shopu bude potrebovať možnosť vybrať skupinu produktov podľa rôznych filtrov (napr. kategória, značka, skladová dostupnosť) a vykonať hromadnú zmenu cien jedným kliknutím. Softvér by mal umožniť nastaviť rôzne typy zmien cien (percentuálna zľava, pevná čiastka) a zobraziť prehľad o vykonaných zmenách. Užívateľ by mal byť schopný akciu potvrdiť pred jej definitívnym prevedením.

Potvrdenie:

• Správca môže filtrovať produkty podľa kategórií, značiek a skladovej dostupnosti.
• Správca môže aplikovať hromadnú zmenu cien na vybranú skupinu produktov.
• Správca musí vidieť náhľad zmien pred ich potvrdením.
• Po potvrdení sa ceny produktov aktualizujú a systém zaznamená, kto a kedy zmeny vykonal.

Acceptance criteria

Acceptance criteria sú podmienky, ktoré musia byť splnené, aby bola implementácia užívateľského scenára prijatá zainteresovanými stranami Fungujú ako testovacie podmienky, ktoré je potrebné preveriť počas testovania. Acceptance criteria vznikajú na základe konverzácie a slúžia na:

• definovanie rozsahu užívateľského scenára,
• dosiahnutie zhody medzi zainteresovanými stranami,
• popis pozitívnych aj negatívnych scenárov,
• stanovenie základnej definície acceptance testingu,
• presnejší test planning a odhadovanie testovania.

Najbežnejšími formátmi acceptance kritérií sú tie, ktoré sa orientujú na scenáre, a tie, ktoré sa orientujú na pravidlá. Tieto formáty umožňujú dokumentovať väčšinu acceptance kritérií, ale je možné využiť aj iné, ak sú kritériá dobre definované a jednoznačné.

Praktický príklad

Predstavme si tím, ktorý vyvíja aplikáciu na rezerváciu hotelov a pracuje na funkcii na vyhľadávanie dostupných izieb.

Ako užívateľ chceme vyhľadať dostupné hotelové izby v určitom meste a dátume, aby sme si mohli rezervovať ubytovanie.

Formát orientovaný na scenáre:

• Pozitívny scenár – Užívateľ zadá platné mesto, dátum príchodu aj odchodu. Systém zobrazí zoznam dostupných hotelových izieb pre zadané obdobie.
• Negatívny scenár – Užívateľ zadá neexistujúce mesto alebo uplynulý termín. Systém zobrazí chybovú správu "Žiadne dostupné izby pre zadané parametre".

Formát orientovaný na pravidlá:

• Systém musí vyhľadať dostupné izby na základe zadaného mesta a termínu.
• Systém zobrazí chybovú správu, ak nie je nájdená žiadna izba alebo ak sú vstupné údaje neplatné.

Acceptance test-driven development

Acceptance test-driven development (ATDD) je prístup, kde sú test casy vytvorené pred implementáciou užívateľského scenára. Tímy zložené z rôznych členov, ako sú zákazníci, vývojári či testeri, spoločne pripravujú testy, ktoré môžu byť vykonávané manuálne alebo automatizovane.

Prvým krokom je zvyčajne schôdzka ohľadom špecifikácií, kde tím analyzuje a dokumentuje užívateľské scenáre a ich acceptance criteria. Tento proces pomáha odstrániť nejasnosti, nejednoznačnosti či defekty v scenároch.

Nasleduje vytvorenie test casov, čo môže vykonávať celý tím alebo iba testeri. Testy sú založené na acceptance kritériách a slúžia ako príklady správneho správania softvéru. Prvé test casy sú zvyčajne pozitívne, teda zamerané na potvrdenie správneho správania, a pokrývajú prípady bez výnimočných situácií. Po týchto prípadoch tím vytvára negatívne testy a testy zamerané na nefunkčné požiadavky.

Test casy by mali byť zrozumiteľné pre všetky zainteresované strany a mali by popisovať vstupné podmienky, vstupy a výstupné podmienky. Dôležité je, aby každý test case pokrýval iný aspekt užívateľského scenára a neprekračoval jeho rámec.

Ak sú acceptance criteria popísané vo formáte podporovanom automatizačným nástrojom, môžu vývojári testy automatizovať súčasne s implementáciou. V takom prípade sa acceptance tests stávajú spustiteľnými požiadavkami, ktoré sú súčasťou procesu vývoja.

Praktický príklad

Tím pracuje na novej funkcii e-shopu, ktorá má automaticky poskytovať 10% zľavu pri nákupe nad 40 EUR.

Na schôdzke so zástupcami biznisu vývojári a testeri upresnia požiadavky.

Hlavný scenár – Zákazník nakúpi za viac ako 40 EUR a dostane automaticky zľavu.

Pozitívny test – Zákazník nakúpi tovar za 50 EUR, systém aplikuje 10% zľavu a zákazník zaplatí 45 EUR.

Negatívny test – Zákazník nakúpi za 39 EUR, zľava sa neaplikuje.

Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 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 (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V nasledujúcej lekcii, Manažment testovania, sa detailnejšie zameriame na plánovanie testovania, prejdeme si prínos testerov pri plánovaní iterácií a vstupné aj výstupné kritériá. Ukážeme si techniky na odhadovanie, nevynecháme ani prioritizáciu testovacích prípadov a nakoniec preberieme testovaciu pyramídu a kvadranty.