10. diel - Prístupy k testovaniu založené na spolupráci Nové
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.
Prístupy collaborative testingu
Každá z predchádzajúcich techník testovania má za cieľ 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) – aceptance criteria pre overenie správnosti scenára.
Jako [ROLE] chci, aby [CÍL], protože [byznysová HODNOTA].
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.
INVEST princíp
INVEST princíp slúži ako vodítko k tvorbe správnych scenárov. Scenáre by mali byť:
- nezávislé (Independent),
- schodné (Negotiable),
- hodnotné (Valuable),
- odhadnuteľné (Estimable),
- malé (Small),
- testovateľné (Testable).
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 Software 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 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.
- 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 aceptancie testingu,
- presnejšiemu test planningu a odhadovaniu testovania.
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ľ 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“.
- 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 ( ATDD) je prístup, kde sú test casy vytvorené pred implementáciou užívateľského scenára.
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 testu časov, čo môže vykonávať celý tím alebo iba testeri. 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 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 pri nákupe 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 zákazník zaplatí 1080 Sk.
Negatívny test - Zákazník nakúpi za 950 Kč, zľava sa neaplikuje.
Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Stuart Reid, Eric Riou du Cosquer (predseda), Adam Roman, Lucjan 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é 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.
