Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
Na projekte sa objaví nová funkcionalita.
Analytik pripraví user story a krátku špecifikáciu.
Vývoj začne implementovať.
Tester pripraví test cases až keď je funkcionalita hotová.
A vtedy sa objavia otázky:
- Čo sa má stať pri chybovom stave?
- Ako sa má systém správať pri prázdnych údajoch?
- Platí to pre všetkých používateľov alebo len pre niektorých?
- Čo má používateľ vlastne vidieť na obrazovke?
Odpovede sa začnú hľadať až počas testovania alebo po nasadení.
V skutočnosti problém vznikol oveľa skôr.
Špecifikácia sa nikdy poriadne neprečítala z pohľadu testovania.
Čo sa tu vlastne pokazilo (analýza systému)
V mnohých tímoch sa špecifikácia chápe len ako zadanie pre vývoj.
Tester sa k nej dostane až v momente, keď existuje implementácia.
Lenže špecifikácia je vlastne prvá verzia správania systému.
Ak je nejasná, vývoj implementuje podľa vlastného pochopenia.
Tester potom netestuje systém.
Testuje interpretáciu zadania.
A často sa ukáže, že nie je jasné ani to:
- čo má systém urobiť
- ani ako má výsledok vyzerať pre používateľa
Testovanie špecifikácie znamená položiť si otázku:
Dokážeme podľa tohto textu jednoznačne určiť, čo má systém robiť a čo má používateľ vidieť?
Skutočné náklady (čas, chaos, riziko)
Ak sa špecifikácia netestuje pred vývojom, vznikajú typické problémy:
- vývoj implementuje neúplnú funkcionalitu
- test cases sa musia počas testovania meniť
- vznikajú falošné bugy
- tím rieši otázky, ktoré mali byť zodpovedané na začiatku
- dokumentácia vzniká spätne podľa implementácie
Veľmi častý problém je, že:
funkcionalita „funguje“,
ale každý si ju predstavoval inak.
Najväčší problém je, že tieto chyby sa objavia až v neskorej fáze projektu.
Minimálny model riešenia
Testovanie špecifikácie je jednoduché.
Tester si prečíta zadanie ešte pred vývojom a pokúsi sa z neho pripraviť test cases.
Pri tom narazí na otázky, ktoré špecifikácia neobsahuje.
Tie sú presne tým miestom, kde špecifikácia nie je úplná.
Pri čítaní špecifikácie by mali byť jasné:
- Vstupy
- Aké údaje systém prijíma
- Výstupy
- Aký je očakávaný výsledok
- čo používateľ uvidí (obrazovka, tabuľka, hláška, export)
- Scenáre
- Ako funkcionalitu používa používateľ
- Chyby
- Čo sa stane pri neplatných údajoch
- ako sa chyba zobrazí používateľovi
- Obmedzenia
- Čo funkcionalita nepodporuje
- Závislosti
- Od čoho správanie systému závisí
Ak sa na niektorú otázku nedá odpovedať, špecifikácia ešte nie je pripravená.
Príklad
Špecifikácia obsahuje vetu:
„Používateľ môže exportovať údaje.“
Pri testovaní špecifikácie sa okamžite objavia otázky:
- Aký formát exportu?
- Aké údaje export obsahuje?
- Existuje limit počtu záznamov?
- Čo sa stane, ak nie sú dáta?
- Kde používateľ export spustí? Je tam tlačidlo? Ako je označené?
- Zobrazí sa potvrdenie alebo sa súbor rovno stiahne?
Tieto otázky by mali byť vyriešené ešte pred vývojom.
Mini checklist testovania špecifikácie
Pred začiatkom vývoja by sa mal tím vedieť opýtať:
- Je jasné, kto funkcionalitu používa?
- Sú definované vstupy?
- Sú definované výstupy?
- Je jasné, čo používateľ uvidí na obrazovke?
- Sú popísané chybové stavy?
- Sú uvedené hraničné situácie?
- Je jasné, čo funkcionalita nerobí?
Ak tester dokáže podľa špecifikácie pripraviť test cases bez ďalších otázok, špecifikácia je pravdepodobne pripravená na vývoj.
Prepojenie na kvalitu a workflow
V projekte existuje prirodzený postup:
User story → Akceptačné kritériá → Špecifikácia → Implementácia → Testovanie → Dokumentácia
Testovanie špecifikácie patrí na začiatok tohto reťazca.
Tester tu nepôsobí ako kontrolór hotového systému.
Pôsobí ako človek, ktorý pomáha odstrániť nejasnosti ešte pred vývojom.
Ak nie je jasné:
- čo má systém robiť
- ani čo má používateľ vidieť
tím pracuje s rôznymi predstavami o výsledku.
Krátke zhrnutie
Testovanie špecifikácie je jeden z najlacnejších spôsobov, ako znížiť chaos v projekte.
Ak sa nejasnosti odhalia pred vývojom, ušetrí sa čas vývojárom, testerom aj autorom dokumentácie.
A celý tím pracuje s rovnakou predstavou o tom, ako sa má systém správať – aj ako má výsledok vyzerať pre používateľa.