Man kan ikke teste kvalitet ind

2. april 2020

Kender du den fornemmelse, at man kan have lyst til at stille sig på en stol med en megafon og råbe noget ud I lokalte for at få folk til at forstå?

Sådan har jeg det lidt med sætningen ”Man kan ikke teste kvalitet ind”!

Nu har jeg arbejdet med test i næsten 25 år, i både modne og umodne organisationer – i både traditionel udvikling og agile projekter, og stadig støder jeg på oplevelser som denne:

”Sidste relese havde vi mange fejl produktionen, vi har lavet en analyse for at finde ud af hvorfor vi ikke fandt det i test – og nu har vi en plan til hvordan vi kan lave bedre test. Vi skal bare lige lave det her om i testprocessen, danne det her team, udvide med den her testaktivitet – så skal det nok blive bedre.”

Når jeg oplever denne situation så er der noget der falder mig for brystet (udover en barnlig trang til at ruske nogen 😊); Hvorfor er jeres analyse kun fokuseret på hvorfor de ikke blev fundet i test? Hvorfor kigger i ikke også på hvordan det kan være de blev INTRODUCERET i stedet for at putte alle kræfter i at finde ud af hvorfor de ikke blev IDENTIFICERET? Jeg kunne komme med forslag som:

  • Har i styr på hvad i egentlig skal lave? Forstår i hvad det er for et behov jeres brugere har? (start with why)
  • Har i fyldt for meget i jeres sprint eller release? Så udviklingsteamet ikke kunne nå i mål? Ignorerede i det da de råbte til jer – vi kan ikke lykkes med det her til den aftalte tid? Sagde i bare ”jamen det skal i”?
  • Presser i jeres udviklingsteams så meget at de ikke kan nå at gøre deres arbejde ordentligt? Så der ikke er tid til at lave test driven development? Så de dropper unit testen? Så testerne ikke kan følge med?
  • Som resultat af de tre forrige; har i så mange fejl i løbet af sprintene at i ikke kan følge med i at rette dem? Måske fordi i ikke laver plads til det i sprintet?
  • Har i styr på jeres tekniske gæld? Tager i tid til rent faktisk at rydde op?
  • Har i ikke ”råd” til at få styr på en solid strategi til automatisering men i har råd til at køre lange regressionstests i test faser i i stedet for at regressionsteste løbende?
  • Smider i funktionalitet ind i leverancen helt hen til sidste øjeblik? Kommer der stadig ny funktionalitet ind i byggene mens de kører den afsluttende test?
  • Har i rammerne til at teste end-to-end så det rent faktisk er realistisk?


Når alt kommer til alt så er er tre parametre du kan få din release efter: hurtigt, billigt og god kvalitet. Men du kan altså kun få to af dem! Hvis det er hurtigt og billigt er det sandsyndligvis ikke i god kvalitet, og hvis det er god kvalitet hurtigt så er det garanteret ikke billigt.


Lige om lidt kommer den næste bog med den næste spændende løsning; Agile, CI, CD, Devops, SAFe, LESS, Scrum at scale, eller noget helt syvende. Det næste buzzword vi alle løber efter fordi det er det nye sort – men hvad nu med at starte med det helt basale som gælder universalt uanset hvilken bibel du hænger ved, uanset om det er SAFe bogen, the Phoenix Project, Continuous testing with Devops eller en helt fjerde bog…

  • Der skal være tæt kontakt mellem forretning og udvikling for at forstå HVORFOR vi bygger det vi bygger. PO er en del af teamets dagligdag, ikke en sjælden gæst et par gange hver anden uge.
  • Kvalitet skal bygges ind. Det vil sige at udover at vi skal have styr på hvad det er vi skal bygge (og hvorfor), så skal der vær plads til at vi kan bygge det ordentligt – at vi kan lave god kode på et solidt fundament, støttet af en solid unit test.
  • At vi har vores continiuous integration der sikrer at vi tester løbende, så vi ikke kompromiterer det vi allerede har bygget.
  • At man skal lave plads i sin plan til at rette fejl, til at refactorere, til at forbedre.
  • At testfokus er med fra start til slut, et er at have det rigtige automatiseirngsframework, og de dygtige automatiseringsspecialister – men hvis de ikke kan designe den effektive test så er det bare skod test stadigvæk…. Den kører bare hurtigere.
  • Benhård command and control stemmer dårligt overens med en agil tankegang og tilgang til software udvikling. Det første ord du bør lære er TRUST!
  • Kvalitet er mere end fokus på funktionalitet – der er så mange andre kvalitetsattributter du bør have fokus på.
  • Kvalitet er så meget mere end test! lad være med at sætte lighedstegn mellem test og QA
  • God test KOSTER! Et ordentligt testmiljø, styr på testdata, et godt og vedligeholdbart automatiseringsframework, det rigtige værktøj til at styre din test – ikke regneark og worddokumenter, og sidst men ALLERMEST; de rigtige mennekser til at udføre det – med det rigtige mindset og med den respekt og anerkendelse de bør have i organisationen.

Så en lille bøn fra mig; lad nu være med at blive ved med hovsaløsninger i slutningen af projektet for at redde kvaliteten – i er nødt til at tænke kvalitet fra dag et, og der er SÅ MEGET mere i kvalitet end test!

Kontakt os

Hurtige links

Denne hjemmeside benytter cookies. Ved at klikke på 'Acceptér' godkender du vores brug af cookies.

Godkend