Test og kvalitetssikring
— fra første sprint
Bugs fundet i produktion koster 10x mere at rette end bugs fundet under udvikling. Vi bygger kvalitet ind fra starten — ikke som et lag der tilføjes til sidst.
Kvalitet er ikke en fase — det er en tankegang
Hos os ejer alle udviklere kvaliteten. Test er ikke noget vi laver til sidst for at tjekke om tingene virker — det er en del af hvert eneste feature fra dag ét. Det betyder at fejl opdages tidligt, koden er lettere at vedligeholde og I kan release med tillid.
QA er ikke en afdeling. Det er en del af kulturen og udviklingsprocessen. En developer der skriver tests mens de koder finder fejl i deres egne antagelser. En developer der sender kode til review opdager blinde vinkler. Et automatiseret pipeline der kører tests på hvert PR fanger regressions inden de rammer brugerne.
Resultatet er software der ikke bare virker ved levering, men som forbliver stabilt og pålideligt, når forretningen vokser og kravene ændrer sig.
Hvad vi tester og hvordan
Unit tests
Automatiserede tests af isolerede funktioner og komponenter. Hurtige, reproducerbare og giver et sikkert net til refaktorering. Vi sigter efter høj coverage på forretningslogik.
Integrationstest
Tests der verificerer at komponenter arbejder korrekt sammen — API'er, databaser og tredjepartsservices. Vi tester rigtigt, ikke mock-baseret, så vi opdager de fejl der opstår i det virkelige setup.
End-to-end tests
Automatiserede tests af kritiske brugerflows i rigtige browsere med Playwright eller Cypress. Login, betaling, checkout — de flows der aldrig må fejle, testes automatisk på hvert deploy.
Performance & load tests
Vi load-tester inden go-live, så vi ved hvad systemet kan klare. k6, JMeter og Artillery til at simulere realistisk trafik og identificere flaskehalse inden brugerne finder dem.
Code review
Systematiske reviews på alle pull requests. Ikke kun for at finde bugs — men for at sikre at koden er forståelig, vedligeholdbar og følger teamets arkitekturmønstre.
Manuel QA & device test
Kritiske flows testes på rigtige enheder og browsere. Automatisering fanger mange fejl — men ikke alle. Manuelle tests finder de edge cases og UX-problemer der kun ses med menneskelige øjne.
Hvornår tester vi?
Under udvikling
Unit tests skrives sideløbende med koden. Statisk analyse, type-checking og linting kører lokalt og i CI. Peer review på alle PRs som standard.
I CI/CD-pipeline
Alle tests kører automatisk på hvert PR og hvert merge til main. Et failing test blokerer deployment. Ingen kode når produktion uden at passere pipelinen.
Inden go-live
Fuld E2E-gennemgang, load test og manuel QA på staging-miljø. Vi tester på de browsere og enheder der svarer til jeres brugerprofil — ikke kun Chrome på MacBook.
Spørgsmål om QA & test
Vi starter med at kortlægge de kritiske flows og risikofyldte dele af systemet. Det er som regel bedre at have gode tests på 20% af kodebasen end dårlige tests på 100%. Vi hjælper med at etablere en testkultur og -infrastruktur, og tilføjer tests gradvist der, hvor gevinsten er størst.
Coverage-procenten er et dårligt mål i sig selv. 100% coverage kan give falsk tryghed hvis tests ikke tester de vigtige cases. Vi fokuserer på meningsfuld coverage af forretningslogik, kritiske flows og de dele af kodebasen der ændres hyppigt — ikke på et vilkårligt tal.
Kortfristet: lidt. Langsigtet: nej — det er det modsatte. Et system med god testdækning er langt hurtigere at ændre i, fordi du ved med det samme om en ændring bryder noget. Uden tests bruges tid på manuel verifikation, regression-debugging og fejlretning i produktion — det er langt dyrere end at skrive tests undervejs.