Čo je čitateľnejšie pre tím
Reálny problém z praxe
Séria: Ako písať dokumentáciu a manuály v IT projekte
V mnohých projektoch sú akceptačné kritériá napísané voľným textom.
Napríklad:
Používateľ môže exportovať zoznam objednávok do CSV.
Export je dostupný len pre oprávnených používateľov.
Pri prázdnom zozname sa zobrazí hláška.
Na prvý pohľad to vyzerá zrozumiteľne.
Lenže keď sa tím začne baviť o detailoch, objavia sa otázky:
- čo presne znamená „oprávnený používateľ“
- čo sa stane pri chybe exportu
- čo sa stane, keď používateľ nemá práva
- čo presne obsahuje CSV
Tester potom nevie presne pripraviť testy.
Vývojár nevie, ktoré situácie sú dôležité.
A dokumentácia neskôr opisuje len časť reality.
Čo sa tu vlastne pokazilo
Voľný text má jeden zásadný problém:
nemá štruktúru scenára.
Opisuje funkcionalitu, ale nie situáciu, v ktorej sa správa systému overuje.
Akceptačné kritériá by však mali byť napísané tak, aby sa dali:
- priamo otestovať
- rýchlo pochopiť
- jednoznačne interpretovať
Práve preto vznikol formát Given–When–Then.
Given–When–Then
Formát:
Given (za predpokladu)
opis situácie alebo stavu systému
When (keď)
akcia používateľa alebo udalosť
Then (potom)
očakávaný výsledok
Používa sa v prístupe BDD – Behavior-Driven Development, kde sa požiadavky zapisujú ako scenáre správania systému.
Príklad: voľný text
Akceptačné kritériá napísané voľne:
- Používateľ môže exportovať objednávky do CSV.
- Export je dostupný len pre rolu účtovník.
- Pri prázdnom zozname sa zobrazí hláška.
Text je krátky, ale nie je jasné:
- čo presne je prázdny zoznam
- či sa export tlačidlo zobrazí
- alebo sa zobrazí chyba až po kliknutí
Príklad: Given–When–Then
Scenár 1 – úspešný export
Given (za predpokladu), že používateľ má rolu „Účtovník“
a zoznam obsahuje aspoň jednu objednávku
When (keď) klikne na tlačidlo „Export CSV“
Then (potom) systém stiahne CSV súbor
a súbor obsahuje stĺpce: číslo objednávky, dátum, suma
Scenár 2 – prázdny zoznam
Given (za predpokladu), že zoznam objednávok je prázdny
When (keď) používateľ klikne na „Export CSV“
Then (potom) systém zobrazí hlášku
„Nie sú dostupné dáta na export“
Scenár 3 – nedostatočné oprávnenie
Given (za predpokladu), že používateľ nemá rolu „Účtovník“
When (keď) otvorí stránku objednávok
Then (potom) tlačidlo „Export CSV“ sa nezobrazí
Skutočné náklady voľného textu
Voľný text nie je vždy problém.
Problém vzniká, keď:
- kritériá interpretujú rôzni ľudia rôzne
- testy vznikajú až po implementácii
- chýbajú hraničné situácie
- dokumentácia sa píše dodatočne
Výsledkom sú typické projektové situácie:
- tester hlási bug
- vývojár odpovie „takto to bolo myslené“
- produktový manažér povie „to sme sa tak nedohodli“
Minimálny model riešenia
Nie každá user story potrebuje desiatky scenárov.
Ale minimálne by mala obsahovať:
- 1 happy path (základný scenár)
- 1 negatívny scenár (chyba alebo výnimka)
- 1 scenár oprávnení, ak ide o roly
Takto má tím istotu, že funkcionalita je opísaná v reálnych situáciách.
Prepojenie na kvalitu a workflow
Given–When–Then má jednu veľkú výhodu.
Je to jazyk, ktorému rozumejú:
- produktový manažér
- vývojár
- tester
- a často aj človek, ktorý píše dokumentáciu.
Scenár je zároveň:
- opis požiadavky
- základ testu
- a zdroj informácie pre manuál.
To výrazne znižuje množstvo nedorozumení v tíme.
Kedy použiť voľný text
Voľný text má stále svoje miesto.
Hodí sa napríklad na:
- jednoduché pravidlá
- krátke obmedzenia
- doplňujúce poznámky
Napríklad:
Export podporuje maximálne 10 000 záznamov.
Ale ak ide o správanie systému v konkrétnej situácii, scenárový zápis býva čitateľnejší.
Mini checklist
Akceptačné kritériá sú pravdepodobne zrozumiteľné, ak:
- opisujú konkrétnu situáciu
- obsahujú akciu používateľa
- obsahujú očakávaný výsledok
- pokrývajú aspoň základný scenár a jednu výnimku
Krátke zhrnutie
Voľný text je rýchly na napísanie.
Given–When–Then je však často čitateľnejší pre celý tím, pretože opisuje konkrétny scenár správania systému.
V praxi nejde o dogmu.
Dôležité je, aby akceptačné kritériá boli napísané tak, že:
- tester vie pripraviť testy
- vývojár vie, čo má byť výsledok
- a dokumentácia nemusí vzniknúť až dodatočným „objavovaním systému“.