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

V predchádzajúcej lekcii, Techniky testovania bielej skrinky , sme si ukázali techniky testovania bielej skrinky a techniky testovania založené na skúsenostiach.

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

Prístupy collaborative testing

Každá z predchádzajúcich techník testovania má za cieľ identifikáciu defektov, ale prístupy collaborative testing (testovanie založené na spolupráci) sa 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) – aceptance criteria pre overenie správnosti scenára.

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

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

Spolu s tým sú stanovená aceptancia 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.

INVEST princíp

INVEST princíp slúži ako vodítko pre tvorbu správnych scenárov. Scenáre by mali byť:

• Nezávislé (Independent)
• Schodné (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é im pomôcť 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 zmeny vykonal a kedy.

Aceptance 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,
• popisu pozitívnych aj negatívnych scenárov,
• stanovenie základnej definície aceptance testing,
• presnejšiemu test planningu a odhadovaniu testovania.

Najbežnejšie formáty aceptance criteria sú formát orientovaný na scenáre a formát orientovaný na pravidlá. Tieto formáty umožňujú dokumentovať väčšinu aceptancie criteria, 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 pre vyhľadávanie dostupných izieb:

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

Formát orientovaný na scenáre:

• Pozitívny scenár – užívateľ zadá platné mesto, dátum príchodu a odchodu. Systém zobrazí zoznam dostupných hotelových izieb pre zadané obdobie.
• Negatívny scenár - používateľ zadá neexistujúce mesto alebo minulý 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, pokiaľ 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 a testeri, spoločne pripravujú testy, ktoré môžu byť vykonávané manuálne alebo automatizovane.

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

Nasleduje vytvorenie test časov, čo môže vykonávať celý tím alebo iba testeri. Testy sú založené na aceptanci criteria a slúžia ako príklady správneho správania softvéru. Prvý test casy sú obvykle pozitívne, 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 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 aceptance 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 na nákupy nad 1000 Sk:

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 1000 Sk a dostane automaticky zľavu.

Pozitívny test - zákazník nakúpi tovar za 1200 Sk, systém aplikuje 10% zľavu a zaplatí 1080 Sk.

Negatívny test - zákazník nakúpi za 950 Sk, 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 Decouter, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda) Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V budú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é a 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.