Reálny problém z praxe
Séria: Ako písať dokumentáciu a manuály v IT projekte
User story je často jedna veta. A akceptačné kritériá k nej buď nie sú vôbec, alebo sú tiež len „nejaké poznámky“.
Potom to dopadne vždy rovnako:
- vývoj implementuje podľa svojho výkladu,
- tester testuje podľa svojho výkladu,
- dokumentácia sa píše podľa toho, čo sa „náhodou“ správa v systéme.
Akceptačné kritériá mali byť miesto, kde sa to celé zarovná. Lenže nie sú.
Čo sa tu vlastne pokazilo
Akceptačné kritériá sa zamieňajú za:
- zoznam úloh („urobiť tlačidlo“, „pridať pole“, „upraviť DB“),
- opis riešenia („spraviť endpoint“, „pridať tabuľku“),
- alebo všeobecnú vetu („musí to fungovať“).
Testovateľné akceptačné kritériá však majú popísať pozorovateľné správanie systému tak, aby:
- sa dalo jednoznačne overiť,
- bolo jasné, čo je „hotovo“,
- a minimalizovali sa dodatočné otázky.
Skutočné náklady
Keď akceptačné kritériá nie sú testovateľné:
- vznikajú „falošné bugy“ (nie je jasné, či je to chyba alebo očakávané správanie),
- pribúda ping-pong komunikácia v komentároch,
- testy sa píšu neskoro a chaoticky,
- dokumentácia sa dopisuje až po urgenciách od zákazníka.
Minimálny model riešenia
1) Kritérium musí byť pozorovateľné
Nie „systém bude bezpečný“, ale napríklad: „neautorizovaný používateľ dostane hlášku X a akcia sa nevykoná“.
2) Kritérium má byť binárne
Dá sa vyhodnotiť ako splnené/nesplnené.
3) Pokryť aspoň tri typy situácií
- happy path (základný scenár),
- validácie a chyby (čo sa stane pri zlom vstupe),
- práva/role (kto to smie robiť).
4) Nepísať riešenie, ale správanie
Akceptačné kritériá nie sú technická špecifikácia.
BDD a Given–When–Then
BDD (Behavior-Driven Development) je prístup, kde sa požiadavky formulujú ako očakávané správanie systému v konkrétnych scenároch, aby boli zrozumiteľné pre biznis aj tím a dali sa priamo overovať.
Formát:
- Given (za predpokladu)
- When (keď)
- Then (potom)
Príklad z praxe
User story
Ako používateľ chcem exportovať zoznam objednávok, aby som ich mohol spracovať v účtovnom systéme.
Akceptačné kritériá v Given–When–Then
Scenár 1: Export prebehne úspešne
- Given (za predpokladu), že používateľ má rolu „Účtovník“ a v zozname sú aspoň 2 objednávky
- When (keď) klikne na „Export“ a zvolí formát CSV
- Then (potom) sa stiahne súbor CSV obsahujúci stĺpce: číslo objednávky, dátum, suma, mena
Scenár 2: Nie sú dáta na export
- Given (za predpokladu), že zoznam objednávok je prázdny
- When (keď) používateľ klikne na „Export“
- Then (potom) systém zobrazí hlášku „Nie sú dostupné dáta na export“ a súbor sa nestiahne
Scenár 3: Nedostatočné oprávnenie
- Given (za predpokladu), že používateľ nemá rolu „Účtovník“
- When (keď) klikne na „Export“
- Then (potom) systém export neumožní a zobrazí hlášku „Nemáte oprávnenie na export“
Poznámka: Technické detaily typu „kde je endpoint“ alebo „ako sa generuje CSV“ sem nepatria. To je až špecifikácia/technická dokumentácia.
Prepojenie na kvalitu a workflow
Akceptačné kritériá sú najkratšia cesta k tomu, aby:
- tester vedel pripraviť testy bez dohadovania,
- vývoj vedel, čo má byť výsledné správanie,
- dokumentácia nebola písaná „objavovaním systému“.
V ideálnom workflow je to reťazec:
User story → Akceptačné kritériá → Test cases → Dokumentácia → Release notes
Ak zlyhá akceptácia, všetko ďalšie sa len „lepí“.
Mini checklist: testovateľné akceptačné kritériá
- Sú kritériá napísané ako pozorovateľné správanie, nie riešenie?
- Dá sa každé kritérium vyhodnotiť splnené/nesplnené?
- Je pokrytý aspoň 1 happy path?
- Je pokrytá aspoň 1 validačná/negatívna situácia?
- Je pokryté oprávnenie/rola (ak je relevantné)?
- Sú pomenované výstupy (hláška, zmena stavu, stiahnutý súbor, vytvorený záznam)?
Konkrétna formulácia do Jiry / DoD
Definition of Done – AC:
- Akceptačné kritériá sú uvedené minimálne pre: happy path, negatívny scenár, oprávnenia (ak relevantné).
- Kritériá sú napísané v Given (za predpokladu) / When (keď) / Then (potom) alebo ekvivalentne jasným testovateľným spôsobom.
- Kritériá neobsahujú implementačné detaily.
Krátke zhrnutie
Testovateľné akceptačné kritériá sú krátky, ale presný opis správania systému.
Keď sú dobré, šetria čas vývoju, testerovi aj človeku, ktorý neskôr píše dokumentáciu.