Leckdo dnes sdílí zkušenosti s automatizací testů. I vzhledem k tomu, že jsem první skript vyprodukoval před cca 15 lety, jsem si řekl, že je na čase přispět i svou troškou do mlýna. Žádný strach, nepůjde o prehistorický příběh nostalgicky vzpomínající na muzejní technologie, ale o zkušenost z jara 2020. V článku najdete:

Charakter projektu

Zadání

Agilní tým standardní velikosti (tj. cca 8 lidí) dostal za úkol vyvinout aplikaci, která pomáhá urychlit proces ověření zdravotní způsobilosti pracovníka pro vstup na pracoviště. Typický scénář je následující: Brzo ráno přijde zaměstnanci SMS s odkazem, pod kterým se schovává dotazník indikující možnost nakažení virem Covid-19. Před vstupem na pracoviště pověřený vrátný na svém mobilu zkontroluje, že přicházející pracovník vyplnil dotazník a změří mu teplotu, kterou též vloží do aplikace. Pokud aplikace nevyhodnotí riziko nákazy, zaměstnanec je šťastný, že může pracovat, a je vpuštěn na pracoviště. Zajímají-li vás podrobnosti, můžete se podívat na detailnější demonstraci celého procesu.

Design aplikace je primárně přizpůsoben mobilním telefonům. Dotazník ve formě wizardu předhazuje uživateli obrazovky s jednotlivými dotazy: podle toho, jak uživatel odpoví na jedné obrazovce, ho směruje na další obrazovku. Aplikace vypadá velmi podobně jako například tento indikativní test.

Použité technologie a nástroje

V rámci analýzy byly použity nástroje pro grafický popis obrazovek Figma a na diagramy draw.io, ve kterém byl zachycen rozhodovací strom pro směrování uživatele mezi obrazovkami.

Řízení projektu probíhalo v Jira Kanban projektu, procesně pak dle Scrumban metodiky. Oblast testů pokrýval Jira plugin TM4J. Veškerý kód byl samozřejmě uložen v repozitářích s podporou verzování (GitLab).

Frontend aplikace je vytvořen v javascriptovém frameworku React, který přes REST rozhraní volá služby nad backendem v Javě a menší persistencí v PostgreSQL.

K automatizaci GUI testů byla použita tradiční kombinace Robot Framework s knihovnou Selenium, respektive Karate na API testy.

Testovací strategie

Cest, kterými uživatel mohl být směrován mezi obrazovkami, bylo mnoho (neboli rozhodovací strom aplikace byl velmi košatý). Od začátku bylo tedy nabíledni, že si nevystačíme s manuálním testováním. Automatizované GUI testy dostaly za úkol pokrýt všechny možné varianty průchodu rozhodovacím stromem a být vyvíjeny společně s aplikací.

Servisně orientovaná aplikace vyzývala k použití automatizovaných API testů, takže souběžně s dokončováním jednotlivých API, byly implementovány i API testy. Zároveň bylo cílem pokrývat skrze volání API celý proces, tj. simulovat kompletní use case, kdy frontend aplikace nasbírá od uživatele odpovědi z dotazníku a odesílá je přes API k dalšímu zprocesování, které končí ne/doporučením nástupu zaměstnance do práce.

Architektura testů

GUI testy

Testy byly navrženy se zřetelem na jejich snadnou udržovatelnost a flexibilitu při pozdějších změnách. Dnes stále ještě populární technika „Record&Replay“ tedy nebyla vůbec použita. Aplikace organizovaná do jednotlivých obrazovek indikovala použití návrhového vzoru POM .

Testy musely dále splňovat velmi snadnou a rychlou tvorbu v mnoha variantách průchodů rozhodovacím stromem, jednak z důvodu zmíněné flexibility a také z důvodu vytváření test casů (test)analytikem bez technických znalostí nutných ke scriptování.

Celé řešení tak sestávalo ze tří vrstev:

1. Test Cases: průchody rozhodovacím stromem, tj. obrazovky dotazníku s vyplněnými daty a seřazenými v očekávaném sledu
2. Screens: implementace všech obrazovek, tj. logika jejich vyplňování
3. Shared support libraries: podpůrné technické komponenty, usnadňující implementaci obrazovek (naskriptování určitých sdílených UI prvků, nezbytná podpůrná komunikace přímo na API, atp.) a umožňující specifické konfigurace testů (typ browseru, headless mode pro spouštění v CI, atp.)

Krom benefitů implikovaných POM přístupem umožnila tato koncepce i další podstatnou výhodu: test design testovacích případů mohl vznikat prakticky nezávisle na implementaci obrazovek. Stačilo znát jejich název a strukturu dat, což bylo definováno už v rámci návrhu designu obrazovek (viz Figma výše).

API testy

V případě API byla situace jednodušší. Každé API bylo pokryto elementárním testem. Tyto elementární testy byly dále použity i pro E2E scénáře pokrývající několik málo happy day use casů.

Hlavním účelem API testů bylo prověřit celkovou kondici aplikace, aby mohla být testována. Někdy se takové testy označují termínem „health check“. Neboli bezproblémový průběh API testů byl kritériem pro spouštění GUI testů.

Výhodou API testů bylo i to, že exekuce kompletní testovací sady byla velmi rychlá (v řádu sekund), čili nebyl problém API testy spouštět velmi často, například při každé změně kódu vývojářem.

Design a implementace testů

GUI testy

Jak bylo zmíněno výše, GUI testy jsou implementovány na platformě Robot Framework podporované knihovnami SeleniumLibrary a REST.

Test cases: každý jeden test case reprezentuje jeden průchod rozhodovacím stromem aplikace. Typický test case tak sestává krom zahajovacích, respektive ukončujících, direktiv (Intro, resp. Closure ) jen ze seznamu obrazovek. Například v test casu Symptom 1 | Below 40| worsening klíčové slovo pass symptoms fever říká: „Na obrazovce s otázkami na symptomy vyber, že máš horečku, a pokračuj dále“.

Screens: obrazovky jsou uloženy v repository (jedno místo v adresářové struktuře projektu).

Shared support libraries: sdílené technické komponenty jsou umístěny samostatně. Jde typicky o různé „vychytávky“, které si přinášíme jako zkušenosti/tipy z jiných projektů, ale i o pomůcky specifické pro daný projekt.

API testy

Implementace API testů stojí na platformě Karate používající klíčová slova ve stylu Cucumber. Příklad izolovaného testu konkrétního API je triviální:

I v API testech byl záměr přepoužívat elementární testy umístěné v jedné repository. Uložení dat dotazníku z příkladu výše tak najdete i v příkladu E2E průchodu procesem:

Volání testů z repository je realizováno pomocí:

Když chceme nějaký test volat v sekci Background, která v Cucumberu obsahuje kroky platné pro každé Scenario, použijeme:

Operace callonce zajistí, že reálné volání proběhne jen napoprvé a výsledek se uloží do cache pro další volání v rámci ostatních Scenarios ve Feature. Detailněji viz dokumentace.

V kódu příkladu stojí za povšimnutí i kód realizující integraci na Slack:

Projects Highlights & Downfalls

Co bylo fajn

1. Být součástí vyladěného týmu
Nástroje a metodologie mohou být super, ale vždy se nakonec ukáže stará pravda, že vše je o lidech. Pakliže se sejde tým podobně motivovaných lidí, které práce baví, jsou profesionály (rozumí své práci a dokážou se správně zeptat, když něco nechápou), pracují pro tým (snaží se pomáhat, efektivně komunikují, je jim cizí „nechat ho v tom vykoupat“), je to moc hezký zážitek. A teprve pak ony nástroje a metodologie, pokud jsou správně vybrané a používané, dokáží reálně zvýšit celkovou efektivitu týmu.

2. API testy
Framework Karate se snažím šířit mezi testery a aplikovat na projektech už nějaký ten pátek, důkazem budiž moje přes rok stará propagace na TestStacku ;] Krom technických předností je zajímavý svým konceptem žádného GUI. Nakonec zjistíte, že klikání a vyplňování boxů v dnes populárních nástrojích (Postman, Insomnia, soapUI, apod.) prostě jenom zdržuje. Aplikace napsaná čistě v kódu navíc umožňuje používat verzovací systém (v našem případě osvědčený GIT), tzn. usnadní flexibilně spolupracovat v testerském tým, transparentně sdílet testy (typicky do vývojářského týmu), efektivně a spolehlivě se napojit do CI/CD orchestrací.

Co trochu zabolelo

Hlavní nepříjemné překvapení (a asi jediné) z projektu byla bezzubost knihovny Selenium pro RobotFramework vůči JS framework React.

Selenium pro RF obsahuje řadu praktických klíčových slov simulujících akce na webové stránce. Musí se však používat obezřetně, protože React a JS frameworky obecně vycházejí primárně z elementárních akcí uživatele: stisk klávesy a mouse click (případně mouse down/up). Takže například klíčová slova, která vybírají položku ze seznamu, použít prakticky nelze.

Další problém je komplexnost aplikace v JS jako taková. Často podle vizuálních komponent nepoznáme, zda aplikace na pozadí ještě něco neprocesuje (např. nějaké asynchronní ajax volání).

Aby testy byly stabilní, doporučuji držet se při zemi s výběrem klíčových slov pro simulaci akcí uživatele. Osvědčilo se mi:

• Vystačit si s několika málo klíčovými slovy na simulaci interakcí uživatele:

• Nepodceňovat kontroly toho, že daná obrazovka/komponenta je ready (s těmi doporučuji rozhodně nešetřit):

A veškerou komplikovanější logiku zapouzdřovat do uživatelsky definovaných klíčových slov (user keywords).

Toto téma by si však zasloužilo samostatný článek.

Autor: Viktor Terinek

Viktor sbírá zkušenosti na poli testování softwaru už více než 15 let. Za svou kariéru vystřídal prakticky všechny výkonné testerské role spojené s analýzou, designem a implementací testů, včetně různých dimenzí automatizace. Prošel si několika manažerskými rolemi a aktuálně se naplno věnuje zefektivňování testovacích procesů a navrhování nových řešení. Těší se, až své zkušenosti uplatní i v rámci vašeho projektu.