Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
V Jire sa objaví user story s jedným akceptačným kritériom:
„Systém správne spracuje objednávku.“
Vývojár začne rozmýšľať, čo presne má implementovať.
Tester sa neskôr snaží zistiť, ako to vlastne funguje.
A keď niekto píše manuál, musí funkcionalitu najprv skúšať v systéme, aby zistil, čo robí.
Takto vzniká dokumentácia „z experimentu“, nie zo zadania.
Čo sa tu vlastne pokazilo (analýza systému)
Akceptačné kritériá majú byť most medzi zadaním a realitou systému.
Majú definovať:
- vstupy
- očakávané správanie
- výnimky
- hraničné situácie
Ak sú napísané príliš všeobecne, každý si ich vysvetlí inak.
Najčastejšie chyby sú tri:
1. Nejasná formulácia
Príklad:
„Systém musí správne spracovať objednávku.“
Otázky, ktoré okamžite vzniknú:
- Čo znamená „správne“?
- Čo sa stane pri chybnom vstupe?
- Ktoré polia sú povinné?
Bez odpovedí nie je možné pripraviť presný test.
2. Chýbajúce výnimky a hraničné prípady
V zadaniach sa často opisuje len happy path.
Chýba napríklad:
- čo sa stane pri neplatných údajoch
- čo sa stane pri duplicite
- čo sa stane pri výpadku integrácie
Tester potom musí tieto situácie objavovať až počas testovania.
3. Miešanie riešenia s požiadavkou
Akceptačné kritériá majú opisovať správanie systému, nie implementáciu.
Typická chyba:
„Systém uloží údaje do tabuľky ORDER_DATA.“
To už nie je požiadavka.
To je technické riešenie.
Pre biznis ani používateľa táto informácia nemá význam.
Skutočné náklady (čas, chaos, riziko)
Slabé akceptačné kritériá spôsobujú reťazový efekt:
- Vývojár si zadanie interpretuje po svojom.
- Tester objaví rozdiel medzi očakávaním a implementáciou.
- Tím začne spätne diskutovať, čo vlastne malo platiť.
To znamená:
- viac bugov
- viac otázok
- viac prepisovania dokumentácie
Problém sa tak prenesie do ďalších vrstiev projektu.
Dokumentácia potom opisuje realitu systému, nie pôvodný zámer.
A práve akceptačné kritériá sú miestom, kde sa tento chaos dá zastaviť.
Minimálny model riešenia
Akceptačné kritériá majú byť testovateľné.
Jedna z najpraktickejších foriem je štruktúra:
Given – When – Then
- Given (Za predpokladu) – aký je stav systému
- When (Keď) – aká akcia nastane
- Then (Potom) – aký je očakávaný výsledok
Príklad:
Given používateľ zadá všetky povinné údaje objednávky
When odošle formulár
Then systém vytvorí objednávku a zobrazí jej identifikátor
Takáto forma núti autora premýšľať nad presnými podmienkami správania systému.
Prepojenie na kvalitu a workflow
Akceptačné kritériá ovplyvňujú viac než len testovanie.
Sú zdrojom pre:
- test cases
- používateľské manuály
- support dokumentáciu
- release notes
Ak sú jasné, celý tím pracuje s rovnakým pochopením funkcionality.
Ak nie sú, vznikne situácia, ktorú pozná veľa testerov:
každý v projekte má trochu inú predstavu o tom, ako systém funguje.
Krátke zhrnutie
Najčastejšie chyby v akceptačných kritériách sú:
- nejasné formulácie
- chýbajúce výnimky
- miešanie riešenia s požiadavkou
Akceptačné kritériá majú byť:
- jednoznačné
- testovateľné
- zamerané na správanie systému
Ak sú napísané dobre, pomáhajú nielen testerom, ale aj dokumentácii, supportu a onboarding nových kolegov.
V opačnom prípade sa tím snaží pochopiť systém až z implementácie – a to je najdrahší spôsob, ako zistiť, čo vlastne malo byť v zadaní.