Automatiserede tests: hvorfor de sparer dig penge (også i små projekter)

Automatiserede tests er små programmer der tjekker at de vigtigste dele af dit system stadig virker, hver gang koden bliver ændret. De sparer dig penge på to måder: færre fejl når ud til dine kunder, og hver ændring bliver billigere fordi ingen skal klikke hele systemet igennem i hånden før en udgivelse. Det gælder også i små projekter, så længe testene dækker det der tjener penge eller kan gøre skade.

Jeg er freelanceudvikler og bygger og vedligeholder webapps, mest i Laravel, hvor jeg typisk skriver testene med Pest. Herunder får du regnestykket som jeg ser det, hvad du bør teste først, og hvornår tests ikke er pengene værd.

Den korte version

Tænk på automatiserede tests som en forsikring der også gør dig hurtigere. Du betaler en præmie når en funktion bygges, og til gengæld bliver hver ændring bagefter billigere og mindre risikabel.

Beslutningsreglen er enkel: skal systemet leve længere end et par måneder og ændres undervejs, betaler tests til de vigtigste arbejdsgange sig. Skal det smides væk efter en demo, gør de ikke. Tests er én del af et samlet udviklingsforløb, og hvor de passer ind fra idé til drift, kan du se i guiden til hvordan et softwareprojekt foregår.

Hvad en automatiseret test er, forklaret uden kode

En automatiseret test er et lille stykke kode der afprøver et konkret scenarie og svarer ja eller nej. "En kunde kan logge ind med den rigtige adgangskode, men ikke med den forkerte." "En ordre på 3 varer med rabatkode giver den rigtige pris inklusive moms." "En medarbejder kan ikke se en anden afdelings data." Testene kører automatisk hver gang en udvikler laver en ændring, og fejler én af dem, kommer ændringen ikke i drift.

Der er tre slags som du vil høre om:

• Enhedstests (unit tests) tjekker én lille del isoleret, fx den funktion der beregner fragt. De er hurtige, men siger ikke så meget om helheden.
• Feature-tests (også kaldet integrationstests) tjekker et helt forløb: en forespørgsel kommer ind, data gemmes i databasen, og der sendes en mail. Laravels egen dokumentation anbefaler at de fleste tests er af den slags fordi de giver mest sikkerhed for at systemet virker som helhed (Laravels dokumentation om test).
• Browsertests (end-to-end-tests) styrer en rigtig browser og klikker sig igennem som en bruger. De fanger fejl i samspillet, men er langsommere og mere skrøbelige, så dem bruger jeg sparsomt til de allervigtigste forløb.

I Laravel følger testværktøjerne Pest og PHPUnit med fra start, og frameworket kan erstatte mails, køer og kald til eksterne systemer med attrapper under testen. Testene kan derfor afprøve et helt købsforløb uden at kontakte betalingsudbyderen eller sende en mail til en rigtig kunde. Det er en af grundene til at Laravel er mit standardvalg, som jeg forklarer i mine 13 grunde til at vælge Laravel.

Regnestykket: hvad tests koster, og hvad de sparer

Det mest brugbare studie jeg kender om regnestykket, kommer fra Microsoft og IBM. Forskerne fulgte fire udviklingsteams der skrev testene før koden (testdrevet udvikling), og sammenlignede med lignende projekter uden. Fejltætheden før udgivelse (antal fejl i forhold til kodens størrelse) faldt med 40-90 %, mens teamene selv vurderede at den første udvikling tog 15-35 % længere tid (Nagappan m.fl., Empirical Software Engineering, 2008). Det er fire teams i store virksomheder og ikke en naturlov, men retningen er tydelig: du betaler lidt mere for at bygge og får markant færre fejl.

Den anden halvdel af regnestykket er hastighed. Martin Fowler, en kendt forfatter inden for softwaredesign, påpeger at udviklere mærker dårlig intern kvalitet som en bremse allerede efter få uger (Fowler: Is High Quality Software Worth the Cost?). Kode som ingen tør ændre fordi intet sikkerhedsnet fanger fejlene, er præcis den slags bremse.

Et tænkt regneeksempel

Forestil dig et lille bookingsystem med 8 arbejdsgange der ikke må gå i stykker: oprettelse, login, booking, aflysning, betaling, refundering, bekræftelsesmail og administratorens oversigt. Jeg regner med 1.000 kr. i timen fordi det er et rundt tal, ikke fordi det er en bestemt pris:

• Uden tests skal nogen klikke de 8 arbejdsgange igennem før hver udgivelse. Gøres det ordentligt, tager det let 45 minutter. Med to udgivelser om måneden er det 18 timer om året, altså 18.000 kr., og det er kedeligt arbejde der i praksis ofte bliver sprunget over.
• Tests til de 8 arbejdsgange tager måske 2-3 dages arbejde, groft sagt 15.000-24.000 kr., afhængigt af hvor komplicerede betalingen og reglerne er. Bagefter kører de ved hver ændring uden ekstra timer.
• Én fejl i betalingen der når ud til kunderne, kan let koste mere end testene: fejlsøgning under pres, refunderinger, support, tabte bookinger og en akut rettelse uden for normal arbejdstid.

Alene den manuelle gentest svarer altså cirka til prisen på testene i løbet af det første år. Og så har jeg hverken regnet en eneste undgået fejl med eller den tid der spares når udvikleren tør rydde op og ændre i koden. Sæt dine egne tal ind, men regnestykket ender sjældent anderledes for et system der skal leve i flere år.

Hvad du skal teste først, også i et lille projekt

Antallet af tests betyder mindre end hvor de sidder. Min prioritering er den samme uanset projektets størrelse, fra vigtigst til mindst vigtig:

1. Penge. Priser, rabatter, moms, abonnementer, fakturaer og betalinger. En regnefejl her rammer omsætningen direkte og opdages tit sent.
2. Adgang. Login, roller og hvem der må se hvad. En fejl her kan betyde at en kunde ser en anden kundes data, og så er der også tale om et muligt brud på persondatasikkerheden efter GDPR.
3. Kerneprocessen. Den ene arbejdsgang systemet findes for: bookingen, ordren eller ansøgningen. Virker den ikke, er resten ligegyldigt.
4. Integrationer. Kald til økonomisystem, betalingsudbyder eller CRM. Testene kører mod attrapper så de er hurtige og stabile, og overvågning i drift holder øje med den rigtige forbindelse.
5. Fejl der er sket før. Min tommelfingerregel er at hver rettet fejl får en test der fanger netop den fejl. Så kommer den ikke igen, og over tid dækker testene de steder hvor systemet faktisk er skrøbeligt.

Det jeg typisk ikke skriver tests til: layout og farver, tekster der ændres tit, simple sider uden logik og selve frameworkets funktioner, som allerede er testet af dem der laver det. Den tid er bedre brugt på punkt 1-3.

Og et ord om testdækning (code coverage), altså hvor stor en del af koden testene kører igennem. Det er et nyttigt termometer, men et dårligt mål. 100 % dækning kan opnås med tests der ikke tjekker noget vigtigt, og 60 % kan være rigeligt hvis det er de rigtige 60 %. Spørg hellere hvilke af dine vigtigste arbejdsgange der er dækket. Det spørgsmål indgår også i mine 12 tegn på en sund eller syg kodebase.

Sådan får et eksisterende system tests i 5 trin

Har dit system ingen tests i dag, er det ikke en grund til at starte forfra. Sådan griber jeg det an når jeg overtager kode uden sikkerhedsnet:

1. Find de 5-10 arbejdsgange der ikke må gå i stykker. Det er en forretningssamtale, ikke en teknisk, og du kender svaret bedre end udvikleren.
2. Skriv brede tests først. Feature-tests der afprøver hele forløbet udefra, fanger mest og kræver ikke at koden er pæn indeni. De låser fast hvad systemet gør i dag, også de skæve hjørner, så du opdager det hvis en ændring rykker ved det.
3. Sæt testene til at køre automatisk ved hver ændring, fx med GitHub Actions. En test der kun kører når nogen husker det, er næsten ingen test.
4. Hold testene hurtige og stabile. DORA, et forskningsprogram om softwarelevering, anbefaler at udviklere får svar fra testene på under ti minutter, og at tests der fejler tilfældigt, bliver rettet i stedet for at blive ignoreret (DORA om testautomatisering).
5. Udvid løbende. Hver ny funktion og hver rettet fejl får tests med. Så vokser dækningen der hvor systemet faktisk ændres, uden et stort separat projekt.

Når de vigtigste arbejdsgange er dækket, bliver to ting pludselig billigere: oprydning i gammel kode og opdatering af framework og pakker. Begge dele er risikable uden tests fordi ingen kan se hvad der går i stykker. Det hænger tæt sammen med teknisk gæld og hvad det koster at vente og med hvorfor du ikke bør udskyde opdatering af framework og pakker.

Hvornår tests ikke er pengene værd

Tests er en investering, og ikke alle investeringer er gode. Jeg ville springe dem over eller holde dem på et minimum når:

• Det er en prototype der skal vise en idé til investorer eller brugere og derefter smides væk. Så er fart vigtigere. Men vær ærlig over for dig selv: prototyper har det med at ende i drift.
• Det er en simpel hjemmeside uden logik, hvor det værste der kan ske, er en forkert tekst. Her er et hurtigt tjek efter udgivelse rigeligt.
• Systemet skal udfases inden for få måneder og ændres ikke mere.
• Testene tjekker detaljer i stedet for adfærd. Tests der går i stykker hver gang en knap flyttes, koster mere end de sparer, og så er det testene der skal skrives om.

Automatiske tests erstatter heller ikke at du selv prøver nye funktioner af i et testmiljø før de kommer ud til brugerne. Testene tjekker det man ved skal virke. Et menneske opdager det ingen havde tænkt på.

Hvornår du ikke skal hyre en som mig til det

Jeg tilbyder vedligehold og videreudvikling af eksisterende systemer, men du skal ikke hyre mig til at skrive tests hvis:

• du har en intern udvikler der kender systemet. Giv hellere vedkommende tid til at skrive tests end at hente en ny ind som først skal lære koden at kende.
• systemet er bygget i en teknologi jeg ikke arbejder med. Jeg arbejder med Laravel, PHP og JavaScript (React og Next.js).
• det er et færdigt standardsystem du betaler abonnement på. Så er testene leverandørens ansvar.

Næste skridt

Start med at finde ud af hvor dit system står. Tag spørgsmålene herunder med til din udvikler eller dit bureau. Svarene fortæller dig om du har et sikkerhedsnet, eller om du betaler for fejlene i stedet.

Har du et system uden tests, eller vil du have en vurdering af dem du har, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende systemer. Du får direkte kontakt med mig der skriver koden, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Kan jeg selv se om mit system har automatiske tests?+

Ja, og du behøver ikke kunne læse kode. Bed din udvikler om at køre testene mens du ser på, eller om at sende et skærmbillede af den seneste kørsel. Ligger koden på GitHub eller lignende, kan du ofte se et grønt flueben eller et rødt kryds ved hver ændring. Det viser at testene kører automatisk. Findes der hverken en testmappe eller en automatisk kørsel, har du dit svar.

Skal tests stå i tilbuddet fra udvikleren?+

Ja. Spørg hvilke arbejdsgange der bliver dækket af tests, og om de kører automatisk ved hver ændring. Står tests ikke nævnt, så spørg direkte. Sammenligner du to tilbud, kan det billigste være billigere netop fordi testene er sparet væk, og den regning får du senere i form af fejl og dyrere ændringer. Bed om tests som en fast del af leverancen og ikke som et tilvalg der streges når budgettet strammer.

Bliver tests mindre vigtige når koden skrives med AI?+

Nej, snarere vigtigere. AI-værktøjer skriver meget kode hurtigt, men de kender ikke dine forretningsregler og kan ødelægge noget der virkede i går uden at sige det. Tests er den beskrivelse af hvad systemet skal kunne, som AI-genereret kode bliver tjekket op imod. Apps bygget hurtigt med værktøjer som Lovable eller Bolt kan sagtens mangle tests helt, så det er et af de første steder jeg kigger.

Hvad koster det at tilføje tests til et eksisterende system?+

En første runde der dækker de 5-10 vigtigste arbejdsgange, er typisk et spørgsmål om dage, ikke måneder. Prisen afhænger af systemets størrelse og hvor rodet koden er, så tag mit skøn som et groft udgangspunkt. Bed om en fast pris på netop den runde. Derefter kan resten af dækningen komme løbende med de opgaver der alligevel laves, så det ikke bliver et stort projekt for sig.