Automatizace funkčních testů - I.

Testovat software jiným způsobem než manuálním "klikáním" se stává v poslední době velmi populárním. Navzdory přítomnosti mnoha velmi dobrých nástrojů na trhu určených pro tuto činnost ale ve většině případů projekty "automatizace testů produktu" selhávají. Proč tomu tak je?



Na prvním místě jsou nereálná očekávání. Často se setkávám s naivní představou "koupíme nástroj, najmeme lidi co napíšou testy a pak už manuální testery vůbec nepotřebujeme, nebo nám v tom horším případě stačí nějaký tester pro "průzkumné testování", pro jistotu..." Jádro pudla spočívá v tom, že málokdo si uvědomuje základní charakteristiky automatizovaných funkčních testů:

• jsou obvykle rentabilní pouze v delším časovém horizontu a při jejich velmi častém spouštění
• nemají za úkol plně nahradit manuální testování - jenom urychlit ty typy testů, u kterých se to vyplatí, případně nahradit testy, které by se jinak dělaly velmi obtížně.
• automatizovat mohou pouze zkušení testeři s velmi dobrými znalostmi programování, kteří jsou podstatně dražší než "klikači"
• kód automatizace se musí udržovat stejným způsobem, jako kód produktu (release manažment, úpravy kódu při změně produktu atd.)
• testy jsou silně závislé na použité technologii produktu (automatizace třeba tlustého klienta v Javě, tenkého klienta v PHP a webové služby se diametrálně liší, byť ve stejném nástroji)

Již jsem se zmínil, že automatizace je také programátorský projekt - to ale znamená také to, že i projekt automatizace může obsahovat "produktové chyby":

• nedostatky v kódu automatizace (automat nezachytí chyby, nebo naopak reportuje věci, které problematické nejsou)
• nad testovanou aplikací se spouští špatná verze kódu automatizace, určená pro jinou verzi aplikace
• problémy s testovacím prostředím ("zasekávání" automatu kvůli různým nečekaným událostem, se kterými si automatizační nástroj neporadí)

Dalším častým problémem je komunikace přínosů směrem k nadřízeným - v zásadě platí pravidlo, že pokud chcete na projektu nasadit automatizované testy a nedokážete zákazníkovi přesně říct, co mu to přinese (respektive kolik tím ušetří), na automatizaci rovnou zapomeňte. Pokud to ovšem nechcete dělat na vlastní triko po pracovní době (i tak se to sice dá dělat, získate alespoň nové zkušenosti - dlouhodobě je to ale nemotivující).

Poslední problém co mě napadá (i když ten nejméně "kritický" ze všech uvedených) spočívá ve výběru nástroje, obzvlášť pokud ho chcete koupit nejen kvůli jednomu konkrétnímu projektu, ale hledáte něco univerzálního pro více typů projektů a technologií.
Tady platí, že u "jednorazových akcí" můžete s klidem sáhnout po open-source nástrojích (Selenium, AutoIT a další), svou práci udělají spolehlivě, pokud se trefíte do podporované technologie. V případě "univerzálů" musíte bohužel sáhnout po komerčních produktech - které jsou většinou pro běžného uživatele strašně drahé, takže budete rádi za jednu licenci (QuickTest Pro, Rational Functional Tester a další).
Já jsem si oblíbil TestComplete, jelikož svými funkcemi plně vyhovuje mým potřebám a navíc byl i podstatně levnější, než jiné nástroje podobné kategorie. Každému ale vyhovuje něco jiného - jediné co mějte vždy při výběru nástroje na paměti je přínos, podpora technologií vašeho projektu a cena (přeloženo - jestli se koupě "vleze do rozpočtu projektu").

S jakými dalšími problémy jste se při zavádění automatizace setkali? Vyjádřete se v diskuzi, názory a zkušenosti jsou vítány!

Příště napíšu trochu podrobněji o tom, za jakých podmínek se vyplatí automatizovat testy, které typy testů jsou vhodné a které se naopak automatizují velmi obtížně.