Menu

Test design pro automatické testy

Rád bych nastínil svůj pohled na to, jak připravit testy GUI pro automatizaci, bez ohledu na to, kdo bude testy automatizovat. Cílem tohoto textu ale není diktovat způsob psaní testů, spíše jde o to vyvolat diskuzi. Článek je zaměřený na běžné testování funkčnosti aplikace.
Vycházím ze svých zkušeností, kdy jsem psal zadání pro implementaci a následně automaty přebíral, stejně jako kdy jsem automaty vytvářel. Čím dál více mi přijde, že není možné napsat testy tak, aby byli na projektu všichni šťastní . . . nebo alespoň já ;). Když už nic, tak se můžeme co nejvíce přiblížit.

Výchozí stav

Jsou dvě výchozí situace:

  1. Projekt nezačal, nejsou testy. Ale ví se, že proběhne automatizace.
  2. Projekt začal, testy jsou napsané. Pomalu se připravuje automatizace.

První případ vypadá mnohem příjemněji pro automatizaci, protože testy lze od začátku tímto způsobem směřovat. Bohužel se musí počítat i s tím, že nejdříve testy proběhnou manuálně a automatizace začne až v případě stabilní a funkční aplikace.

V druhém případě se už dopředu musí počítat, že implementace bude složitější a bude kolem toho více práce i z pohledu manuálních testů.

Ani v jednom případě ale nelze garantovat, že se vyhneme problémům. Vždy záleží primárně na komunikaci v týmu a ochotě dělat kompromisy.

Teorie

Pro efektivní vývoj automatizovaných testů je potřeba stabilní a odladěná aplikace, na které již proběhly manuální testy. Především ty, jejichž cíl je shodný s plánovanými automaty.

Bohužel, 99% manuálních testů nelze plně automatizovat bez nějakého kompromisu. Důvodů může být víc, prakticky se to děje kvůli větší efektivitě u manuální exekuce (Když testuji vytvoření platebního příkazu, přece ho rovnou zkontroluji ve výpisech). Automaty jsou ale efektivnější v případě, že jsou testy rychlé, jednoduché a nezávislé. Možná proto funguje automatizace v některých přístupech používaných v agile (ATDD, BDD).

Testy by tedy měly splňovat tato pravidla:

  1. Testy musí být jednoduché / přímočaré
  2. Testy by měly být bez duplicit
  3. Testy musí být konkrétní
  4. Testy nesmí obsahovat manuální ověření akce
  5. Test musí mít jasný cíl

Projekt

Zpátky k projektu, máme scope testování a informaci, že se bude automatizovat. Je potřeba tedy napsat testy tak, aby podle nich mohli testeři otestovat aplikaci manuálně, následně byly testy automatizovány a následně bez náhrady vyškrtnuty z manuálních testů. Zní to docela složitě, že?
Hlavu vzhůru, nejde to. Vždycky se najdou problémy, které během automatizace testů budou, stejně tak kroky, které nepůjde automatizovat.

Výběr testů

První věc, nad kterou by test analytik měl začít přemýšlet je, které testy se budou automatizovat. Pokud to udělá, tak pravděpodobně vyřadí takové testy:

  • které jsou zaměřeny na vzhled
  • kde je zapotřebí manuální ověření

O zbytku řekne, že jsou určeny k automatizaci. Pokud chci mít automatizaci efektivní, tak je to druhý nejhorší způsob výběru scope (hned po tom, že se bude automatizovat vše).

Výběr testů by ale spíše měl kopírovat testovací pyramidu:

  • Nejdříve by se měly automatizovat jednoduché, přímočaré testy
    • Od nejvíce prioritních funkčností / procesů
    • Pokrytí co největší části aplikace
    • Bez ověřování v jiných aplikacích
    • Bez ověření po uplynutí určitého času (např. zaúčtování do výpisů)
  • Následují testy založené na datech (různá vstupní a výstupní data)
  • V případě potřeby (aplikace je veřejná) následují různé validační testy

Příprava testů pro automaty

Máme vybrané testy, ale buď je ještě nemáme napsané, nebo máme napsané automatizované testy, které ale moc neodpovídají našim představám. Nyní je na řadě úprava / vytvoření testů tak, aby automatizace proběhla hladce.

Testy většinou automatizuje specialista, a proto nepředpokládám, že by měl mít business znalost testované aplikace.

Přímočaré testy

Ověření (asserty)

Předpis pro automat by měl obsahovat informaci, kde je potřeba assert (ověření očekávaného výsledku). Asserty je potřeba umístit tak, aby ověřily cíl testu (klient se po založení objevuje v přehledu) a zároveň ověřily, že nedošlo k chybě (po úspěšném založení klienta se nezobrazí chybový text).

Zároveň se ale nesmí ověřovat všechno, primárně elementy, které test používá, nemá smysl ověřovat. Když budou chybět, test stejně spadne i bez assertu.

Akce

V přímočarých testech musí být zároveň vysvětleno, jak se celým procesem / funkčností projde. Obzvláště, pokud je více možností, jak danou akci provést:

  • Přechody mezi obrazovkami
  • Provedené akce
  • Upozornění, která je potřeba odkliknout

Co tam nepatří

Standardní věci jako ověření vzhledu, validací, manuálních kroků atd.. Hlavně by neměl test ověřovat každý svůj krok (standardní manuální kroky), protože testy tak ztrácí vypovídací hodnotu.

Pro začátek automatizace je vhodné se i vyhnout ověřování v externích programech (txt, pdf, word atd.), ale může se jednat o zajímavou investici, pokud se automatizace osvědčí.

V tomhle je opravdu dobré se z pozice test analytika trochu vcítit do role stroje (nemusí to být hned terminátor) a popsat i negativní ověření. V případě, že se vyskytne chyba, která brání testu v pokračování, ověření není potřeba psát, test spadne. Pokud se ale jedná jen o textové upozornění, tak je potřeba přidat krok, že tento text se tam nenachází.

Testy založené na datech

Tyto testy musí vycházet z přímočarých testů a liší se pouze tím, že je plníme jinými daty a ověřujeme výstupy do detailu.

Tyto testy by měly mít jasně označené datové vstupy a výstupy (ideálně i jejich vztah). Datové vstupy je potřeba popsat podle toho, jak se dají získat:

  • Hodnota splňující určitá pravidla (např. 2-místný číselný kód)
  • Číselník v aplikaci (seznam bank)
  • Číselník mimo aplikaci (rodinný stav)
  • Konkrétní hodnota, která se časem bude měnit (např. protiúčet, kde se platba bude kontrolovat)

Zároveň je ale potřeba i říct, jak mají být tyto hodnoty vybírány (náhodně generovaný / přesný výběr / všechny hodnoty).

Validační testy

Testy nevycházejí z předcházejících, a proto je potřeba zvážit, zdali má smysl je automatizovat a případně, které z nich. Navíc u těchto testů je nejpravděpodobnější, že automaty neověří celý scope.

Patří sem:

  • Ověření elementů na obrazovce
  • Ověření validací neplatných hodnot
  • Ověření přítomnosti a doslovné validace textů (lze použít v případě přidání nového jazyka)

Testy by měly být napsány jednotným stylem. Validace neplatných hodnot by měly být založeny na co nejpodobnějších typech vstupů, aby se nemusely pro každý element vytvářet nové metody.

Úprava manuálních testů

Z pohledu poměru cena x výkon se jedná o nejdůležitější část. Je hezké mít automatizovanou sadu, ale pokud obsahuje testy, které jsou stále obsahem manuálních testů (tzn. aktivně se testují i manuálně), tak splachujeme peníze a čas do záchodu.

Nejedná se o závěrečnou aktivitu, naopak by měla probíhat paralelně. Výhodou je, pokud úpravu testů pro automaty a manuální sady bude zastřešovat jeden test analytik. V takovém případě by mělo být rozdělení snadné.

Teoreticky se může stát, že automaty budou ověřovat všechny funkčnosti, ale vždy bude potřeba manuálně samotný vzhled aplikace (resp. v určitých případech se i ověření vzhledu dá automatizovat, ale to patří do jiného článku).

Závěr

Důležitý předpoklad pro úspěšnou automatizaci je mít připravené testy tak, aby:

  • Pro pochopení testu nebyla potřebná business znalost aplikace
  • V testu bylo popsáno, co se má kontrolovat (co se má a nemá zobrazit)
  • Testy neobsahovaly duplicitní kontroly a neztratily tak vypovídací hodnotu
  • Manuální sada vhodně doplňovala automaty

Nejdříve bychom měli automatizovat testy, které se zaměřují na ověření procesů / funkcionalit. Tyto testy by měly být jednoduché a přímočaré, ideálně bez kontrol v jiných aplikacích. Následovat by měly testy pro různé variace dat. Jako poslední by měly vznikat různé validační testy v případě, že je chceme zařadit do regresní sady.

V rámci údržby a dalšího rozvoje lze přemýšlet nad scope, který chybí. Cílem by ale mělo být co největší zjednodušení práce testerům, nikoli priorita ušetření peněz.

Comments

Napsal:

Ondřej Mudra
Test Automation Specialist

Dear user, this website uses cookies to ensure you get the best experience on our website. More about cookies
I give my consent to processing of my personal data. More info