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.

Nejdříve se připravuje framework, nastavují se nástroje. Měsíc je pryč.

Následně se začnou psát testy a připravovat devops prostředí.

Zjistí se, že testy nejsou stabilní. Musí se předělat aplikace, doplnit ID.

Najednou je půl roku po spuštění vývoje a výsledky nikde.

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:

Frustraci vývojářů automatů
Nedůvěra v týmu k automatům, nechuť spouštět
Nedůvěru managementu “Seš si jistý, že pád automatů není chyba ve skriptu?”
Vypínání problematických testů
Omezení aktivit automatizace
Zastavení projektu automatizace testů

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?

Test může přehlédnout chybu!

A ta se poté může dostat do produkčního prostředí. Dopady pak mohou být katastrofální.

Syndrom věčně zeleného testu vzniká často z červeného testu.

Jak?

Jednoduše, pokud mi padá aplikace na nepředvídatelném chování aplikace nebo prostředí, mám tendenci tuto „chybu“ opravit tím, že do svého testu přidám podmínku, která situaci vyřeší.

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

Nadšený manuální tester se rozhodne, že začne psát automatizované testy.

Zdá se to jako logický postup.

Tak jednoduché to ale není

Často se stane, že tester je na automatizaci sám bez zkušeností a znalostí.

Toto byl bohužel i můj příklad.

Je to jeden z mnoha receptů na automatizační apokalypsu.

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í?

Spousta lidí přemýšlí o startu v IT, ale neví kde začít. Ať už jde o absolventa školy či člověka, který přemýšlí o změně kariéry. Často pokládané otázky jsou:

Jak začít?
Jak se mám do IT dostat?
Potřebuji školu či jiné dovednosti?

Pokud si tyto nebo podobné otázky pokládáš, pak je možná pro tebe testování to pravé.

A co to vlastně je?

Testing je nezbytná část vývoje Software i Hardware. V dnešním ultra rychlém světě je stále důležitější. Při dodávání nového produktu je potřeba reagovat co nejdříve, pokud možno okamžitě. Zbrklost, změny, stres, to jsou příčiny chyb.

Já osobně mám pocit, že postupem času je kolem mě stále více a více nefunkčních, chybových věcí. Koncový uživatel je až na samém konci. Hlavní cíl je dodat novou věc, i když je nekvalitní nebo nehotová.

A proto tu je testing. Testování pomáhá tyto chyby odhalovat a směrovat aplikaci či jiný produkt ke kvalitnějšímu provozu.

V tomto článku proberu, co je mých 10 bodů, proč vstoupit zrovna do testování.

1. Brána do IT

Neznám ani jediného testera, který by toto tvrzení měl rád. Trochu to snižuje hodnotu a profesionalitu našeho oboru.

Bohužel i bohudík je to pravda. Testování je často vstupní branou do IT. Proč? Nepotřebuješ totiž žádné dlouhé kurzy či školy. V některých případech je možné do testování vstoupit úplně bez zkušeností.

2. Jednoduchý start

Pro start v testingu není nutné mít vysokoškolské vzdělání ba ani umět programovat. Když to vezmu velmi s nadhledem, tak pro uchazeče o testování stačí umět pracovat s počítačem.

Pokud chceš mít při pohovoru šanci na úspěch, musíš se alespoň trochu orientovat v používaných nástrojích, vědět jak probíhá vývoj SW i umět používat aplikace, které běží v pozadí za tím, co normální uživatel vidí.

Toto naštěstí dokáží pokrýt mnohé akademie, které se zaměřují na předání znalostí nutných pro start. Jednou z nich je i Testovací Akademie, kterou pořádáme.

3. Plat

Je všeobecně známo, že IT nabízí nadstandardní platy. To platí i o testerech. Juniorní tester s minimem zkušeností si vydělá i 35.000 Kč, což je v Březnu 2022 téměř na úrovni průměrné mzdy v ČR, která je 37.047 Kč

Seniorní tester, s 6 lety praxe si může říct o 100 tisíc a víc.

Proč tomu tak je? Odpověď je jednoduchá. IT je obor, který se velice dynamicky a rychle rozvíjí a dlouhodobě v něm je nedostatek pracovní síly. To znamená, že firmy jsou nuceny bojovat o každého zaměstnance. Důsledek je takový, že platy v IT jsou takové, jaké jsou. Testing je v tomto ještě trochu vyjímečnější. Díky větší retenci (odchodovosti) jsou některé pozice velice nadstandardně ohodnoceny.

4. Výzva

Testování na první pohled vypadá lehce. Člověk přijde k aplikaci, nakliká něco dle skriptu a hotovo. Ono tomu tak ale úplně není. Rád říkám, že testing je jako Šachy, je snadné začít je hrát, ale stát se mistrem zabere ohromné množství času.

Každý den v testování přináší nové výzvy. Ať už to jsou zajímavé úkoly, situace nebo také použití nových nástrojů.

Jak dosáhnout co nejvyšší kvality aplikace nelze jednoduše popsat. Časem zjistíš, že dříve efektivní techniky začínají být netečné. Proto je potřeba stále vymýšlet a hledat nové způsoby, jak produkt testovat.

5. Rozmanitost

Testing je činnost, která je hodně rozmanitá. Jeden den tester analyzuje nový projekt, druhý testuje, třetí vytváří automatizované testy. Množství činností a cest k tomu jak dosáhnout co nejvyšší kvality aplikace je spousta. Je na tobě, jakou cestu k testování zvolíš. Je jich spousta a určitě se nebudeš nudit.

6. Je nás málo

Proč? Je to způsobeno několika faktory. Tím hlavním je to, že v IT je nedostatek lidí. Díky průmyslu 4.0 je transformace podniků rychlejší, než stačí trh a školy reagovat. Proto je málo nejen testerů, ale i jiných technických pozic v IT jako jsou programátoři nebo analytici.

Další důvod, proč je na trhu nedostatek testerů, zvláště seniornějších je vysoká odchodovost. Tester je univerzální „bojovník“. Musí umět jak technickou část, musí umět komunikovat, tak řešit business situace. Následně už stačí jen ta správná příležitost a z testera je například business analytik.

7. Soft i hard skills

Ač to dle názvu „Testování“ vypadá, testování není pouze o tom, že tester ověřuje funkčnost aplikací. Exekuce (ověřování funkčnosti) je velká část naší práce, jsou zde ale i další úkoly a odpovědnosti. Tester může na chyby upozorňovat již když se přemýšlí o nové funkčnosti. Ověřuje se i dokumentace, která vzniká ještě před začátkem vývoje. Pro naši práci potřebujeme znát produkt do detailu. Dokumentace ale často bývá povrchní či neúplná. To znamená, že si požadované informace musíme zjišťovat od analytika, klienta či vývojáře. Existuje také mnoho situací, kde může tester sdílet svůj názor nebo zkušenosti.

Toto všechno má za následek to, že tester k své práci potřebuje nejen technickou znalost (hard skills), ale také komunikační, měkké dovednosti (soft skills).

8. Rozvoj

Další z důvodu, proč si myslím, že je kariérní dráha testera zajímavá, jsou možnosti rozvoje. Svět softwaru je sám o sobě neskutečně rozmanitý. IT je v dnešní době již téměř všude. “Ajťák” má možnost se uplatnit od retailu až po automotive či bankovnictví. Může se rozhodnout jestli bude pracovat spíše s programy a aplikacemi nebo hardwarem.

To samé platí i o testerech. Nemusíme se však orientovat čistě na odvětví. Junior tester velice rychle narazí na křižovatku kam se vydat. Bude se ubírat spíše technickým směrem například do testování backend systémů? Nebo spíše zvolí cestu k zákazníkovi a komunikaci? Možná je ta správná cesta test management. Nebo rovnou může změnit celý obor a jít pracovat například jako projektový manažer.

Cest rozvoje je spousta a to dělá práci testera ještě víc zajímavou.

9. Komunita

Tak jako vývojáři, tak i testeři mají svou komunitu, kde si sdílí jejich znalosti a dovednosti. V Čechách je to například komunita [pro:]TEST!

Testeři se potkávají na diskusních fórech, meetupech nebo konferencích. Kdykoliv je možné poznat nové lidi nebo si například říct o pomoc či názor.

10. Homeoffice

V dnešní době již možnost pracovat vzdáleně není až tak vyjímečná. Je ale dobré zmínit, že práce testera je možná plně z domova či jakéhokoliv místa na planetě. Já si často prodlužuji dovolenou tím, že pracuji například z pláže.

Práce testera je v hodně ohledech zajímavá. Je však vhodná úplně pro každého? Jsou tu jen samá pozitiva? To určitě ne. Jsou tu i stinné stránky, ale o těch snad někdy příště.

Já svou testerskou kariéru miluji, jsem s mým oborem naprosto spokojený a práce mě naplňuje.

Zaujala tě práce testera? Chceš se stát jedním z nás? Tak to potom koukni na naši testerskou akademii!

Štítek: it start

9 důvodů proč selhává Automatizace testování