Automatizované testování poskytuje mnoho výhod:

• snížení nákladů,
• zkrácení doby dodání,
• minimalizace rizika chyb v produkci, čímž se zlepšuje celková kvalita výsledného produktu,
• a další. A další. A další.

V tomto článku se budeme podrobněji zabývat naší cestou k automatizovanému testování a sdílet některé důležité aspekty, které by i vám mohly pomoci pro úspěšné zavedení do vývoje.

Proč s automatizovaným testováním začít

Regresní manuální testování může být časově náročné a zároveň méně spolehlivé. Proč? Protože je provádí lidé. A lidé dělají chyby.

Oproti nim stroj provede úkol vždy stejně. Kromě toho vám automatizované testování umožní věnovat více času scénářům, na které by jinak nebyl čas.

Je však důležité poznamenat, že automatické testy nemají nahradit manuální testy, ale spíše je doplňovat.

Oba typy mají své místo a čas ve vývojovém cyklu.

Produktový vs agenturní vývoj

Do Futured jsem přišel z firmy, která měla svůj vlastní produkt a kde byla automatizace doslova na denním pořádku. Nástup do agentury, kde se automatizace téměř neřešila, byla pro mě tedy výzva a zkouška zároveň.

Prvním krokem bylo téma otevřít na interní úrovni a nadhodit myšlenku zařazení automatizace do standardního procesu vývoje. Shodli jsme se, že se automatizovanému testování chceme věnovat, a tak jsme se vrhli na tooling a frameworky.

Průzkum a analýza

Často se stává, že firma, která chce začít automatizovat, najme seniorního Automation Engineera, od kterého se očekává, že hned začne sypat hromadu testů.

Neříkám, že je to nutně špatně, ale často to nemusí být správné řešení, protože tento externí člověk nemá potřebné povědomí o současných typech produktů. Může tak například zvolit framework, na který je zvyklý a ne ten, který nejvíce vyhovuje potřebám firmy a ostatním QA Engineerům. Nikdo asi nechce po desítkách hodin (v horším případě stovkách) zjistit, že vybraná technologie nevyhovuje.

Investujte čas do analýzy, vrátí se vám to.

Nesnažte se ale najít perfektní řešení hned na začátku. Po nějakém čase se podívejte zpět, jestli jste vybrali správně. Možná přijdete na to, že je potřeba využít jiný framework nebo i více frameworků. To byl třeba náš případ: Řekli jsme si, že nemá smysl hledat univerzální framework, kterým se dá automatizovat jak web, tak mobilní aplikace, a zvolili jsme nakonec dva.

Workshopy

Pokud ve firmě automatizace není součástí vývoje, tak QA Engineeři pravděpodobně testy psát neumí. Proto je důležité uspořádat workshopy, aby se budoucí uživatelé seznámili se základy programování, gitem a hlavně s frameworkem a best practices u psaní testů.

Určitě neočekávejte, že po třech workshopech budete schopni okamžitě psát testy. Je potřeba dát všem prostor, aby si framework osahali a vyzkoušeli v praxi. V rámci těchto workshopů je také vhodné diskutovat o přístupu a identifikovat oblasti, které lze automatizovat.

Nabídka klientovi

Ta skutečná výzva u nás nastala, když jsme chtěli automatizaci prodat klientům – implementace automatizovaného testování může být totiž vnímána jako zbytečné zvýšení nákladů. Proto je důležité vysvětlit přínos ve vývoji, ale hlavně, jaký přínos ucítí klient samotný.

Jakmile zmíníte, že psaní testů a jejich údržba stojí dost času, a tedy peněz, diskuze se značně komplikuje.

My jsme šli cestou osobních setkání, v rámci kterých jsme s klientem detailně prošli všechny benefity a prázdné titulky oživili skutečnými příklady z praxe.

Obecně jsme se hlavně zaměřili na benefit, který klienta zajímá nejvíce, což je šetření peněz. Ale jak se dají ušetřit peníze, když automatizace něco stojí? Aby si to klient dokázal líp představit, zařadili jsme do prezentaci i grafy. Ve zkratce jde o to, že čím déle se na projektu pracuje, tím více dává automatice smysl.

Celou prezentaci jsme uzavřeli živou ukázkou. Ukázali jsme jednoduchý End to End (E2E) test ve vývojovém prostředí. Zdůraznili jsme, že pokud je test správně napsaný, tak je i dobře čitelný pro netechnického člověka. Což v podstatě znamená, že testy můžou sloužit i jako dokumentace.

Následně jsme test spustili a dovolím si tvrdit, že až tato názorná ukázka klientovi demonstrovala sílu testů. Sledovat jejich zájem byla čirá radost.

Implementace a problémy

Když jsme dokázali automatizaci prodat, mohli jsme začít se samotnou implementací.

Ta vyžaduje spolupráci mezi vývojáři a testery. Například je chtěné, aby každá komponenta, se kterou potřebuje test pracovat, měla unikátní a neměnné ID. Na tento fakt musí myslet samotný developer a IDs přidávat už během programování.

E2E testy (na uživatelské úrovni) ale často nestačí. Potřebovali jsme tedy vyřešit i otázku tzn. unit testů, které píšou samotní developeři a jejichž cílem je ověřování správné funkčnosti dílčích částí neboli jednotek zdrojového kódu. Význam těchto testů je také často opomínán.

Čím dále jsme byli, tím více věcí jsme museli vyřešit. Budeme testy pouštět na reálných zařízeních nebo simulátorech? Lokálně, nebo remote? Automaticky během buildu, nebo manuálně? A kde budou vlastně testy uložené? A tak dále.

Během implementace vždycky narazíte na problémy a otázky, nad kterými jste během analýzy nepřemýšleli. Může to být díky komplexitě aplikace nebo zkrátka nedostatečnými znalostmi. Vývoj obecně je o řešení problémů. Důležité je se nezaleknout, nezastavit se a místo toho přijít s nějakým řešením a mít v záloze alternativní řešení.

Závěr

Na závěr je nutné zmínit, že:

⁠Automatické testy se nevyplatí implementovat všude a za každou cenu.

Je dobré se zamyslet nad hodnotou, aby nakonec investice nebyla vyšší, než samotný přínos. Pokud je například produkt hodně malý, časová investice může být daleko vyšší, než investice do manuálního testování.

Pro technické čtenáře je asi trochu zklamáním, že jsem nevěnoval více slov odstavci implementace. Mým záměrem ale není se chlubit, co používáme, proč a jak. Ve výsledku si myslím, že by vám to ani k ničemu nebylo.

⁠Tip: Podobná témata často řešíme na QA meetupu No Bugs Allowed, který ve Futured pořádáme. Sledujte nás na sítích, ať vám další neuteče.

Cílem tohoto článku bylo spíše nastínit, co je potřeba udělat, když se s automatizací začíná. A také demonstrovat, že každá mince má dvě strany a žádné řešení není univerzální. Vždy je potřeba analyzovat potřeby a po nějakém čase si položit otázku, jestli nám zvolený způsob vyhovuje.

Miro Ořeský je QA Lead. Jak o QA přemýšlí? Přečtěte si rozhovor.

Obrázky/vizualizace použité v textu jsme si vypůjčili od DigitalMara, Nextgen a Cypress.

–––

Úspěšnou aplikaci můžeme vytvořit a otestovat i pro vás.

Napište Lukášovi, který Futured založil: [email protected] & +420 605 312 459

–––

⁠Fotky označené písmenem W vznikly pro Futured profil na platformě Welcome to the Jungle.