Automatiseret test på tværs af +100 sites skaber tryghed og værdi

13. okt.

Kort om samarbejdet

Det Digitale Folkebibliotek (DDF) udvikler og driver digitale løsninger for stort set samtlige danske folkebiblioteker. De står bag +100 live bibliotekswebsites bl.a. Københavns Kommunes Biblioteker på bibliotek.kk.dk.

Vi har arbejdet sammen med Det Digitale Folkebiblioteker stort set siden vores opstart i 2010.

www.detdigitalefolkebibliotek.dk

*Kasper er én af flere udviklere bag test-løsningen*

Udfordringen

Ingen releases med krydsede fingre

Når man står med +100 bibliotekswebsites i drift, er det ikke nok at håbe, at det hele spiller, når der rulles en ny opdatering ud. Én lille fejl kan sende både funktionalitet og brugeroplevelse i gulvet. Hos Reload har vi gjort automatiseret test til en integreret del af vores udviklings- og driftssetup for DDF, så vi kan udrulle med ro i maven og uden at krydse fingre.

DDF’s CMS er motoren bag bibliotekswebsites i hele landet. Løsningen skal kunne opdateres løbende, ofte og trygt - uden at en enkelt ændring får utilsigtede konsekvenser for andre dele af systemet.

Med over hundrede individuelle sites er kompleksiteten høj, og manuel test ville være både tidskrævende og sårbar. Målet var derfor at bygge et setup, der fanger fejl, før de rammer rigtige brugere.

TILGANG

Robust og testdrevet leveranceproces

Vi har bygget et CI/CD-setup, der kombinerer GitHub Actions, automatiserede tests og DDF’s egen hostingplatform, som vi også selv har udviklet.

Når en udvikler ændrer koden, sker der automatisk:

Statisk kodeanalyse - finder potentielle fejl tidligt.
Unit tests (Vitest + PHPUnit) - sikrer at komponenter fungerer isoleret.
Integrationstests / end-to-end-tests (Cypress) - tester hele brugerflows og eksterne integrationer via mock-services.
Visuelle regressionstests (Chromatic) - fanger utilsigtede layoutændringer.
Performancetests (Lighthouse) - sikrer at sitet lever op til best practice i forhold til at levere en hurtig slutbrugeroplevelse.
Tilgængelighedstest (Pa11y) - finder automatisk steder hvor sitet ikke lever op til gældende tilgængelighedskrav i forhold til WCAG 2.

Alle tests kører i GitHub Actions. Hvis noget fejler, kan ændringen ikke merges. Hostingplatformen håndterer derefter automatiseret build og deployment med caching og rollback-muligheder.

Vi prioriterer testindsatsen ved at identificere ”red routes” - kritiske funktioner, der skal virke hver gang, mens mindre kritiske områder testes selektivt.

Foreløbige resultat

Det virker … og det går stærkt!

Selvom vi ikke måler på deciderede fejlprocenter, har vi opnået det vigtigste: Vi kan i dag udrulle opdateringer på tværs af over 95 bibliotekswebsites uden frygt for, at kritiske funktioner bryder sammen. Det har skabt en helt ny ro, både i udviklerteamet og hos kunden. Driften er blevet mere stabil, og de akutte “brandudrykninger” er blevet sjældnere. Samtidig er tempoet steget markant. Hvor DDF tidligere udrullede tre gange om året, ruller de nu nye releases ud mindst én gang om ugen.

“Vi er super glade for at være DDFs tætteste samarbejdspartner, og arbejder hver dag på at leve op til den store tillid der er blevet vist os”

Rasmus Luckow-Nielsen

Adm. direktør i Reload

Det "svære"

Pas på med at teste alt

At udvælge hvad vi tester automatisk er en balancegang. Tester vi alt, bliver processen for tung og dyr. Tester vi for lidt, mister vi sikkerheden. Vi har lært, at fokus på “red routes” giver den bedste kombination af værdi og effektivitet.

Derudover er en klassisk problematik er at teste funktionalitet, som er bundet sammen med eksterne services. I DDFs tilfælde har vi løst det ved at implementere mock-services, dvs. vi har lavet identiske, men simulerede services, som vi tester op imod. På den måde kan vi sikre, at testen kun fejler, hvis der er en fejl i vores ende - og ikke fordi data eller andet har ændret sig i den anden ende.