Kruso Logo
Kontakt os

Muligheder for automatiseret web UI test.

Webtestautomatisering kan være en jungle med uendelige værktøjer og forskellige muligheder. Erik Henningson, vores tekniske forretningskonsultent, har undersøgt nogle af værktøjerne og har opsummeret sine tanker i dette blogindlæg.

Hvordan finder man den bedste automatiserede web UI-test

Webtest automatisering er et bredt vidensområde, og jeg vil umiddelbart ikke kalde mig selv for ekspert. Men for nylig brugte jeg noget tid på at undersøge mulighederne for automatiseret UI tests (det var et par år siden sidst) og jeg tænkte, at jeg ville dele mine tanker med jer. Jeg lavede denne undersøgelse da jeg på vores nuværende set up savner muligheden for at køre tests på forskellige enheder (hovedsageligt Safari og iPhone). 

Ofte er min rolle at være ansvarlig for en løsning fra et teknisk perspektiv. Jeg skal sørge for, at løsningen opfylder kundens behov, men selvfølgelig også sikre, at løsningen virker og fortsætter med at virke. 

At tjekke at alt fortsat virker i en konstant udviklende løsning hedder regressions testning. Normalt bruger jeg automatiseret UI tests til at lave regressions tests på en web app, hvor testene normalt er udløst af vores CI/CD løsning når vi deployer en ny release. Det hurtigt at kunne teste og tjekke om alle kritiske funktioner virker, gør mig sikker, når jeg implementerer ny kode og det hjælper også godt på min nattesøvn. 

Jeg startede med at lave automatiseret UI tests ved at bruge Selenium IDE for mange år siden, hvor jeg har kørt alle tests i browseren. Det var en forholdsvis lav-tærskel måde at starte med automatiseret UI tests. Siden da har jeg evalueret og testet adskillige og forskellige tilgængelige services/værktøjer. I perioder har jeg også været involveret I at lave og vedligeholde tests nærmest på daglig basis.

To hovedtilgange

Der er en del services/værktøjer, der tilbyder ens funktioner, når det kommer til det endelige resultat. Altså, at kunne teste funktioner og/eller visuel fremtoning i forskellige browsere. Dog har de forskellige services forskellige tilgange til, hvordan de når det endelige resultat. Jeg (til dels ignorant) inddeler disse tilgange i to hovedgrupper:

  • Følg dine interaktioner i en web browser og tilføj observationer (check om alt er som forventet) løbende. De interaktioner er så gentaget når testen kører. Der er en UI til at simplificere justeringer og vedligeholde din test, tilføje visuel sammenligning osv. For mig, er simplificering en prioritering over at have edge-case funktioner.

  • Definer kun dine tests og observationer i kode. Dog kan nogle services importere Selenium tests, så du potentielt kan bruge Selenium IDE til at følge og vedligeholde dine tests. Du bliver måske nødt til at indstille et test framework på din web app, eller bruge specifikke værktøjer til at vedligeholde dine tests. At have mange funktioner er prioriteret i forhold til simplificering.

Simplicitet er første prioritet

Simplicitet er min første prioritet. Hvis det ikke er simpelt at bruge, vil det formentlig ikke blive brugt overhovedet. For mig er det vigtigt, at alle udviklere i mit team kan lave eller opdatere tests ud fra en kort introduktion. Jeg har arbejdet på større projekter, hvor der rent faktisk har været et dedikeret team af testere, og hvor budgettet gjorde det muligt at bruge avancerede test værktøjer.

Men hvad sker der med løsningen når den modnes og blot skal vedligeholdes? Test teamet er væk, og udviklerne har hverken viden eller tid til at vedligeholde tests, eller lave tests for nye funktioner. Og det er lige nøjagtigt her du har mest brug for regressions tests!

Mine anbefalinger til testning

Jeg har kigget på adskillelige services/værktøjer (der er sååå mange…) og fundet nogle, der opfylder ”simplicitets”-kriteriet:

Ghostinspector (ghostinspector.com)

Jeg har brugt Ghostinspector i nogle år nu. Det er forholdsvis funktionsrigt med en meget fornuftig pris. Den gratis version kan få dig langt, og du kan bruge alle ledige funktioner. Det er muligt at importere og eksportere Ghostinspector tests i forskellige formater. Jeg kan godt lide, at jeg kan eksportere mine tests, hvis jeg beslutter mig for at stoppe med at bruge Ghostinspector.

Frontend Robot (frontendrobot.com) Frontend Robot er den nye dreng i klassen, der sigter efter at være enkel at bruge. Den har ikke ligeså mange funktioner som Ghostinspector. Jeg synes også, at måden man arbejder med Frontend Robot når man laver eller opdaterer tests er meget langsommere sammenlignet med Ghostinspector. 

Prisen for Frontend Robot starter fra 5 USD/month.

Mabl (mabl.com) Mabl virker også simpel at bruge og har nogle cool funktioner som ”auto-healing” (forsøger automatisk at fixe tests, som gik i stykker når UI’en opdateres). Jeg testede den ikke for alvor, da en af funktionerne jeg har brug for (email testing) kun er tilgængelig på ”Enterprise” niveauet. Jeg gider ikke bruge tid på ”Kontakt os for en personlig pris” (suk), så jeg går bare ud fra, at det ikke kan matche prisen fra Ghostinspector. 

Reflect (refelect.run)

Meget simpel og hurtigt til at lave og opdatere tests. Selve testene er også udført meget hurtigt. Jeg kan virkelig godt lide det her værktøj, og prisen er fornuftig. Men ligesom med Mabl skal du have ”Enterprise” abonnementet for at kunne køre email tests.

Desværre er der ingen af disse services, der har muligheden for at lave et cross-device testing. Hvis du virkelig skal bruge automatiseret cross-device testing, og du har ressourcerne til et mere komplekst test set up, tilbyder Browserstack, Saucelabs, Katalon, eller TestProject gode services, der kunne være et godt match. Men for mig er disse services bare ikke simple nok. 

På baggrund af al den her research vil jeg fortsætte med at bruge Ghostinspector til automatiserede tests. Jeg kombinerer det med sporadiske og manuelle cross-device tests ved at bruge Browserstack’s ”Live” testing funktion.

Og bare lige for god ordens skyld: Jeg har ingen tilhørsforhold med nogen af de services eller værktøjer jeg har nævnt i det ovenstående.