Při designu testů si musíte nejdřív projít existující manuální testovací scénáře a unit testy (pokud jsou nějaké vytvořeny) a pak si rozmyslet tyto věci:
1. Je daný scénář vhodný na automatizaci?
Dost často se setkávám s tím, že se testeři snaží zautomatizovat každý scénář, na který narazí. Prakticky se ale vyplatí automatizovat pouze scénáře, které budou sloužit pro regresní nebo smoke testy, případně je velká pravděpodobnost, že se postupem časem takovýmito testy stanou. Není nic horšího, než když programujete nějaký test několik hodin, přičemž manuálně by se dal vykonat za pár minut a po několika releasech produktu zjistíte, že test byl za celou dobu spuštěn pouze jednou. Vždycky uvažujte v poměru cena/přínos.
2. Jaké automatizované scénáře by bylo vhodné přidat k manuálním testovacím případům, aby se zvýšila šance nalezení nějaké chyby?
Výhodou automatu je třeba to, že můžete stejný test opakovat X-krát s různými vstupními daty s malým nárůstem pracnosti, takže toho můžete využít ke svému prospěchu - ať již k většímu rozsahu testování, nebo k velmi efektní přípravě testovacích dat (například pro manuální akceptační testy).
3. Jaké scénáře by bylo vhodné přidat k doplnění unit testů?
Unit testy mají obvykle nevýhodu, že jsou sice perfektní pro pokrytí kódu uvnitř nějaké třídy, ale mnohem hůře se nimi testuje integrace napříč nehomogenními systémy. Automatizované testy jsou často psány na "úrovni ručně klikajícího uživatele", takže pokud je to tento případ, můžete automatem zvýšit pokrytí kódu aplikace.
4. Do jaké hloubky "ověřování" půjdu při vykonávání jednotlivých testů automatem?
Rozepište si "kontrolní body" u testů do podrobností. Když například manuální test přikazuje "ověřte korektní založení zákazníka", musíte v automatu naprosto přesně vědět, co budete kontrolovat. Bude vám stačit hláška na obrazovce? Nebo se podíváte do databáze? Čím větší hloubka kontrol bude, tím víc kódu budete muset psát - a zase pokud bude kontrola příliš "mělká", mohou vám uniknout závažné chyby.
5. Je možné daný scénář využít i k jiným účelům, než na které byl původně zamýšlen?
Funkční test pro vytvoření objednávky nějakého produktu může být stejně dobře použit pro vytváření testovacích dat - přemýšlejte i v těchto intencích a navrhujte testy tak, aby s takovými možnostmi počítaly. Prakticky to znamená psát testy tak, aby šly snadno parametrizovat a třeba test nějakého složitého business procesu rozdělte do několika dílčích funkcí, které zavoláte z "hlavní funkce business testu".
6. Jaká testovací data budu ke scénáři potřebovat?
Tady je potřebné zvážit několik okolností:
- Jak budou tato data připravena? Bude před začátkem testů "nalitá" databáze pevnou množinou dat (například daty "z produkce")? Nebo tato data bude generovat nějaký automat?
- Jak přenést tyto data jako vstup pro testovací scénáře? Bude si je automat náhodně vybírat z databáze, nebo jiného zdroje, nebo budou přesné hodnoty "hardkódovány" přímo do kódu scénáře? Anebo si tyto data vygeneruje automat sám na základě nějakého "patternu"?
- Jak po ukončení testu odstraním změny v datech způsobených testováním, třeba pro další běh automatu? Bude se dělat opětovný "přeplach" databáze? Nebo se pro další testy použije "ještě nepoužitá" část dat z úvodního "nalití"? Nebo čištění dat není vůbec potřebné?
Na závěr si pro jistotu projděte celý design testů ještě jednou a někde ho zadokumentujte - automatizační projekt je stejně jako samotný "vývojářský projekt" složitý a tudíž je dokumentace nezbytná. Počítejte s tím, že možná už později na projektu nebudete a někdo po vás bude muset testy "převzít" - případná dokumentace o rozhodnutích ve fázi designu a vhodné komentování zdrojového kódu mohou dotyčnému výrazně usnadnit život a bude pak na vás vzpomínat v dobrém :-)
Příště tento seriál ukončím seznamem "best practices automatizace", které jsem na projektech sesbíral.
Příspěvky
Žádné komentáře:
Okomentovat