Základy Continuous testingu

Každá firma, která to s testováním  svého produktu myslí vážně, se dříve nebo později začne trápit tím, jak samotné spouštění testů co nejvíce zautomatizovat . Tím omezí nejen dopad lidských chyb na testování, ale hlavně zrychlí zpětnou vazbu testů k vývojářům, manažerům a všem dalším kolegům na projektu. Continuous testing pak představuje způsob, jak se s tímto trápením vypořádat. V tomto článku se dozvíte:

• Co je to Continuos testing

• Proč se vyplatí s Continuous testingem začít

• Jak postupovat při integraci Continuous testingu

Co je to Continuos testing?

Continuous testing (dále jen CT) je proces, který spouští automatizované testy a vrací nám zpětnou vazbu s riziky, které by mohla obsahovat nová verze programu. Co si z toho ovšem má vyvodit tester?

Podoba dnešního testování je často taková, že automatizační scripty, či jejich skupinu (rozumějte kolekci testů), spouští tester buď po příchodu do práce, nebo naopak těsně předtím, než odejde domů. Často se také vytvoří skupina testů, které vývojáři pouští předtím, než například mergují kód z vývojových větví do master větve v Gitu, nebo si tester musí dávat třeba připomenutí na to, že každé uterý v 11:00 musí pustit script na pročištění databáze atd.

Všechno to jsou únavné a otravné záležitosti, které dnes lze naštěstí dělat zcela automaticky. A to je přesně to, co znamená CT pro běžného testera. Usnadnění a hlavně vyhnutí se mnoha chybám, které mohou vznikat díky lidskému faktoru nebo nedostatku času, a tedy přenesení co nejvíc manuálního spouštění testů do takzvané Pipeliny (pokud pracujete v githubu, tak Workflow), což není potrubní trubka, ale nějaký konfigurační soubor, který našemu nástroji pro CI (Jenkins, Github etc.) říká, co, jak a kdy spustit.

Nejlépe si výhody CT můžeme ukázat na dvou scénářích, ve kterých popisuji své dva zážitky před implementací CT. Ty ukazují, jak nám může CT a jeho integrace do běžných procesů výrazně urychlit a zlevnit práci.

Jako první scénář, který potkáváme dnes a denně v Teseně, může posloužit situace, ve které jako hlavní hrdinové figurují regresní testy na front-end. Ty kontrolují, zda nám v nové verzi webové aplikace fungují všechny prvky stránky (například tlačítka) správně.

Příklad Pipeliny v Gitlabu

Testujeme webovou aplikaci, kdy nám každé pondělí v 17:00 vývojáři dají k dispozici novou verzi a my potřebujeme pomocí automatizovaných testů provést regresní testování front-endu, abychom zjistili, zda nám všechna tlačítka fungují správně.

Bez CT by v úterý ráno bylo potřeba spustit běh regresních testů, pak vzít výsledky a prokousávat se jimi. V závislosti na velikosti těch testů, byste mohli mít hotovo okolo středy dopoledne.

S CT se toto vyřeší jen pomocí pár řádků kódu, kdy můžete použít třeba Playwright a spouštění pipeline (na Githubu pojmenované jako workflow) v předem určený čas, plus ještě výsledky vyreportovat do Reportportalu.

Tento kód nám pomocí syntaxe cron (zápis času ve formátu cron) spustí každý první den v 17:30 regresní testy v Playwrightu a ještě nám vytvoří report, který odešle do ReportPortalu. Díky tomu ušetříme peníze projektu a čas testerům, kteří se můžou věnovat něčemu jinému, než dohlížení na to, zda testy běží a byly spuštěny ve správný čas. K tomu všemu máme v úterý hotové nejen testy, ale díky automatickému odeslání výsledků do reportovací aplikace získáme i reporty bugů, které se dají sdílet s vývojáři a ostatními lidmi podílejícími se na projektu.

Druhý scénář nemusí být platný na každém projektu, přesto jsem se již několikrát setkal s tím, jak někdo pushnul kód i s přihlašovacími údaji do gitu.

Tester po napsání automatizačních testů a jejich commitnutí udělal push request na githubu. Nyní čeká na schválení seniora, aby mu řekl, zda je vše v pořádku. Tento senior nyní musí projít test a ptát se: „Co když tyto testy obsahují nějaké důležité informace? Třeba přihlašovací údaje k síti nebo SSH klíč?“

Bez CT byste museli jako seniorní testeři projíždět všechny proměné, popř. testy, a hledat zda tam někde není ukrytá proměná se jménem, heslem nebo klíčem.

S CT toto vůbec nemusíte řešit, příkladem budiž níže uvedený kód z Githubu, kdy si nastavíte Workflow a vložíte do ní těchto pár řádků (vysvětlení co tento kód dělá je uvedeno níže):

Tyto řádky kódu nám zařídí, že se adresář pullne do dockeru, který má v sobě ukrytý nástroj jménem Gitleaks . Ten nám následně na to, projde repozitář, zda tam není někde ukryté třeba heslo. Díky tomu víme, že nám během mergování či pushování neutečou interní informace do světa.

Proč se tedy pouštět do CT?

Správně by tato otázka měla být postavena spíš nějak takto: „Proč ještě nemáte CT?“. Z výše uvedených příkladů je zcela jisté, že díky CT můžete:

• Ušetřit náklady za zbytečnou a zdlouhavou práci několika testerů
• Zkvalitnit dodané testy a jejich výsledky
• Zrychlit testovaní mnohdy i o více, než jen pár dní
• Při využívání toho, že se spouští testy automaticky při každém pushi nového kódu, se dá velmi jednoduše vyvarovat mnohým bugům
• A mnohé další faktory, který dáme prostor třeba příště...

Integrace CT

Možná by vás potom všem mohly napadnout dva argumenty, které slýchávám docela často. Za prvé: Na to, abychom s CT začali nemáme budget. A za druhé: my už děláme CI/CD a nevíme, jak to integrovat. Proto si teď vysvětlíme, proč se nemusíte ani jedním z těchto komentářů nechat zastrašit...

CI je Continuous integration a znamená slučování různých verzí kódů od různých vývojářů do sebe, klidně i několikrát za den. Tedy klasická práce s Gitem.
CD je Continuous delivery či deployment, a znamená automatizované dodání aplikace či patchů do ní. Lze si to představit tak, že každý týden ve středu se nám zabalí/zkompiluje kód, který máme na Githubu, či na jiném úložišti, a vyšle se do světa (k zákazníkům).

Pokud CT nemáte

Není čeho se bát. Začít s CT nic nestojí. V dnešní době CT poskytují zdarma (byť v nějaké omezené míře) i největší hráči na trhu - GitHub nebo GitLab. Můžete taky začít používat jeden z nejznámějších nástrojů - Jenkins.

Pokud již máte CI/CD

Pak vám rozhodně nic nebrání v tom, abyste začali používat CT, který je součástí běžných CI/CD pipeline, takže časová náročnost začlenění CT do vaší Pipeliny/Workflow se bude pohybovat v řádu jen několika minut, popřípadě hodin.

Závěr

Z těchto a mnoha dalších důvodů, by mělo být zcela jasné, že dříve nebo později bude běžné mít CT na všech větších projektech. Tak jako je dnes normální snažit se dát testy, u kterých to má smysl, do automatizované podoby. Dobrý CT zkrátka dokáže ušetřit nervy, čas, a tedy i peníze vaší firmě. Nevíte, na koho se obrátit? V Teseně máme s implementací Continuous testingu bohaté zkušenosti, takže vám s tím rádi pomůžeme.