Prečo pôvodné riešenie nestačilo
Klient používal komerčný nástroj na vytváranie automatizovaných testov, ktorý sľuboval automatizáciu bez znalosti kódovania. Tento sľub platil do istej miery: juniorný tester v ňom vedel bez kódovania pripraviť prevažne jednoduchšie testy. Zložitejšie scenáre si však vyžadovali kapacity vývojárov. Testovanie tak súťažilo o kapacitu s vývojom produktu.
Nástroj navyše nevytváral vždy a vo všetkých situáciách stabilné selektory, teda pravidlá, podľa ktorých test vyhľadáva prvky v aplikácii. Aj automaticky vytvorené selektory preto potrebovali kontrolu a úpravy.
Cieľom nebola iba technická výmena nástroja. Nové riešenie malo znížiť závislosť od vývojového tímu, rozšíriť pokrytie a zachovať regresnú kontrolu aj počas migrácie.
Migrácia počas paralelnej prevádzky
Nový framework vznikol od nuly na open-source nástrojoch Selenium pre webové testy a Appium pre mobilné testy. Obe časti používali rovnaký design pattern Page Object Model, ktorý oddeľoval testovacie scenáre od selektorov a operácií nad stránkami či obrazovkami. Architektúra tak zostala jednotná, hoci technológie na ovládanie webu a mobilnej aplikácie boli odlišné.
Vybrané hodnotné scenáre sa prenášali postupne a pôvodná aj nová sada istý čas bežali vedľa seba. Až po overení náhrady bolo možné pôvodný nástroj úplne odstaviť.
Tento postup obmedzil riziko, že firma počas zmeny stratí dôležitú regresnú kontrolu. Zároveň umožnil neprenášať mechanicky všetko, ale sústrediť sa na scenáre s reálnou hodnotou.
Prevádzka, diagnostika a rozsah
Testy boli zapojené do GitLab CI/CD, dali sa spustiť na požiadanie a využívali paralelizáciu. Reporty zaznamenávali jednotlivé kroky, snímky obrazovky, konzolu prehliadača aj sieťovú komunikáciu, aby sa príčina zlyhania dala hľadať bez zdĺhavého opakovania.
Súčasťou riešenia bola okrem reportov aj error pattern analysis, teda analýza opakujúcich sa chýb. Jej prehľad ukazoval, v ktorých častiach testovacej sady sa sústreďovalo najviac zlyhaní. Tím tak na prvý pohľad videl najproblémovejšie miesta a vedel, kde začať s analýzou. Súvisiaci článok vysvetľuje, ako sa dá podobné zoskupovanie rozšíriť o triedenie zlyhaní pomocou AI.
- stovky webových a mobilných testov;
- automatizované accessibility kontroly;
- produkčný monitoring viacerých kľúčových ciest, ktorý bežal nepretržite z Kubernetes podu.
Čo sa zmenilo pre tím
- Pôvodný komerčný nástroj úplne nahradilo open-source riešenie.
- Vývojári už neboli potrební na vývoj a údržbu automatizovaných testov.
- Testy sa dali spúšťať v CI/CD aj na požiadanie a paralelizácia skrátila čakanie na výsledok.
- Diagnostické reporty pomáhali pri analýze konkrétnych zlyhaní a error pattern analysis ukazovala najproblémovejšie časti testovacej sady.
- Rovnaké riešenie pokrylo regresiu webu, mobilnú aplikáciu, accessibility aj vybrané produkčné cesty.