Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
Tester hlási:
„Systém nefunguje.“
Vývojár odpovie:
„To nie je chyba. To je obmedzenie.“
Používateľ zadal kombináciu údajov, ktorú systém nepodporuje.
Systém vrátil chybu.
Lenže nikde nebolo napísané:
- aké kombinácie sú povolené
- aké nie
- čo je chyba a čo je zámer
Výsledok:
tester hlási bug
vývojár ho zamieta
support nevie, čo povedať zákazníkovi
Čo sa tu vlastne pokazilo (analýza systému)
Problém nie je v konkrétnom správaní.
Problém je, že systém nemá zdokumentované hranice.
Každý systém má:
- chybové stavy
- funkčné obmedzenia
- nepodporované scenáre
Lenže v dokumentácii často chýbajú.
Potom vzniká chaos:
- nie je jasné, čo je chyba
- nie je jasné, čo je správne správanie
- tím si to vysvetľuje rôzne
Skutočné náklady (čas, chaos, riziko)
Keď chýbajú chybové stavy a obmedzenia:
- vznikajú falošné bugy
- testovanie je neefektívne
- support nevie komunikovať so zákazníkom
- vývoj rieši nedorozumenia
Typická situácia:
systém sa správa správne
ale tím si myslí, že nie
Minimálny model riešenia
Chybové stavy musia byť explicitné.
- Definícia chýb
- aké chyby môžu nastať
- v akých situáciách
- čo ich spôsobuje
- Správanie systému
- čo systém urobí pri chybe
- akú hlášku zobrazí
- čo vráti API
- Funkčné obmedzenia
- nepodporované kombinácie
- limity vstupov
- špecifické pravidlá
Napríklad:
- maximálny počet položiek
- povinné kombinácie polí
- Rozlíšenie chyba vs obmedzenie
Kľúčová vec:
- chyba = systém sa správa nesprávne
- obmedzenie = systém sa správa podľa návrhu
Toto musí byť jasne napísané.
Príklad
Bez dokumentácie:
„Systém neumožňuje uložiť formulár.“
S dokumentáciou:
- pole X je povinné
- kombinácia A + B nie je podporovaná
- systém vráti chybu 400
Zrazu je jasné:
že nejde o bug
ale o pravidlo
Mini checklist
Sú definované chybové stavy?
Je jasné, čo ich spôsobuje?
Je popísané správanie systému?
Sú uvedené funkčné obmedzenia?
Je jasné, čo je chyba a čo obmedzenie?
Ak nie, systém nemá jasné hranice.
Prepojenie na kvalitu a workflow
Chybové stavy sú kritické pre testovanie.
Bez nich:
- tester nevie, čo má overiť
- vznikajú zbytočné bugy
- komunikácia v tíme zlyháva
Pre testerku:
najdôležitejšia otázka nie je „funguje to?“
ale „ako sa to má správať, keď to nefunguje?“
Krátke zhrnutie
Systém nie je len o tom, čo funguje.
Je aj o tom:
- čo nefunguje
- čo nesmie fungovať
- čo nie je podporované
Ak to nie je zdokumentované:
- vzniká chaos
- tím si nerozumie
Ak to zdokumentované je:
- vieš, čo testovať
- vieš, čo je chyba
- vieš, kde sú hranice systému
A to je základ kvalitného produktu.