Od biznis požiadavky k testu: ako si dohodnúť, čo má aplikácia overiteľne robiť
Požiadavka „zákazník sa má vedieť prihlásiť na workshop“ ešte nehovorí, podľa čoho spoznáte správny výsledok. Product owner, teda človek zodpovedný za smerovanie produktu, analytik, vývojár aj tester si pod ňou môžu predstaviť niečo iné. Spoločné zadanie má preto opísať vstupy, podmienky a očakávané správanie tak, aby ho klient vedel schváliť a tím následne overiť. Začať sa dá aj bez hotových testovacích scenárov.
Prečo zoznam kliknutí nestačí
Postup „otvor web, vyber workshop, stlač Prihlásiť“ opisuje ovládanie aplikácie. Chýba mu však význam úspechu: vznikla platná registrácia, ubudlo miesto a vidí používateľ správny stav? Zelený výsledok testu, ktorý skontroloval iba zobrazenie tlačidla, na tieto otázky neodpovedá.
Podobne nejasné sú požiadavky „má to byť rýchle“ alebo „chybu treba správne ošetriť“. Tím potrebuje dohodnúť podmienky, pozorovateľný výsledok a podľa potreby aj časový limit. Aktuálne správanie aplikácie môže pomôcť pri skúmaní, samo osebe však nie je dôkazom zamýšľaného pravidla. Inak si do zadania prepíšete aj existujúcu chybu.
Tento krok predchádza rozhodovaniu, kedy spustiť smoke, sanity alebo akceptačné testy. Tu sa dohodne, čo má aplikácia robiť; uvedené typy testovania potom používajú túto dohodu na rôzne účely.
Čo priniesť, keď nemáte pripravené scenáre
Klient nemusí napísať technickú špecifikáciu. Užitočnejší začiatok býva ukážka bežnej práce, opis problému a konkrétny prípad, pri ktorom vznikla chyba alebo neistota. Analytik či tester z týchto podkladov pripraví návrh, otvorené otázky a príklady na schválenie.
Na spoločné stretnutie stačí pripraviť:
- Cieľ a používateľa: kto potrebuje niečo urobiť a prečo je výsledok dôležitý.
- Vstupy: napríklad zvolený workshop, účet účastníka a počet obsadených miest; pri ukážkach používajte pripravené testovacie údaje.
- Predpoklady: čo už musí platiť, napríklad prihlásený používateľ, otvorená registrácia a existujúci workshop.
- Očakávaný výsledok: čo používateľ alebo nadväzujúci systém pozoruje po vykonaní akcie.
- Hranice a výnimky: posledné voľné miesto, plná kapacita, opakovaná požiadavka či nedostupná závislosť.
- Vlastníka rozhodnutia: kto môže potvrdiť pravidlo, keď majú členovia tímu odlišný výklad.
Chýbajúcu odpoveď zapíšte ako otvorenú otázku s konkrétnym vlastníkom. Predpoklad „asi sa má poslať e-mail“ nesmie nenápadne prejsť do schválenej požiadavky. Ak bez odpovede nemožno určiť správny výsledok, daný scenár ešte nie je pripravený na realizáciu.
Ako z rozhovoru vzniknú prijímacie kritériá
Prijímacie, často označované aj ako akceptačné, kritériá sú podmienky, podľa ktorých posúdite splnenie požiadavky. Pravidlo môže hovoriť o všetkých registráciách, konkrétny príklad však ukáže jeho výklad: pri jedenástich obsadených miestach z dvanástich sa ďalší účastník ešte môže prihlásiť.
Pri rozhovore oddeľte pravidlá, príklady a nezodpovedané otázky. Takto s nimi pracuje aj metóda Example Mapping v dokumentácii Cucumber. Užitočné je pridať aj zoznam odložených tém, aby všetci videli hranice aktuálneho zadania.
Odporúčaným výstupom je krátky záznam pri požiadavke: schválené kritériá, príklady, otvorené otázky a rozhodnutia o rozsahu. Osobitne označte návrh testera a potvrdené biznis pravidlo. Tester vie odhaliť nejasnosť, no bez poverenia nerozhoduje, komu má firma umožniť registráciu.
Modelový príklad: registrácia na posledné miesto
Nasledujúci príklad je vymyslené zadanie. Čísla a pravidlá slúžia na vysvetlenie postupu, nie ako odporúčané nastavenie každého rezervačného systému.
Požiadavka R-17: „Prihlásený používateľ sa môže zaregistrovať na otvorený workshop, ak je voľné miesto. Počet potvrdených registrácií nesmie prekročiť kapacitu.“ Po rozhovore tím doplní, že jeden účet môže mať na rovnakom workshope iba jednu platnú registráciu. Čakacia listina a e-mailové notifikácie sú mimo tejto požiadavky.
| Kritérium | Dohodnuté správanie | Konkrétny príklad |
|---|---|---|
| K1: voľné miesto | Vznikne jedna potvrdená registrácia, ktorá sa zobrazí používateľovi aj v zozname organizátora. | Pri kapacite 12 a 11 registráciách pribudne dvanásta. |
| K2: plná kapacita | Nová registrácia nevznikne a používateľ dostane informáciu o naplnení kapacity. | Pri 12 registráciách ďalší účet neuspeje; počet zostane 12. |
| K3: opakovanie | Opakované odoslanie tým istým účtom nevytvorí ďalšiu registráciu. | Účet už registrovaný podľa K1 odošle požiadavku znova; počet sa nezmení. |
| K4: súbežný záujem | Pri súčasnom záujme dvoch rôznych účtov o posledné miesto uspeje iba jeden. | Z 11 registrácií vznikne 12, druhý účet dostane informáciu o plnej kapacite. |
Z K1 vznikne scenár S-17-1. Predpokladom je otvorená registrácia, kapacita 12, presne 11 potvrdených účastníkov a prihlásený účet, ktorý medzi nimi nie je. Akciou je odoslanie registrácie. Očakávaným výsledkom je potvrdený stav pri tomto účte, jeho jediný záznam v zozname organizátora a celkový počet 12.
Takéto členenie zodpovedá zápisu Given–When–Then: východiskový stav, udalosť a očakávaný výsledok. Dokumentácia Gherkin odporúča výsledok overovať na pozorovateľnom výstupe. Na dohodu však stačí bežný text alebo tabuľka; zavedenie konkrétneho nástroja nie je podmienkou.
K2 až K4 potrebujú vlastné scenáre. Dva postupné pokusy nenahrádzajú súbežný pokus z K4. Tester s vývojárom musia dohodnúť spôsob, ako vytvoria súbeh a rozlíšia výsledky oboch účtov. Ak test overil iba posledné miesto pre jedného používateľa, kritérium súbehu zostáva neoverené.
Čo bude dôkazom vykonaného testu
Scenár popisuje očakávanie; výsledok behu zaznamenáva, čo sa skutočne stalo. Pri S-17-1 má byť dohľadateľné označenie požiadavky a kritéria, verzia scenára, testovaná verzia aplikácie, prostredie, použité účty a východisková obsadenosť. K tomu patria skutočné výsledky jednotlivých overení a celkový stav behu.
Primeraným dôkazom môže byť záznam potvrdenej registrácie dostupný v účte používateľa a zodpovedajúci zoznam organizátora. Technická kontrola môže výsledok čítať aj cez dohodnuté API, teda rozhranie, ktorým komunikujú programy. Spôsob overenia má zodpovedať kritériu; samotná úspešná odpoveď servera ešte nepotvrdzuje správny počet účastníkov.
Snímka potvrdenia pomôže pri kontrole zobrazenia, ale sama nepreukáže, že nevznikla duplicita. Rovnako nestačí súhrn „test prešiel“, ak sa z neho nedá zistiť, ktoré podmienky skutočne overoval. Rozsah a podobu dôkazov dohodnite podľa potreby projektu, nie podľa všetkého, čo testovací nástroj dokáže vyprodukovať.
Čo schvaľuje klient a čo rieši technický tím
Klient alebo poverený product owner schvaľuje zamýšľané správanie, príklady a hranice rozsahu. V našom príklade potvrdí, že rozhoduje účet používateľa, opakovaním nevzniká ďalšia registrácia a čakacia listina zatiaľ nevznikne. Zároveň určí, kto odpovie na otázky alebo schváli neskoršiu zmenu pravidla.
Technický tím zodpovedá za vykonateľný postup, prípravu dát a primerané overenia. Klient nemusí schvaľovať každý selektor, teda pravidlo na vyhľadanie prvku vo webe. Má však rozumieť tomu, čo výsledok testu potvrdzuje a čo zostalo mimo kontroly. Schválenie scenára pred implementáciou tiež nie je automatickým prijatím hotovej funkcie.
AI má zachovať schválený význam scenára
Pri tvorbe testu pomocou umelej inteligencie (AI) zostáva schválený slovný opis podkladom na kontrolu. AI môže navrhnúť kód, doplňujúce otázky alebo opravu technického kroku. Nemá meniť vstupy, postup či očakávané výsledky len preto, aby test prešiel.
Ak zlyhá overenie dvanástich registrácií, nahradenie presného počtu podmienkou „zoznam nie je prázdny“ oslabí kritérium. Vynechanie kontroly duplicity zas odstráni časť dohodnutého správania. Oprava selektora môže zachovať význam, aj pri nej však človek preverí, či test stále pracuje so správnym prvkom a účtom.
Zmenu významu musí schváliť oprávnený človek a má sa premietnuť do požiadavky, kritéria aj scenára. Pri kontrole porovnávajte slovný opis so skutočnými krokmi a overeniami. Zelený výsledok je použiteľný až v spojení s tým, čo test vykonal.
Čo tým získate a kde zostávajú hranice
Prepojenie požiadavka → kritérium → scenár → dôkaz umožní pri nezhode nájsť konkrétne pravidlo a zodpovednú osobu. Analytik vie ukázať nevyriešené otázky, tester chýbajúce overenia a klient rozsah, ktorý prijíma. Pri zmene kapacity alebo pravidiel účtov sa ľahšie dohľadajú dotknuté testy.
Ani dôkladne spracovaná registrácia nepokrýva celý produkt. Bezpečnosť, accessibility či správanie pri veľkej záťaži môžu potrebovať ďalšie požiadavky a samostatné overenie. Ich priority patria do širšej testovacej stratégie.
Prvý krok pri vašej požiadavke
Vyberte jednu dôležitú používateľskú činnosť a dopíšte k nej úspešný príklad, hraničný prípad a chybový tok. Pri každom určte vstupy, predpoklady, výsledok a spôsob jeho overenia. Nejasnosti prideľte konkrétnemu rozhodovateľovi. Takýto podklad umožní dohodnúť rozsah práce aj vtedy, keď zatiaľ nemáte jediný automatizovaný test.