Automatizace funkčních testů - II.

V úvodním článku o automatizovaných testech jsem popsal důvody, proč snahy o tak populární automatizaci selhávají. Nyní se budu věnovat spíš způsobu, jak se do toho pustit a co je všechno potřebné zvážit.

Zde je tedy "kontrolní seznam", který používám při rozhodnutí, co se přesně oplatí zautomatizovat (jestli vůbec něco):

1. Kolik iterací testů se v životním cyklu produktu předpokládá?


Počítejte s tím, že zautomatizování testovacího případu, který ručně "naklikáte" za pár minut, může zabrat i několik hodín programování. Pokud se tyto testy nepouštějí často, případně nebudou sloužit jako regresní testy pro X dalších releasů, není to rentabilní - jednoduše se víc oplatí testovat "po staru" - manuálně.

2. Které testy budu automatizovat?

Ne všechny typy testů jsou vhodné k automatizaci - buďto kvůli technické náročnosti/nemožnosti jejich vytvoření, nebo kvůli nevhodnému poměru cena/výkon (viz předešlý bod).

• Budete automatizovat již existující manuální testy (náhrada-urychlení existujících testů)?
• Nebo vytvoříte nové testy, které budou pokrývat jiné oblasti než manuální testy (doplňkové automatizované testování)?
• Budete automatizovat "akceptační testy", "systémové testy", "integrační testy" alebo "komponentové testy"?

Velmi dobře se automatizují testy webových služeb, funkční testy na GUI (tlustý klient, tenký klient), o něco náročnější na čas jsou integrační testy (z důvodu nutnosti programování většího množství "kontrol") a úplně nejhůř se automatizují testy aplikací, které využívají nestandardní technologie (SAP, Siebel...), pokud k tomu ovšem nemáte specializovaný nástroj.

3. Je aplikace dostatečně stabilní?

Pokud vám programátoři ještě pořád zásadně mění aplikaci "pod rukama" (například redesign funkcí na formuláři), čeká vás hodně "předělávání" automatového kódu. Je proto ve vašem zájmu, abyste automatizovali až tehdy, když finišuje vývoj a nepředpokládají se výrazné změny ve stávajícím kódu aplikace.

4. Budu automatizované scénáře pro funkční testy používat i pro zátěžové testy?

Tohle je jedna z otázek, které zásadně ovlivňují design auto-testů. Pro "funkční testy" je často výhodnější psát "dlouhé" scénáře simulující reálnou činnost uživatele nebo celý business proces (například login-založení zákazníka-logout), pro zátěžáky je naopak lepší psát krátké testy, u kterých sa dá snadněji identifikovat přesné místo úzkého hrdla - bottlenecku. Samozřejmě tohle dělení není neporušitelným pravidlem, vždy záleží na konkrétní aplikaci a také cíli funkčního nebo zátěžového testu.

5. Jak a komu budu reportovat výsledky automatizovaných testů?

Velmi důležitý bod - je potřebné si ujasnit hlavně metriky, které budete reportovat. Dáte test manažérovi seznam "passed" a "failed" scenářů? Nebo po dokončení běhu dostane vývojář test log z nástroje, kde si sám dohledá příčiny chyb? Anebo test log bude procházet tester a nalezené chyby zareportuje "standardně" do bugtrackingového nástroje? Případně to zareportování chyb provede automat sám?

6. Jak budu měřit přínos?

• Budete sledovat počet nalezených chýb automatem vzhledem k počtu nalezených chýb na projektu celkem?
• Budete argumentovat počtem ušetřených mandays vzhledem na "manuální testy" stejného rozsahu?

Ať už se rozhodnete jakkoliv, mějte na paměti jedno: pokud nebudete schopni obhájit přínos testů, zapomeňte na další použití automatizace na případných dalších projektech.


Důležité upozornění na závěr: nikdy si ani jen nepomyslete, že automatizované testy mohou plně nahradit manuální testování člověkem. Již z principu to nejde - jednak nemůžete zautomatizovat vše (stejně jako nemůžete otestovat vše), navíc některé věci zautomatizovat nelze a přitom mohou mít výrazný vliv na úspěšnost produktu (rozvržení ovládacích prvků, subjektivní "pocit" testera jakožto prvního uživatele aplikace, testování nestandardních situací...). Proto se občas dobře bavím nad nabídkami firem typu "zautomatizujeme váš projekt v nástroji XXX" - pokud nejsou ujasněny otázky z tohoto checklistu, tak "garantovat automatizaci" může snad jen ten, kdo s automatizací nemá žádné zkušenosti.

Teď už víte co a kdy automatizovat, příště se budu věnovat výběru vhodného nástroje pro automatizaci.