Jak psát srozumitelné testovací případy pro akceptační testy

V praxi se často setkávám s tím, že test analytici neumí napsat srozumitelné testovací případy pro uživatelské akceptační testy (UAT) - uživatelé, kteří mají podle nich testovat aplikaci a rozhodnout, jestli tuto aplikaci "akceptují" do ostrého provozu, mají problém se zjištěním, co vlastně mají udělat a proč.
Zde jsou principy, kterými se doposud úspěšně řídím (některé částečně patří i do oblasti test manažmentu):

1. Testovací případy dejte psát test analytikovi, který byl s aplikací důkladně obeznámen
Tím nemyslím klasickou test analýzu z dokumentace dodanou business analytikem/vývojem (to je samozřejmé, že z této dokumentace se při tvorbě testů vždy vychází), ale že by samotné test cases měl ideálně psát někdo, kdo tu aplikaci testoval v systémových testech, nebo má takového testera "po ruce".
Důvodem je skutečnost, že takový test analytik umí vhodně zvolit úroveň detailu, do které má při psaní scénářů jít a navíc může uživatelům v průběhu jejich UAT snažení dělat podporu, pokud se na něčem "zaseknou". Nehledě na to, že finální aplikace se dost často liší od "business zadání" (drobné úpravy "za pochodu" přímo do implementace a následné neaktualizování analytické dokumentace).

2. Poznejte uživatele, kteří budou testovat podle vašich scénářů a podle toho volte úroveň detailu

Tato zásada vám může ušetřit hodně práce - pokud třeba píšete akceptační testy pro stávající aplikaci, ve které se uživatelé již orientují a mají otestovat pouze nějakou novou funkčnost, volte úroveň detailu jen takovou, jaká je nezbytně nutná. Velmi pomůže i to, když znáte jejich "hantýrku" a ještě lépe popis jejich "běžné" pracovní činnosti. Do testů pak dávejte jenom podstatné informace - pouze základní postup k věcem, které uživatel zná a detailnější postup u věcí, které uživatel nezná. Pokud neznáte "cílovou skupinu čtenářů", volte detaily jako pro uživatele, který aplikaci vidí poprvé.

Příklad z praxe - externí test analytik si tohle "poznávání uživatelů" odpustil ("nemám na takové věci čas") a při testu aktivace nového telefonního čísla s platbou na fakturu a novým tarifem Master napsal scénář s 27 kroky. Jelikož jsem znal uživatele, který danou funkčnost má otestovat, stejný testovací případ se "smrsknul" na popis "aktivujte nové postpaidové MSISDN běžným způsobem, jako tarif zvolte Master (nový produkt) a po zpracování požadavku zkontrolujte správnou aktivaci čísla v dotčených systémech". Při počtu 200 podobných scénářů to udělá slušnou časovou úsporu při přípravě testů.

Šlo to takhle zkrátit, protože jsem věděl, že:

• uživatel s aplikací denně pracuje, dělá běžně aktivace čísel a tudíž ví ještě lépe než já, kdy má kam kliknout (a tudíž by se mohl cítit dotčen, že je scénář psaný "jako pro blbečka"); navíc samotné přidání nového tarifu nezpůsobilo změnu procesu (to vím již z business analýzy a architektury)
• uživatel ví, jak má "vypadat" správná aktivace čísla - kde má co zkontrolovat (tudíž mu nemusím rozepisovat co, kde a jak má udělat)
• místo dlouhého popisu "telefonní číslo s platbou na fakturu" mohu uvést "postpaidové MSISDN", protože vím, že je to zavedený "pojem" ve firmě pro tento případ a uživateli se to bude lépe číst.
• scénáře je ve firmě možné psát neformálním, ale srozumitelným stylem (takže například nemusím striktně oddělovat v kroku popis "akce" od "očekávaných výsledků")

3. Oddělujte testovací data od popisu kroků

Je chybou psát konkrétní testovací data přímo do kroku, například "aktivujte telefonní číslo 724123456 na zákazníkovi s rodným číslem 192344/3544". Uživatel možná test napoprvé "pokazí", nebo se nedejbože najde chyba a budete muset pracně "předělávat" scénář pro další pokus. Je lepší data držet zvlášť od popisu kroků - to platí koneckonců nejen pro manuální, ale i automatizované testy (a tak to popisují i různé testovací metodiky - přesto se s tímto nepěkným mícháním jablek s hruškama setkávám).

4. Každý test pište tak, aby šlo jednoznačně rozhodnout o výsledku

Hlavně zkušenější test analytici si často dělají zkratky typu "Ověřte, že zákazníkovi byla doručena odpovídající SMS" místo "Ověřte, že zákazníkovi byla doručena SMS s textem "Abcd.". Má to úskalí - v uvedeném případě se stalo, že uživatel akceptoval text "...vas dodavatel" a muselo se to pak dodatečně opravovat, protože zadavatel požadoval text "...Vas dodavatel" a lidem ve vedení vadilo, že oslovení "váš" s malým "v" není dostatečně osobní (což uživatel nevěděl).

Takovou "zkratku" si můžete dovolit pouze v případě, že jste si jisti, že akceptační tester je dostatečně seznámen se zadáním (v ideálním případě když je akceptačním testerem přímo zadavatel projektu).

Nezapomínejte, že příslušný tester se pod daný test musí "podepsat", obvykle ručí za správnost dané funkce produktu svým krkem a nejspíš byste taky nepodepsali něco, o čem máte pochybnosti. 

5. Množinu možných stavů výsledků testovacích scénářů mějte co nejmenší

Záleží samozřejmě na domluvené metodice  (ať už "celofiremní" nebo ze "smlouvy s dodavatelem"). Nicméně pokud metodiku vymýšlíte, nevymýšlejte příliš mnoho "stavů".

Akceptační testeři obvykle nejsou svým povoláním testeři, ale jsou to pouze cíloví uživatelé aplikace (mzdová účetní, skladník v e-shopu...). Čím víc stavů dáte (obecně čím složitější metodiku jim "nasadíte"), tím větší pravděpodobnost bude, že nebudou vědět, co tam mají vyplnit (a pokud se rozhodují, vždy vyberou tu "méně příznivou" variantu k akceptačnímu jednání; nejsem si jist, jestli je to chyba = radši tam dám, že to chyba je).

6. Scénáře prezentujte uživatelům v tisknutelné podobě

Jednotlivé akceptační scénáře se často fyzicky podepisují (ve velmi formálním způsobu akceptace), navíc i když podpis není nutný, uživatelé si rádi scénáře tisknou na papír a testují podle papíru (třeba proto, že pro čtení jednotlivých kroků by museli pořád přepínat okna testované aplikace a aplikace, ve které čtou testovací scénář).

Jednou se mi stalo, že jsem takovéto scénáře připravoval do Excelu, blbě jsem rozvrhnul šířku buněk na stránku a po 5 minutách od začátku testů za mnou doběhla skupinka uživatelů s vytištěnýma testama (akce na jednom papíru, zodpovídající výsledek ve stejném řádku na druhém papíru) a dotazem, jestli bych se z toho sám vyznal. Já ani netušil, že si to vůbec tisknou! (výsledky testů se zapisovaly do webové aplikace, tak jsem jaksi předpokládal, že... = moje chyba).

7. Pokud můžete, dejte akceptačním testerům čas na badatelské testování

V akceptačních testech se obvykle testuje sada scénářů, která je předem někým schválena (zadavatel, dodavatel atd.). Pokud to umožňuje smlouva, je velmi výhodné (hlavně u projektů "vylepšení stávající aplikace") dát uživatelům čas, kdy si mohou s aplikací "hrát" - zkoušet třeba postupy, které v UAT scénářích nebyly uvedeny, nebo sekvence operací, se kterými mají zkušenost, že pak aplikace "zlobí". Často se objeví věci, o kterých test analytici, vývojáři ani business analytici neměli ani tušení a co víc - uživatelé si pak lépe vybudují důvěru v testovaný produkt. Nezapomínejte, že akceptační testy slouží k vybudování důvěry v produkt ("funguje to tak, jak jsme chtěli, dobře se s tím pracuje a celkově se nám to líbí, takže to bereme") - ne k nacházení chyb v produktu (od toho jsou primárně systémové testy).

8. Jestliže akceptační testy vykonávají interní zaměstnanci zákazníka a vy jste dodavatel, hýčkejte si je

Poslední princip vychází částečně z předchozího bodu. UAT testeři jsou prvními uživateli vaší nové aplikace. Budou to oni, koho se budou stakeholdeři ptát "Jste spokojeni s produktem? Máme ho koupit?" (stakeholdery víceméně nezajímá, jak samotná aplikace vnitřně funguje - pouze jestli to bylo za smluvené peníze a splňuje to představy uživatelů, pro které je určena). Jsou to opět oni, kteří můžou šířit mezi dalšími kolegy "to bude super aplikace od našeho dodavatele Firmička, už se těším až ji dají do provozu", nebo taky "sice nepříjemné na používání, ale umí to vše co jsme chtěli" a pokud máte smůlu "tak jsme to konečně akceptovali, ale podruhé již má Firmička utrum pokud budeme chtít něco dalšího".

Bývá to právě zkušenost akceptačních testerů a jejich iniciativa, která má výrazný vliv na vytváření dobrého jména dodavatele uvnitř celé společnosti zákazníka - nejen v IT týmu.

Další zajímavé postřehy pro psaní testovacích případů najdete v prezentaci na slideshare.net