Dříve nebo později se většina projektů rozhodne implementovat automatizace testování. Bohužel jsem ale neslyšel moc úspěšných příběhů.

Do automatizací se tým vrhne s velkým očekáváním a motivací.

Velice rychle ale přichází střet s realitou, demotivovanost, neúspěch.

V tomto článku bych se rád podíval na důvody neúspěchů a jak se jim vyhnout.

Nerealistická očekávání

V posledních letech probíhá pravidelná masáž medii, jak bude člověk nahrazen roboty a automaty. Toto se potom promítá i do očekávání na projektech od automatizace. Mnohokrát jsem se setkal s přístupem:

Chceme zavést automatizaci testování a postupně ve střednědobém výhledu zrušit manuální testování.

Je toto správný přístup, který se setká s úspěchem? Z mých zkušeností nikoliv.

Zásadní potíž je v tom, že dle mého názoru dnes nelze plně nahradit manuálního testera.

Skript nepřemýšlí, dělá jen to, co se mu naprogramuje, alespoň prozatím.

Testerovi vizuální kontrola stránky zabere několik minut. Ve skriptu to mohou být stovky řádků kódu.

Vývoj takového testu může zabrat celé dny, někdy i týdny.

Skripty s příliš mnoha kroky jsou nestabilní, trvá je dlouho vyvinout.

Pokud je zvolen tento přístup, dost možná se testování stane úzkým hrdlem ve vývoji software. Což je naprostý opak toho, co se očekává.

Druhou možností je přístup:

Začneme automatizovat a uvidíme co se z toho vyvine

Začít vytvářet nový produkt (ano, automatizace testování lze brát jako produkt) bez definice cílů je nesmysl. Testeři často skáčou do automatizace bez toho, aniž by je nadefinovali.

Celá aktivita je odsouzena k zániku

Výsledkem může být anarchie a zmatek. Nikdo neví co dělá, proč to dělá a celá aktivita je odsouzena k zániku.

Jak z tohoto ven?

Stačí velice málo. Sednout si, zamyslet se nad tím, co může automatizace přinést, nejlépe s někým, kdo má s automatizací zkušenosti a nadefinovat krátkodobé, udržitelné cíle.

Jak takový cíl může vypadat?

Automatizace regresních testů, repetitivních činností, jako je například příprava testovacích dat, vytvoření sanity checků.

Konkrétněji například:

Pokrytí prioritních regresních scénářů do 3 měsíců, automatizované spouštění v Jenkinsu.

Automatizace testování většinou nepřinese ušetření. Zlepšuje zejména efektivitu, rychlost testing dodávání.

Dlouhá doba vývoje

Stává se, že se tým nadšeně pustí do práce. I když ale pracuje naplno, dlouho není vidět žádný výsledek.

Může se stát, že management tuto aktivitu omezí nebo dokonce zastaví. Proč také investovat peníze někam, kde nevidím ani po půl roce žádný výsledek.

Jak z toho ven?

Mám rád metodu doručování quick wins. Jsou to malé dodávky, které ale již přináší benefit v extrémně krátkém čase. Příklady:

• Zautomatizování malé, ale kritické oblasti, například test přihlašovací funkce
• Spouštění testů každý den z lokálu a reporting management
• Rozsekání větších testů na menší celky a dodávání postupně

Mám jednoduché pravidlo. Pracovat jen na tom, co zrovna potřebuji. Žádný vývoj do šuplíku.

Syndrom věčně červeného, zeleného testu

Rád bych popsal 2 extrémy, které vedou většinou k restartu celé automatizace nebo dokonce jejímu zrušení v týmu. Jedná se o 2 póly, které jsou rozdílné, ale mají spoustu společných vlastností.

Jedná se o takzvaný syndrom věčně červeného/zeleného testu. O co se jedná?

Syndrom věčně červeného testu

Je stav, kdy automatizace ve většině případů končí neúspěchem.

Tento neúspěch je způsoben například chybami ve skriptech.

Může se jednat o timeout, nestabilní identifikátory nebo také špatně napsané testy.

Pokud se dlouhodobě nedaří stabilizovat běh testů, aby dávaly vypovídající hodnotu, pak dochází k:

Co bývá příčinou věčně červeného testu?

• Nestabilní identifikátory, aplikace nepřipravená pro testování
• Bad practises v kódu – spaghetti styl, ignorace objektového přístupu, nepřepoužitelný kód, duplikace kódu…
• Špatně napsané testy – v rozporu s očekávaným chováním v aplikaci
• Nestabilita testovacího prostředí
• Neudržování testů

Syndrom věčně zeleného testu

Je pravý opak červeného.

Test ignoruje chybu

Běh testů je úspěšně dokončený, i když je v aplikaci chyba.

Na první pohled to nevypadá, ale tato situace je mnohem víc nebezpečná, než syndrom věčně červeného testu.

Co se může stát?

To je ale špatně!

Test by v sobě pokud možno neměl mít podmínku a měl by být deterministický (jednoznačný).

Mám jednoduché pravidlo při psaní testů:

Testovací skript nesmí mít žádné podmínky!

Automatizují se výhradně GUI testy

Automatizují se zejména end to end GUI testy. Integrační testy jsou ve velkém ignorovány.

Ano, toto je častý případ.

GUI test je zajímavější, je vidět, že něco kliká.

Je to ale to, co by se mělo automatizovat jako první?

Podle mě ne.

Pokud se budeme držet principů Test pyramidy, je přeci jasné, že musí dostat přednost integrace.

Věřím, že automatizace například API testů dokáže přinést benefit v testování rychleji a efektivněji, než GUI automatizace.

Nekompetentnost

Pravděpodobně vznikne spaghetti kód, který je po nějaké době nutné přepsat. V horším případě celý smazat a napsat znovu.
To spotřebovává nejen zdroje, ale i trpělivost a důvěru managementu.

Před začátkem automatizace testování doporučuji projít alespoň základním kurzem na nástroj, který se bude používat.

Také je dobré se naučit základy programování.

Následně je dobré mít jako mentora zkušenějšího engineera nebo alespoň vývojáře.

náhrada manuálních testů 1:1

Automatický skript = regresní end to end test?

Může to být chyba a ubírat na efektivnosti automatizací.

Čím jsou skripty obtížnější a delší, tím jsou méně stabilní a udržitelné.

Psát testy 1:1 k manuálním regresním testů není dobrý nápad.

Automatické testování je obecně velice efektivní v případě jednoduchých, deterministických testů.

Zajímavou možností jsou například atomické automatizované testy (AAT). Zajímavý článek naleznete zde.

Automatizovatelnost aplikace

Ne všechny aplikace jsou vhodné pro automatizaci testování.

Jak se pozná vhodnost, zda-li je aplikace automatizovatelná?

Jeden z klíčů webové automatizace je determiničnost jejího procesu. Pokud nedokážu určit, jak se aplikace v různých situacích bude chovat, zadělávám si na problém.

Další jsou identifikátory HTML elementů.

Pokud nemáte jednoznačný identifikátor, nejméně ten, který se používá pro vývoj, testy nebudou stabilní a opět nastoupí problémy.

Stabilita, odezva prostředí. Padající nestabilní prostředí způsobí pády skriptů, které ve většině případů nemáte jak ovlivnit.

Před spuštění automatizování je nejdříve nutné vyřešit i tuto stabilitu.

Spouštění z lokálního PC

Stává se, že automatizace testování je spouštěna ručně z lokálního počítače.

Jasně, při vývoji testů je to efektivní možnost, jak si skripty otestovat.

Dlouhodobě tento přístup způsobí, že se nevyčerpá potenciál automatizace.

Problémů s přístupem ručního spouštění je spousta.

• Závislost na člověku, který testy spouští.
• Škálovatelnost
• Čas spouštění
• Riziko ztráty dat
• …

Nejlepší způsob je testy napojit na DevOps a spouštět testy na pravidelné bázi.

Například každé ráno před startem pracovních hodin.

Špatný výběr nástroje

V neposlední řadě může automatizování testování zhatit špatná volba nástroje.

Tak jako u dalších oblastích testování je potřeba správně vybrat dle kontextu.

Pokud vyberete nástroj, který je určený pro jednoduché aplikace, do bankovního prostředí.

Může být sice velice jednoduše použitelný, bude mít rychlou implementaci.

Nebude ale zcela jistě mít dobře řešitelnou přepoužitelnost a udržitelnost.

Druhý extrém je použití vlastnoručně vyvinutého frameworku, například v Java na jednoduchou Android aplikaci.

Implementace bude dlouhá a drahá. Tady klidně postačí jednoduchý nástroj.

Shrnutí

Co z toho všeho plyne?

Automatizace testování je samotná část v SDLC (Software Development Life Cycle), a tak je k ní potřeba také přistupovat.

Projekt určitě nenajme místo vývojáře analytika nebo místo testera projektového manažera.

Pro vývoj se používají nástroje, které jsou vhodné pro daný produkt.

Vývojáři nenahrazují architekty.

A tak dále…

Když to jde u jiných částí vývoje, proč by to nemělo jít v automatizaci testování?