Test Automation Engineer

En test automation engineer laver kode, der tjekker andre folks kode. Målet er, at en fejl bliver fundet minutter efter, den er lavet — ikke uger efter, hos kunden.

Det er ikke det samme som en manuel tester. En manuel tester klikker sig igennem systemet og bruger sin næse. En test automation engineer bygger værktøjet, der gør det samme tusind gange i træk om natten.

Typiske opgaver

• Skrive automatiske tests af brugerflader, fx login, betaling eller bestilling
• Skrive API-tests, der rammer systemet direkte uden om skærmbilledet
• Sætte tests op til at køre automatisk ved hver kodeændring i CI/CD-pipelinen
• Undersøge røde tests om morgenen og afgøre, om det er en rigtig fejl
• Rette "flaky" tests, der fejler tilfældigt uden grund
• Bygge og vedligeholde testdata og testmiljøer
• Køre belastningstest, når systemet skal tåle mange brugere samtidig
• Rapportere resultater, så et team kan se, hvad der er brudt
• Være med til at vurdere, hvad der overhovedet kan betale sig at automatisere

En almindelig dag
Dagen starter tit med nattens kørsel. Fjorten tests fejlede. Tre er rigtige fejl. Elleve fejlede, fordi et testmiljø var nede eller et element flyttede sig på siden.

Den sortering er en stor del af jobbet. Du skal kunne læse en fejllog og afgøre, om problemet ligger i produktet, i testen eller i miljøet. Bliver du ved med at melde falske fejl, holder udviklerne op med at tro på dine tests.

Så kommer standup med teamet. Du er som regel en del af et udviklingsteam, ikke en separat testafdeling.

Resten af dagen går med at bygge nyt og vedligeholde gammelt. En ny funktion skal have tests. En gammel test skal skrives om, fordi flowet er ændret. Du laver code review på en kollegas testkode og sidder måske sammen med en udvikler om en fejl, ingen kan genskabe.

Det, ingen fortæller på forhånd
Vedligeholdelse fylder mere end nyudvikling. En testpakke, der ikke bliver passet, rådner på få måneder.

Du møder også et fast pres om at automatisere alt. Det er sjældent en god idé. Nogle ting er billigere at teste med hånden, og du skal kunne sige det højt med en begrundelse.

Hvor sidder man?
Rollen findes overalt, hvor software er forretningskritisk. I Danmark er det især bank, pension og forsikring, hvor fejl koster penge og tillid. Det er også de store it-leverandører til det offentlige, og produktvirksomheder inden for medico, industri og spil.

Bygger du til det offentlige, kommer tilgængelighed ind som testkrav. Webtilgængelighedsloven stiller krav til offentlige websteder og apps, og Digitaliseringsstyrelsen fører tilsyn med området. Arbejder du i medicinalindustrien, skal testene desuden dokumenteres og valideres efter GxP-reglerne.

Der er ingen uddannelse, der hedder test automation engineer. Til gengæld er der en klar fælles nævner: du skal kunne programmere. Uden kode kommer du ikke ind i faget i dag.

Den almindelige uddannelsesvej

• Datamatiker, 2,5 år. Kræver typisk gymnasial eksamen eller relevant erhvervsuddannelse plus matematik C.
• Professionsbachelor i softwareudvikling, 3,5 år. Bygger ofte oven på datamatikeren.
• IT-teknolog, 2 år, med mulighed for overbygning.
• Diplomingeniør eller civilingeniør i software, 3,5 til 5 år. Mere teori, mindre nødvendigt for jobbet.

Ingen af dem underviser tungt i testautomatisering. Det lærer de fleste på jobbet.

Vejen fra manuel test
Dette er den mest almindelige vej i Danmark. Du starter som manuel tester eller supporter og kender systemet godt. Så lærer du et sprog og et testværktøj og begynder at automatisere dine egne tests.

Den vej er stærk, fordi du allerede ved, hvad der plejer at gå galt. Det svære skridt er kodningen. Regn med et halvt til et helt år, før du selv kan bygge en testpakke fra bunden.

Vejen fra udvikling
Nogle udviklere skifter over, fordi de synes, kvalitet er sjovere end features. De har kodningen på plads. Til gengæld skal de lære at tænke som en, der leder efter fejl frem for at bygge.

Certificeringer
ISTQB Foundation Level er den mest udbredte i branchen. ISTQB har også et Advanced Level i netop testautomatisering. Certificeringerne udbydes i Danmark gennem ISTQB's danske medlemsorganisation, Dansk Software Testing Board.

Vær ærlig om værdien. ISTQB giver et fælles sprog og hjælper dig gennem en HR-screening. Den lærer dig ikke at skrive en stabil Playwright-test. Ingen arbejdsgiver ansætter på certifikatet alene.

Sådan kommer du ind uden erfaring

• Byg en lille testpakke mod en offentlig demo-webshop og læg den på GitHub
• Lær ét sprog ordentligt, typisk TypeScript, Python, Java eller C#
• Lær Git og en pipeline, fx GitHub Actions, så dine tests kører automatisk
• Søg stillinger som junior tester eller QA-engineer, ikke kun rene automatiseringsjob

Mange virksomheder ansætter hellere en nysgerrig kandidat med et lille reelt projekt end en med kursusbeviser og ingen kode.

Sprog
Du koder i det sprog, holdet i forvejen bruger. I praksis er det oftest TypeScript eller JavaScript, Python, Java eller C#. Vælg ét og bliv god til det. Sprogene minder om hinanden, når først du kan tænke i kode.

Test af brugerflader

• Playwright, som er blevet standardvalget i mange nye projekter
• Cypress, stadig udbredt i frontend-teams
• Selenium, som holder liv i store, ældre testpakker mange steder
• Appium, hvis der skal testes mobilapps på iOS og Android

Test uden brugerflade

• Postman og REST Assured til API-test
• pytest, JUnit, NUnit og TestNG som testrammer
• WireMock eller lignende til at simulere systemer, du ikke har adgang til
• k6, JMeter eller Gatling til belastningstest

Pipeline og drift

• Git og GitHub, GitLab eller Azure DevOps
• Jenkins, GitHub Actions eller GitLab CI til at køre tests automatisk
• Docker, så testene kører ens på din maskine og på serveren
• BrowserStack eller lignende, når der skal testes på mange browsere

Styring og rapportering

• Jira med Xray, Zephyr eller TestRail til testcases og fejl
• Allure eller pipelinens egne rapporter til at vise resultater
• Cucumber og Gherkin, hvis forretningen skal kunne læse testene

Det vigtigste værktøj
Det er testpyramiden som tankegang. Mange tests i bunden på enkelte funktioner, færre på API-niveau, ganske få tunge tests gennem hele brugerfladen. Vender du pyramiden om, får du en langsom testpakke, ingen stoler på.