Here’s why – and how contract testing fixes it.

You’ve been there. Two teams. Two services. Both green in CI. Both deployed on Friday. Monday morning: production is down. The order service can’t read product prices. Turns out the product team renamed a JSON field over the weekend. Nobody told the order team. Nobody could tell them – there was no mechanism to.

This isn’t a communication failure. It’s an architecture failure. And it has a name: integration drift.

The invisible gap in your test pyramid
Most engineering teams test well at the unit level. They mock dependencies, write fast tests, and get high coverage. The problem is that mocks lie.

When the order service mocks the product service response, it uses the field price. When the product team renames that field to unit_price in their codebase, your mock doesn’t know. Your unit tests don’t know. Your entire test suite doesn’t know – until a real request hits a real endpoint in production.

This is the gap contract testing fills.

What contract testing actually is
Contract testing is a technique where two services agree on a normal, version-controlled description of their interaction – the contract – and both independently verify they honor it.

The contract captures one specific thing: what the consumer (caller) actually needs from the provider (API). Not everything the API returns. Just the fields the consumer uses. There are two sides to every contract:

The consumer defines it. The order service writes a test that says: “When I call GET/products/42, I expect a 200 response with an id (number), a name (string), and a price (number).”
That expectation is saved as a JSON contract file.

The provider verifies it. The product service fetches that contract file and runs its real code against it. If the response doesn’t match – wrong field name, wrong type, missing field – the test fails. Before deployment. Before anything reaches production.
The most widely used tool for this is Pact, which supports JavaScript, Java, Python, Go, .NET, and more.

Why this matters more than you think

It decouples teams. The order team doesn’t need to run the product service locally to test their integration. They test against the mock, generate a contract, and trust the pipeline to verify it. Both teams deploy independently, which is the whole point of microservices.

It makes breaking changes visible immediately. The moment a provider change would break a consumer, the provider’s own CI pipeline fails. The developer who made the change sees it. They fix it before it becomes anyone else’s problem.

It creates a living document of your API surface. The Pact Broker – the shared registry where contracts are stored – becomes a map of which services depend on what. Want to know who calls your /products/:id endpoint and what fields they use? The broker tells you instantly.

It shifts the cost curve. A production incident costs hours of engineer time, customer-facing downtime, and trust. A failed contract test costs two minutes of reading a diff.

What the industry has learned
Three organisations tell the story well – and they come at it from very different angles.

Spotify arrived at contract testing through a fundamental rethink of how testing should work in a microservices world. Their engineering team introduced the “Testing Honeycomb” – an inversion of the classic test pyramid that places integration tests, not unit tests, at the centre of gravity. Their insight: in a microservices architecture, the most complex and failure-prone part of the system isn’t inside any individual service. It’s at the boundaries where services talk to each other. Unit tests, by design, mock those boundaries away. Spotify explicitly named consumer-driven contract testing (Pact) as the natural next step to give teams genuine confidence that they weren’t accidentally breaking those contracts with every release.

Delivery Hero – the global food delivery group behind foodpanda – has the hard numbers. After analysing production incidents across 2023 and 2024, their engineering team found that 5% of all incidents were caused by contract violations between microservices: teams changing their API responses without any mechanism to alert the services consuming them. In practical terms, that translated to approximately 60,000 lost customer orders. After adopting PactFlow contract testing, they reduced production incidents attributable to integration failures by 14%.

Boost Insurance, a New York-based insurtech platform, tells a similar story at smaller scale. Running 15+ microservices, they were experiencing one service outage per month and roughly twelve production issues per quarter. After adopting Pact, outages dropped to virtually zero and production issues fell to two per quarter. Their engineering manager said he would happily eliminate end-to-end testing entirely in favour of contracts.Three different industries. Three different scales. The same underlying problem – and the same category of fix.

The workflow in practice

Here’s the shape of it, end to end:

1. Consumer writes an interaction test
The test defines what the consumer sends and what it expects back. Pact spins up a local mock server, runs the test against it, and saves the contract as a JSON file.

2. The contract is published to a broker
After the consumer’s tests pass in CI, the contract file is pushed to a central Pact Broker (or PactFlow, the hosted version). This is the handshake point between the two pipelines.

3. The provider fetches and verifies
When the provider’s CI runs, it fetches all contracts from the broker and replays each recorded request against the real running service. If any response doesn’t match the contract, the build fails and verification is published as failed.

4. can-i-deploy gates every deployment
Before either service deploys to production, a single command checks the broker: “Is the version of this service compatible with everything it depends on in production right now?” If the answer is no, deployment is blocked. That’s it. That’s the safety net.

Når Scrum Masteren bliver reduceret til mødefacilitator, mister virksomhederne forståelsen for den værdi, rollen egentlig skaber. 

Hvad laver Scrum Masteren efter Daily? 

Daily er slut. Mødet blev holdt inden for de 15 minutter, og alle har fortalt, hvad de arbejder på. Teamet går tilbage til deres opgaver. 

Men blev der truffet nogen beslutninger? Blev planen justeret? Og blev teamet klogere på, hvordan det når sit Sprint Goal? 

Hvis svaret er uklart, er det måske ikke så mærkeligt, at mange virksomheder har svært ved at se værdien af Scrum Masteren. 

Jeg møder virksomheder, hvor rollen primært forbindes med at indkalde til og facilitere møder. Alle events ligger i kalenderen; frameworket er implementeret – og så er vi Agile. Eller er vi? 

Når rollen reduceres til møder, kan Scrum Masteren let blive opfattet som en overflødig ressource med en uklar værdi. Derfor bør vi spørge os selv, om virksomhederne har misforstået rollen – eller om vi som ScrumMasters selv har været med til at udvande den. 

Facilitering er et middel – ikke målet 

God facilitering er vigtig. Den kan skabe en dialog, hvor alle tør sige deres mening, reflekterer sammen og træffer beslutninger. 

Men et velafholdt møde skaber ikke automatisk værdi. 

Et retrospektiv kan både være energisk og professionelt faciliteret. Alle bidrager med post-its og teamet afslutter med tre forbedringspunkter. Men hvis punkterne aldrig bliver fulgt op, og de samme problemer dukker op igen måneden efter, hvilken værdi skabte mødet så? 

Målet er ikke at afholde Scrum-events. Målet er den læring, forbedring og forandring, de fører til. 

Rollen er større end møderne 

Når jeg læser Scrum Guiden, beskrives Scrum Masteren som meget mere end en facilitator. Rollen omfatter blandt andet ansvar for Scrum Teamets effektivitet, coaching i selvledelse, fokus på værdifulde leverancer, fjernelse af forhindringer og støtte til både Product Owneren og organisationen. 

Scrum Guiden beskriver altså, i mine øjne, en leder og coach, der arbejder med mennesker, teams og organisatoriske rammer. 

En certificering kan give et vigtigt teoretisk fundament, men den kan ikke stå alene. Rollen kræver også kompetencer inden for coaching, teamdynamik, konflikthåndtering, forandringsledelse og organisatorisk forståelse. 

Værdien skabes mellem møderne 

Scrum Masterens arbejde er ofte mest synligt under møderne, men den reelle værdi skabes imellem møderne. 

Det er her, at Scrum Masteren observerer teamets samarbejde og fremdrift: Hvor går arbejdet i stå? Tager teamet et fælles ansvar? Er prioriteringerne tydelige? Hjælper processerne teamet – eller hæmmer de? Og bliver alle perspektiver hørt? 

Hvis de samme to personer altid finder løsningerne, mens resten af teamet bliver stille, skal Scrum Masteren kunne opdage mønsteret og hjælpe teamet med at ændre det. 

Nogle gange har teamet brug for konkrete værktøjer og tydelig guidning. Andre gange har det brug for sparring eller en coachende tilgang, hvor Scrum Masteren stiller spørgsmål og hjælper teamet med selv at finde næste skridt. 

Den dygtige Scrum Master følger derfor ikke bare en fast liste over aktiviteter. Tilgangen vælges ud fra, hvor teamet befinder sig, og hvad det har brug for lige nu. 

Vi skal gøre værdien synlig 

Antallet af afholdte events er nemt at tælle, men det fortæller ikke, hvilken forskel Scrum Masteren har gjort. 

Værdien kan i stedet vise sig gennem større ejerskab, bedre samarbejde, tydeligere prioriteringer og færre opgaver, der går i stå. Det betyder ikke, at udviklingen ikke kan følges. Men vi skal tage udgangspunkt i det problem, vi forsøger at løse: 

• Hvad oplever teamet som problemet? 

• Hvilken ændring vil vi afprøve? 

• Hvad forventer vi bliver anderledes? 

• Hvornår følger vi op? 

• Hvad lærte vi? 

Scrum Masterens værdi bliver ikke synlig gennem antallet af møder, men gennem de forbedringer, som teamet og organisationen oplever. Især læring omkring de fejl vi laver, er dem, teamet lærer mest af.  

Ansvaret ligger også hos os 

Virksomhedernes syn på Scrum Masteren ændrer sig ikke, fordi vi forklarer rollen endnu en gang. Det ændrer sig, når vi skaber forbedringer, som teamet, Product Owneren og organisationen kan mærke. 

Facilitering er en del af rollen, men ikke hele rollen. Scrum Masteren skal også kunne observere, guide, sparre, coache og udfordre – og løbende udvikle sine egne kompetencer. 

Scrum Master-rollen er ikke værdiløs. Men forståelsen og udførelsen af den er nogle steder blevet så smal, at værdien er blevet svær at få øje på. 

Hvis vi vil ændre synet på Scrum Masteren, må vi derfor begynde med os selv: Vi skal udfylde hele rollen og blive bedre til at gøre vores effekt synlig. 

Den 29. september 2026 starter vi et nyt hold på vores skræddersyede quality coach uddannelse.

Det er blandet andet chefrådgiver Gitte Ottosen, der underviser på uddannelsen, og her dykker hun ned i den konkrete værdi, uddannelsen har for både medarbejder, team og virksomhed.

I mange organisationer er kvalitet ikke længere noget, der ligger hos én person eller ét team. Moderne organisationer arbejder i stigende grad med agile metoder og DevOps, hvor ansvaret for kvalitet er fordelt på tværs af hele teamet. Det ændrer også rollen for den klassiske tester.

Her opstår behovet for en ny type kvalitetsprofessionel: Quality Coach.

Fra tester til Quality Coach

Traditionelt har testere været eksperter i at finde fejl og skabe indsigt i produktets kvalitet. Men i dag forventes teams i langt højere grad selv at kunne analysere, designe, udvikle, teste og drifte løsninger.

Det betyder ikke, at testkompetencer er blevet mindre vigtige. Tværtimod.

Der er fortsat brug for personer med stærke kvalitetskompetencer, men deres vigtigste opgave er ikke nødvendigvis selv at udføre test. Deres vigtigste opgave er at hjælpe andre med at tænke kvalitet.

En Quality Coach arbejder derfor med at:

• skabe forståelse for kvalitet i hele organisationen
• facilitere dialoger om kvalitet og risici
• styrke teamets kompetencer inden for test og kvalitet
• hjælpe med at indbygge kvalitet tidligt i udviklingsprocessen
• skabe fælles sprog og fælles forståelse på tværs af forretning og IT
• understøtte læring, refleksion og kontinuerlig forbedring

Hvor den traditionelle tester ofte spørger: “Virker løsningen?”

spørger Quality Coachen: “Hvordan sikrer vi som organisation, at vi bygger kvalitet ind fra starten?”

Kvalitet handler om mennesker

Noget af det mest interessante ved Quality Coach-rollen er, at den flytter fokus fra værktøjer og processer til mennesker.

Succesfuld coaching bygger på:

• tillid
• aktiv lytning
• nærvær
• nysgerrighed
• empati
• evnen til at facilitere refleksion

En Quality Coach skal kunne forstå, at forskellige mennesker oplever verden forskelligt. Det kræver evnen til at lytte uden straks at komme med løsninger og i stedet hjælpe andre med selv at finde vejen frem. Dette perspektiv fylder meget i seminaret, hvor coaching beskrives som en disciplin, der kræver både faglig tyngde og stærke menneskelige kompetencer.

En rolle med mange facetter

Quality Coaching bygger på et bredt kompetencefundament.

Rollen omfatter blandt andet:

• Coaching
• Mentoring
• Facilitering
• Kommunikation
• Vidensdeling
• Forandringsledelse
• Systemtænkning
• Kvalitetsrådgivning
• Stakeholder management

Det betyder, at Quality Coachen ofte fungerer som bindeled mellem ledelse, forretning, udviklere, testere og andre interessenter.

Samtidig fungerer rollen som organisationens ambassadør for kvalitet. Ikke ved at kontrollere andre, men ved at skabe forståelse, engagement og ejerskab.

Hvorfor er rollen vigtig netop nu?

TMAP beskriver moderne kvalitetsarbejde som et fælles ansvar i tværfaglige teams, hvor kvalitet skal bygges ind i både produkter, processer og mennesker frem for at blive kontrolleret til sidst i forløbet.

I DevOps- og agile organisationer bliver dette særligt vigtigt, fordi kvalitet ikke længere kan være afhængig af én specialistfunktion. Teams skal kunne træffe gode kvalitetsbeslutninger hver eneste dag.

Her bliver Quality Coachen katalysatoren, der hjælper organisationen med at udvikle de nødvendige kompetencer og vaner.

Hvad får deltageren ud af en Quality Coach-uddannelse?

For den enkelte deltager er uddannelsen en mulighed for at udvikle sig fra specialist til rådgiver.

Deltagerne opnår blandt andet:

Stærkere gennemslagskraft
Evnen til at påvirke beslutninger uden formelt ledelsesansvar.

Bedre kommunikation
Værktøjer til at skabe dialog om kvalitet med både udviklere, ledere og forretning.

Coachende kompetencer
Metoder til at støtte læring og udvikling hos teams og kolleger.

Faciliteringsværktøjer
Teknikker til workshops, retrospektiver og kvalitetsdialoger.

Strategisk forståelse af kvalitet
Evnen til at koble kvalitet sammen med forretningsværdi, risikostyring og organisatorisk udvikling.

Kort sagt bliver deltageren i stand til at skabe effekt gennem andre mennesker frem for alene gennem egen specialistviden.

Hvad får virksomheden ud af at sende medarbejdere på uddannelsen?

Værdien stopper ikke hos kursisten.

Organisationen får medarbejdere, der kan hjælpe med at skabe varige forbedringer i kvalitetskulturen.

Det betyder blandt andet:

Stærkere kvalitetskultur
Kvalitet bliver et fælles ansvar frem for en aktivitet, der ligger hos enkelte personer.

Mere modne teams
Teams lærer at arbejde mere selvstændigt med kvalitet, test og risikostyring.

Bedre samarbejde mellem forretning og IT
Quality Coachen hjælper med at skabe fælles forståelse og fælles mål.

Tidligere fokus på kvalitet
Problemer opdages tidligere, hvor de er billigere og lettere at løse.

Øget organisatorisk læring
Viden og erfaring forankres i organisationen frem for hos enkeltpersoner.

Resultatet er ikke blot bedre test. Resultatet er bedre beslutninger, stærkere teams og højere sandsynlighed for at levere den ønskede forretningsværdi.

Fremtidens kvalitetsprofessionelle

Rollen som Quality Coach er et naturligt næste skridt i udviklingen af kvalitet som disciplin.

Hvor test tidligere handlede om at finde fejl, handler moderne kvalitetsarbejde i højere grad om at skabe de rette betingelser for kvalitet.

Det kræver faglighed. Det kræver menneskelig indsigt. Og det kræver evnen til at skabe forandring gennem andre.

Det er netop her, Quality Coachen gør forskellen.

“I pity the fool who doesn’t put quality dead center”

Sådan kunne Mr. T have sagt, hvis han havde været DevOps-ekspert i stedet for 80’er actionhelt. Men så ville verden have været foruden B. A. Baracus og A-teamet, og det ville også have været en skam.

Nuvel, vi må hellere dykke ned i det, som det egentlig drejer sig om. Risikobaseret teststrategi i CI/CD.

Og hvad er risikoen, spørger du nok? Ja, det må vi finde ud af i fællesskab.

Hvad er kvalitetsrisiko?

Lad os starte med det grundlæggende.

Kvalitetsrisiko er en specifik chance for, at produktet fejler, kombineret med konsekvensen hvis det sker. To faktorer bestemmer chancen for fejl: Sandsynligheden for at fejlen overhovedet findes i produktet, og hvor tit den pågældende del af produktet bliver brugt. Konsekvensen handler om, hvad der sker i den virkelige verden når det går galt. For brugerne og måske for virksomhedens omdømme.

Forestil dig engang, at et finansielt system er bygget med en microservices-arkitektur. En bruger går i gang med en valutakonvertering i realtid. Undervejs crasher systemet, fordi der ikke er styr på afhængighederne mellem de services der kræves for at gennemføre konverteringen. Det er systemkompleksitet der påvirker chancen for fejl og en utilfreds bruger der ikke kan gennemføre sin transaktion, der illustrerer konsekvensen.

En betalingsbekræftelse som alle kunder bruger flere gange dagligt bærer en fundamental anden risiko end et administrativt skærmbillede med en kosmetisk fejl. Din testindsats bør afspejle den forskel. Det er lige præcis det risikobaseret test handler om.

Og det er ikke kun et spørgsmål om prioritering. Det handler om overlevelse. I DevOps er det teamet selv der mærker konsekvensen, når noget går galt i produktion. “You build it, you run it” er ikke bare et catchy motto, men en direkte incitamentstruktur der tvinger kvalitet ind i centrum af arbejdet. Når du er den person der bliver vækket klokken tre om natten fordi din kode fejler i produktion, tænker du anderledes over risiko næste gang du planlægger et sprint.

Og lige inden du tænker “funktionalitet, det har vi da styr på”, så stop lige et sekund. En user story handler typisk om hvad en feature skal gøre, men de relevante kvalitetskarakteristikker rækker langt videre end det. Sikkerhed, performance, vedligehold, brugervenlighed, pålidelighed. En betalingsfeature kan bære høj funktionel risiko og en ligeså høj sikkerhedsrisiko på samme tid. Et rapporteringsdashboard kan have lav sikkerhedsrisiko men til gengæld høj risiko i brugervenligheden. At identificere hvilke kvalitetskarakteristikker der rent faktisk er relevante for hvert item, er en forudsætning for at bygge en teststrategi der er noget værd.

Hele teamet med: Risk poker

Lad os tale om den mest oversete faldgrube i risikovurdering: At kun én person laver den.

En udvikler ser teknisk kompleksitet. En product owner ser forretningsmæssig konsekvens. En tester ser historiske fejlmønstre. En risikoanalyse der kun fanger ét af disse perspektiver er ufuldstændig og en ufuldstændig risikoanalyse giver en ufuldstændig teststrategi. Så lad os gøre det ordentligt.

Risk poker er svaret. Det er en udvidelse af planning poker som de fleste Scrum- og DevOps-teams allerede kender og bruger. Og ligesom planning poker afslører forskelle i, hvordan teammedlemmer forstår størrelsen af en user story, afslører risk poker forskelle i, hvordan de forstår dens risiko. De forskelle er ikke noget man skal komme hurtigt videre fra. De er faktisk den mest værdifulde del af hele sessionen.

Sådan fungerer det i praksis. For hver user story i det kommende sprint estimerer hvert teammedlem selvstændigt to ting: Chancen for fejl og konsekvensen af fejl. Det gøres med kort med værdierne 1 (lav), 2 (mellem) og 3 (høj). Kortene vendes samtidigt og så begynder den rigtige samtale. Når estimaterne afviger, diskuterer teamet årsagerne bag de afvigende værdier, indtil der er opnået konsensus. Resultatet er en item risk score: Chance ganget med konsekvens.

I praksis oversætter mange teams scoren til en risikoklasse. Score 9 bliver Risikoklasse A, score 4 eller 6 bliver Risikoklasse B, og score 1, 2 eller 3 bliver Risikoklasse C. Det holder samtalen fokuseret på relativ prioritet frem for falsk numerisk præcision. For ingen risikovurdering er mere præcis end de antagelser den bygger på.

En vigtig detalje som mange teams overser: Product owner deltager i risk poker, modsat planning poker. Product owner repræsenterer interessenterne og bidrager med det forretningsmæssige perspektiv som udviklere og testere kan undervurdere, særligt når det handler om at kalibrere konsekvensen af en fejl korrekt. Scrum Masteren faciliterer men spiller ikke selv.

Resultatet? En risikotabel. Et struktureret overblik over alle user stories i sprintet med en risikoklasse for hver relevant kvalitetskarakteristik.

Fra risikoklasse til testintensitet

Okay, vi har vores risikotabel. Hvad nu?

Nu bestemmer teamet hvor intensivt hver kombination af story og kvalitetskarakteristik skal testes. Testintensitet udtrykkes i tre niveauer: ••• (høj), •• (mellem) og • (lav).

Reglen er enkel. Risikoklasse A kræver mindst ét ••• . Risikoklasse B kræver mindst •• . Risikoklasse C får aldrig mere end • . Det er tilladt at gå ned i intensitet, men kun med en dokumenteret begrundelse som alle kan se.

Denne struktur forhindrer to klassiske fejl. Den første: At behandle alle stories ens uanset risiko. Den anden: At beslutte uformelt at teste noget “lidt mere” uden at gøre den beslutning synlig. I en CI/CD-pipeline der kører kontinuerligt, er usynlige beslutninger om testintensitet en direkte kilde til uforudsigelig kvalitet.

Kvalitetstiltag: Fra intensitet til konkret handling

Testintensitet fortæller hvor meget. Kvalitetstiltag fortæller hvordan.

For hver kombination af story, kvalitetskarakteristik og testintensitet vælger teamet de konkrete kvalitetstiltag de vil anvende. Og her er det vigtigt at forstå, at kvalitetstiltag ikke er begrænset til dynamisk test. Tværtimod. Det fulde spektrum inkluderer tre kategorier:

Forebyggende tiltag der bygger kvalitet ind fra starten

• Pair programming
• Test-Driven Development
• Behavior Driven Development
• Specification by example

Disse hører hjemme tidligt i leverancecyklussen, i Plan- og Code-stadierne af pipelinen.

Afslørende tiltag der demonstrerer kvalitetsniveauet

• Funktionel test
• Performancetest
• Sikkerhedstest
• Statisk analyse
• Eksplorativ test

Disse fordeles over pipeline-stadierne afhængigt af hvad der skal verificeres og hvornår.

Korrigerende tiltag der proaktivt forbedrer kvaliteten

• Refaktorering
• Feature toggles

Disse hører hjemme i Integrate-stadiet og i teamets løbende refleksion.

Og så er der en forbindelse som mange teams overser, nemlig risiciene og måden at dække dem på er direkte forbundet med acceptkriterierne på story-kortet. En velbeskrevet Confirmation indeholder ikke kun de glade scenarier. Den inkluderer fejlsituationer, edge cases og hints om hvilke testmetoder der er relevante. Det er den forbindelse der gør teststrategien konkret og handlingsorienteret frem for et dokument ingen læser.

Fra teststrategi til quality engineering strategi

En traditionel teststrategi fokuserer primært på de afslørende kvalitetstiltag. Altså det vi normalt forstår ved “test”. Men i DevOps er kvalitet et teamansvar fordelt over hele leverancecyklussen, og så er en traditionel teststrategi ikke nok.

Det fører os til begrebet quality engineering strategi: En udvidelse af teststrategien der giver lige vægt til forebyggende, afslørende og korrigerende tiltag, og eksplicit placerer hvert tiltag der, hvor det hører hjemme i leveranceprocessen.

Lad os tage et konkret eksempel. Et team bygger en ny funktion i deres app der viser brugere deres præcise ventetid i en kø. Teamet klassificerer dette som høj risiko (risikoklasse A). Hvis ventetiden vises forkert, bliver brugerne frustrerede og tilliden til appen falder. Som forebyggende tiltag vælger teamet pair programming under Code-stadiet. Som afslørende tiltag anvender de funktionel test og performancetest med fokus på svartid. Som korrigerende tiltag planlægger de refaktorering under Integrate-stadiet.

Det er ikke bare en testplan. Det er en bevidst, risikobaseret fordeling af kvalitetsaktiviteter over hele sprintcyklussen med hvert tiltag begrundet i den risiko det adresserer.

I en CI/CD-kontekst får dette en direkte operationel betydning. Teams der bruger Jira eller Azure DevOps kan registrere risikoklassen og de aftalte kvalitetstiltag direkte på hver user story. Pipeline-konfigurationen kan herefter referere til disse oplysninger og anvende de relevante testsæt på hvert stadie. Stories med høj risiko kræver den højeste testintensitet på tværs af pipeline-stadierne. Stories med lav risiko kører et målrettet subset. Quality gates, de definerede kriterier som en build skal opfylde inden den avancerer til næste pipeline-stadie, omsætter strategien til konkret pipeline-håndhævelse.

Strategien er levende, ikke et dokument der samler støv

Her kommer den del som mange glemmer.

En quality engineering strategi skabes ikke én gang og lægges i en skuffe. User stories ændrer sig. Nye stories tilføjes. Risikoopfattelsen skifter efterhånden som teamet lærer mere om produktet og dets brugere. Og når en hændelse opstår i produktion, giver den reel evidens for at risikovurderingen af det berørte komponent var sat for lavt.

Kapable DevOps-teams stiller spørgsmålet “skal vi opdatere vores quality engineering strategi?” ved hvert daily standup og i hvert retrospektiv. For teamet er strategien primært en to-do-liste: En klar og fælles aftale om hvilke kvalitetsaktiviteter der skal udføres, med hvilken intensitet og på hvilket tidspunkt i leverancen.

Når den liste er synlig, vedligeholdt og ejet af hele teamet, holder kvalitet op med at være en kontrolaktivitet forbeholdt testere til sidst i processen og bliver en del af måden teamet arbejder på. Hver dag. I hvert sprint.

Og det er egentlig det, som det hele drejer sig om.

Bliv bedre til at omsætte teststrategi til praksis
Risikobaseret teststrategi i CI/CD kræver fælles sprog, tydelige prioriteringer og konkrete kvalitetstiltag i teamet. På vores testkurser arbejder du praktisk med teorien, får eksempler fra virkelige IT-projekter og sparring fra undervisere med solid erfaring fra praksis. Se vores kommende kurser i ISTQB, TMAP og test — eller kontakt os om et skræddersyet forløb til jeres team

Her kommer der lige en lille disclaimer: Denne artikel er ikke nedfældet af en kunstig intelligens, men derimod et helt almindeligt menneske.

Ret vildt, synes du ikke?

Det der for ganske få år siden ville have været en selvfølge, bliver i dag gradvist en sjældenhed i forhold til AI-generet indhold.

Med nogle få instruktioner kunne jeg nemt have fået en AI til at generere enten et udkast eller en hel artikel om dette emne, alt afhængigt af hvilken grad af autonomi jeg ville tildele den.

For det går hurtigt med AI, meget hurtigt.

Særligt inden for softwareudvikling, hvor millionvis af AI-genererede linjer kode bliver spyttet ud dagligt på tværs af vores lille blå planet.

Og når udviklingshastigheden stiger, ja så må hastigheden på at kvalitetssikre dets output følge med.

Så lad os tage et kig på, hvad GenAI egentlig er og hvordan det passer ind i en test og QA-kontekst.

Hvis du allerede nu føler, at det der GenAI har du bare helt styr på, så kan du passende springe ned til overskriften: ‘Hvordan kan GenAI bruges i test kontekst?’.

Her vil jeg komme med eksempler på, hvordan GenAI kan anvendes i test og QA-opgaver.

Hvad er GenAI?

Lad os prøve at visualisere, hvad AI egentlig er.
Forestil dig, at langt ude i skoven lå et bjerg kaldet AI.

På det bjerg stod der så et lille træ, som vi vælger at kalde Generative AI eller blot GenAI.

Træets rødder kaldes neural networks. Rødderne løber op i stammen, language models (LM). På stammen sidder der en gren, pre-trained language models (PLM). På grenen er der tre kviste, en lille kvist, small language models (SLM), en mellem kvist, large language models (LLM) og en stor kvist, multimodal LLM. Og på den store multimodal LLM-kvist sidder der nogle blade, vision-language modeller.

Forvirrende? Lad os dykke ned i, hvad de forskellige elementer så egentlig betyder.

Neural networks

Neural networks eller på dansk kaldet neurale netværk, udgør selve fundamentet for den moderne kunstige intelligens, som vi kender til i dag. De neurale netværk fungerer ved at efterligne vores menneskelige hjerner ved at behandle information gennem bittesmå beregningsenheder, som vi ofte kalder neuroner. Neurale modeller, altså matematiske modeller opbygget gennem neurale netværk, har været igennem en massiv udvikling gennem flere generationer. Fra de tidlige neurale modeller som Recurrent Neural Networks (RNN), der behandler data sekventielt, til de nuværende modeller bygget på Transformer-arkitekturen, som behandler data parallelt.

Det gennemgående for de neurale modeller er deres evne til at processere konteksten af store tekstmængder. Men det er netop her, at Transformer-arkitekturen skiller sig ud fra de tidlige neurale modeller. Hvor RNN-baserede modeller læser tekst som vi læser en bog, ord for ord og fra venstre mod højre, så kan Transformer-baserede modeller læse hele sætningen på én gang og vurdere, hvilke ord der er vigtige ift. hinanden. Det er en uhyre egenskab, som vi kalder self-attention mekanismen.

Forestil dig lige en gang, at du er i gang med at læse en fejlrapport. I rapporten står der sætningen: “Log ind knappen virker ikke, når brugeren trykker på den”. En RNN-baseret model ville behandle hvert ord i rækkefølge, og dermed risikere at “glemme” den indledende del, inden den havde læst sætningen til ende. En transformer-baseret model forstår derimod med det samme at “knappen” og “trykker” hænger sammen, idet self-attention mekanismen beregner relationerne mellem alle ord i sætningen parallelt.

De to grundsten: Tokens og Embeddings

For at en GenAI kan forstå dine prompts, skal den først nedbryde teksten. Det sker gennem to koncepter, der er fundamentet for det hele:

• Tokenization: Her bliver dine prompts nedbrudt i mindre enheder, også kaldet tokens. Tokens kan være enkle tegn eller et helt ord.
• Embeddings: Hold fast, for nu bliver det lidt teknisk. De nedbrudte tokens bliver derefter oversat til tal i et kæmpe koordinatsystem. Tokens med lignende betydninger og anvendelse, placeres tæt på hinanden. På den måde “forstår” modellen de semantiske sammenhænge mellem de nedbrudte tokens.

Language models (LM) & pre-trained language models (PLM)

De neurale netværks rødder løber op i stammen, language models (LM). En language model er kort fortalt en model, der er trænet i at forstå og forudsige sprog ved at lære mønstre fra tekst. Som det tidligere er beskrevet i de to grundsten: tokens og embeddings, så er det her modellens forståelse opstår. Teksten nedbrydes, den oversættes til et tal og gennem talrepræsentationen lærer modellen at genkende mønstre og forudsige sprog.

Fra stammen vokser der sig en gren, pre-trained language models (PLM). En PLM er en videreudvikling af LM der, fremfor at være blevet trænet på en specifik opgave, først bliver trænet på massive mængder tekst – her taler vi alt fra klassiske romaner og videnskabelige artikler til madopskrifter. Denne proces kalder vi pre-training, som giver modellen en generel sprogforståelse, inden den bliver taget i brug med specifikke opgaver.

SLM & LLM: Sprogmodellerne der har læst (næsten) alt

Åh ja, så kom vi til de to mindste kviste; small language models (SLM) og large language models (LLM).

Den mindste kvist, Small Language Models (SLM), er kompakte modeller. Det vil sige, at modellerne har færre end 10 milliarder parametre, hvor parametre skal forstås som de talværdier, der udgør den specifikke og veldefinerede viden som modellen har opbygget under sin pre-training. Modellens specifikke viden og kompakte størrelse gør altså at den er væsentligt lettere at køre og i modsætning til bladet ved siden af, så kan den faktisk afvikles til veldefinerede opgaver lokalt på din computer eller smartphone – det er da ret sejt.

Den mellemste kvist, large language models (LLM), har du formentlig hørt om allerede. Det er dem vi i det daglige kender fra Claude, Gemini, Mistral og ChatGPT. Hvor SLM’er er nogle små kompakte specialister, er LLM’er derimod nogle store og brede generalister. Under dens pre-training har den fået en massiv mængde viden om alskens slags, og med netop den viden kan modellen forstå, når vi mennesker kommer med input til den gennem prompts.

Fra fundament til de helt svære opgaver

De brede generalist LLM’er kan derimod også blive videreudviklet. Udviklingen af en LLM minder lidt om en konsulents avancement i konsulenthuset. Den starter som en Foundation LLM, der er en generalist, som ved lidt om alting (juniorniveau). Derefter bliver den Instruction-tuned, altså trænet specifikt i at forstå og følge menneskelige instruktioner (mellemniveau). Og til sidst har vi Reasoning LLMs, som udbygger instruction-tuned modeller gennem kognitive evner som syllogisme, multi-trin problemløsning, og det vi kalder chain-of-thought reasoning.

For at holde dem på rette spor bruger man Reinforcement Learning from Human Feedback (RLHF). Her er det altså rigtige mennesker, der giver feedback til modellen for at sikre, at den opfører sig ordentligt og svarer sikkert.

Multimodal LLM’er og Vision-Language Modeller

Nå, men fra den fine pre-trained language models (PLM) gren sidder der også en stor kvist, Multimodale LLM. Den multimodale LLM udvider LLM’ernes evne til at behandle andre typer data end tekst, herunder billeder, video og lyd. Dette grundet deres træning på store og forskelligartede datasæt. For at modellen kan håndtere de forskelligartede modaliteter, bliver den iboende tokenization tilpasset de forskellige datatyper. Dette ses bl.a. ved konverteringen af billedtokens til embeddings, som vi tidligere har set med tekst.

På den store kvist sidder der flere blade, Vision-language-modeller, der specifikt integrerer visuel og tekstuel information for at udføre opgaver såsom billedtekstning (image captioning), visuel spørgsmålsbesvarelse (visual question answering) og analyse af overensstemmelsen mellem tekstuelt og visuelt input.

Og når vi så taler om GenAI i forbindelse med test og QA, så giver multimodale LLM’er, og særligt LLM’er suppleret med vision-language-modeller, betydelige muligheder. Eksempelvis ved at analysere visuelle elementer i applikationer, såsom screenshots og GUI-wireframes, sammen med tilhørende tekstbeskrivelser, herunder fejlrapporter eller user stories. Denne egenskab gør det muligt for testere at identificere uoverensstemmelser mellem forventede resultater og de faktiske visuelle elementer.

Hvordan kan GenAI bruges i test kontekst?

At bringe GenAI ind i softwaretest er ikke bare en lille opgradering – det er et regulært paradigmeskift. Vi bevæger os væk fra de tunge, regelbaserede metoder og over mod en mere intelligent og adaptiv automatisering, der dækker hele vejen fra de første krav til den endelige rapport.

Her er de fem områder, hvor GenAI for alvor kan gøre en forskel lige nu:

1. Analyse af krav og testdesign: AI som din “sparringspartner”

Vi kender det alle sammen: Kravspecifikationer, der er mere mudrede end en dansk efterårsdag. Her er LLM’er geniale:

• Oprydning i kravene: Smid dine dokumenter ind i en LLM’ers chat interface, og den vil lynhurtigt spotte eventuelle uklarheder eller manglende info. Modellen kan muligvis give dig de helt rigtige spørgsmål til dine stakeholders, som du måske først ville have opdaget halvvejs i testfasen.
• Automatisk generering af testcases: AI’en kan hurtigt læse dine BDD-user stories og derefter generere testcases, mål og forventede resultater på ingen tid.
• De skæve scenarier: AI’en er god til at finde de der “edge cases”, som vi mennesker overser, når vi har hovedet fuldt af de mest gængse brugerrejser.

2. Implementering og data: Slut med at vente på testdata

Det er her, vi for alvor mærker hastigheden:

• Syntetisk testdata: Har du også prøvet at kæmpe med GDPR-regler og anonymisering af kundedata? AI kan generere realistiske, men 100% kunstige datasæt, der ligner den ægte vare på en prik, uden at du kommer i klemme med lovgivningen.

3. Vedligeholdelse der klarer sig selv (næsten)

En af de største frustrationer i testautomatisering er skrøbelige scripts, der fejler ved selv de mindste UI ændringer.

• Self-healing: Moderne AI-frameworks kan selv opdatere dine scripts, når UI’en eller API’et ændrer sig.
• Intelligent prioritering: Ved at kigge på historiske data kan AI’en fortælle dig, hvilke testcases der er vigtigst at køre lige nu, baseret på hvor risikoen for fejl er størst.

4. Analyse af resultater: Hvad gik der egentlig galt?

Når testen fejler, starter detektivarbejdet. Men AI’en har allerede læst logfilerne for dig:

• Forklaring af fejl: I stedet for at kigge på en kryptisk sensor-log eller 500 linjer fejlmeddelelser, kan AI’en give dig en sammenhængende forklaring på, hvorfor det gik galt, og hvad du skal gøre for at fikse det.
• Automatisk dokumentation: Den kan endda skrive dine defekter og rapporter færdige, så de er klar til audit uden det store manuelle benarbejde.

5. Husk nu mennesket i maskinrummet

Selvom alt det her lyder som den rene QA-lykke, så kræver det en hybridmodel. Vi kan ikke bare læne os tilbage og lade AI’en styre showet alene:

• Tjek resultatet: Selvom GenAI og LLM’er er smarte, så kan modellerne ligesom du og jeg stadig lave fejl. De kan skrive testlogik, der ser rigtig ud, men som ikke stemmer overens med testobjektet. Derfor skal du altid have en ekspert (dig!) med i loopet.
• Styr på standarderne: Vi skal sikre os, at det AI’en genererer til os, rent faktisk lever op til vores kvalitetskrav og den gældende lovgivning.

Puha, det blev en lang omgang. Hvis du stadig læser med, så kommer der lige en kort opsummering:

• GenAI bygger på neurale netværk og transformer-arkitekturen, som gør modellerne i stand til at forstå tekst parallelt og dermed relationen mellem ord
• Sprogmodeller forstår tekst gennem tokens og embeddings – altså nedbrydning i enheder og nummerering.
• Pre-training giver sprogmodeller baggrundsviden – både til SLM specialisterne og LLM generalisterne
• Multimodale LLM’er kan kombinere tekst og billeder, eksempelvis screenshots af GUI-baserede fejl og user story.
• GenAI kan hjælpe med meget af det manuelle arbejde i test og QA, fra kravanalyse og testdesign til fejlforklaring, men det er stadig vigtigt med et human-in-the-loop.

Og som jeg skrev i det indledende, så går det meget hurtigt med AI. Men hvis vi lige vender den formulering på hovedet engang. Mens alle andre bekymrer sig om, hvorvidt GenAI kommer til at erstatte dem på arbejdspladsen, så sidder du nu med en bedre forståelse af, hvad det hele egentlig drejer sig om. Du ved hvad et neuralt netværk er, du ved hvorfor transformer-baserede modeller er klogere end RNN-baserede modeller, og du ved hvordan GenAI kan blive din nye buddy i testarbejdet. Det gør dig bestemt ikke overflødig, det gør dig snarere farlig. Altså på den gode måde. Så ja, det går hurtigt. Men det bliver også sjovere at være tester.

… råber Scrum Masteren flabet ud i æteren. Og ja! Jeg ved selvfølgelig godt, det er en provokation. For sandheden er, at vi elsker frameworks: De lover struktur i kaos, fremdrift i kompleksitet og svar på det, der føles uoverskueligt. Frameworks kommer med certificeringer, tegninger, roller og ceremonier. De giver os noget at holde fast i, når forandring presser sig på.

Men hvad nu, hvis det ikke er frameworket, der skaber forandringen? Hvad nu, hvis det, vi igen og igen forsøger at løse med nye modeller og processer, i virkeligheden handler om noget langt mere fundamentalt: vores værdier og den adfærd, de skaber?

Efter syv år med agile transformationer har jeg set det samme mønster gentage sig: Organisationer implementerer frameworks med de bedste intentioner og står ofte tilbage med compliance uden commitment. Ceremonier uden energi. Tavler uden transparens. Retrospektiver uden reel refleksion. Frameworks er ikke problemet. Men de er heller ikke løsningen alene. Hvis vi vil skabe ægte forandring, skal vi starte et andet sted – nemlig med vores værdier.

Min påstand er, at alle teams er forskellige, og derfor står jeg gang på gang også tilbage med et presserende spørgsmål: Hvorfor bliver de igen og igen presset ned i frameworks, der ikke er skræddersyet til dem, uden at nogen for alvor stopper op og spørger, hvorfor det bliver ved med at ske, og om det virkelig er måden at gøre tingene på?

I min optik er det ikke frameworks, der i sig selv er problemet. De kan være utrolig brugbare, men for mig opstår problematikken, når vi tror, at det er implementeringen af et framework, der i sig selv skaber forandring.

SAFe, Scrum, Kanban og Product Team. Du kan selv vælge din personlige favorit og så fortælle mig, om du mener, at det var implementeringen af frameworket, der skabte forandringen.

Min tese: Det gjorde den ikke. Og derfor mener jeg, at vi i stedet skal stille skarpt på vores værdier.

Gode intentioner

Jeg tror fuldt ud på, at når organisationer implementerer et nyt og revolutionerende framework, bliver det gjort i den allerbedste mening, fordi en transformation er dyr. Samtidig kan de se, at det virkede hos konkurrenten, så det er vel investeringen værd? Måske.

Men hvis man forsøger at implementere et framework uden at forankre det i et bevidst og tydeligt værdisæt, så kæmper man som forandringsleder en unfair kamp. Min erfaring viser mig, at den til tider er helt umulig, fordi et nyt framework ikke ændrer adfærden, uanset hvor mange møder der bookes ind til. Det gør værdierne bag.

For vi er alle styret af vores interne værdisæt: rigtigt og forkert, rimeligt og urimeligt. Så kan vi få skabt fælles ejerskab om forandringens værdier, så har vi grobund for fælles adfærdsændring.

Start nu med værdierne

Jeg har tilpas meget erfaring til at vide, at transformation er svær, og min erfaring har heldigvis også givet mig en masse læring med undervejs. En af de absolut vigtigste læringer for mig er, at jeg til hver en tid vil starte med værdierne, når jeg starter en transformation.

Jeg arbejder primært med overgangen til agile arbejdsmetodikker (ofte Scrum), så det betyder værdier før ceremonier.

Måske gør du det samme, og så vil du heller ikke blive overrasket over, at følgende er de altoverskyggende værdier, jeg arbejder efter:

Transparens
Refleksion
Adaption

Derfor synes jeg også, at Scrum er interessant, fordi det grundlæggende bygger på det samme værdisæt, som jeg har. Så langt, så godt: et framework, der understøtter mine værdier.

Men hvis det ikke fungerer i praksis, så bliver der justeret i samarbejde med teamet.

Frameworket er trods alt til for teamet. Ikke omvendt.

Når det lykkes

Så hvordan ser det ud i virkeligheden, når vi lykkes med en transformation med udgangspunkt i værdierne?

Lad os tage udgangspunkt i Scrum-ceremonierne: Daily, Retrospektiv og Planning.

Daily
Daily kan være et fantastisk rum for transparens, refleksion og adaption.

Når dit team forstår værdigrundlaget, så går Daily fra at være et statusmøde med røvsyg afrapportering til at være et ønsket “timeout-kort” i en travl hverdag, hvor teamet får vendt aktuelle problemstillinger, søger hjælp og giver sparring for at sikre fremdrift mod et fælles mål.

Skal det være hver dag for at opnå det?
Skal det vare 15 minutter?
Skal vi stå op eller sidde ned?

Ikke nødvendigvis, men vi skal være enige om værdien af et fælles overblik og hurtig justering og finde den form, der faktisk understøtter det – i stedet for blot at følge Scrum Guidens retningslinjer.

Retrospektiv
Retrospektiver er geniale til refleksion og adaption, men kun hvis der er psykologisk tryghed til at understøtte transparens.

Hvis teamet ikke tør sige tingene højt, så risikerer vi, at retrospektivet bliver en ventil for “varm luft” og ikke grundlæggende problemhåndtering inden for vores kontrolcirkel.

Oplever du, at teamet ventilerer “varm luft” om ledelse og opgaver, skal du måske starte et helt andet sted:
Hvordan skaber jeg tryghed i mit team?

Når trygheden er der, så kommer transparensen, og så tvivler jeg på, at teamet kan blive færdigt med retrospektivet på under en time.

Alle vil deltage i debatten, snakke åbent om problemet og de konsekvenser, der følger med, uden at det bliver personspecifikt. Vi går efter bolden, ikke manden, og vi sørger for at komme i mål med nogle klare og håndgribelige forandringer, der skal prøves af i den kommende iteration.

Forhåbentlig leder det til øget effektivitet, men min oplevelse er også, at et trygt og vellykket retrospektiv øger tilhørsforholdet og viljen til at lykkes som et team – ikke som individer.

Planning
Når vi planlægger, bliver vi tvunget til at kigge på den virkelighed, vi står overfor.

Men i et team, hvor transparens ikke er til stede eller prioriteret, vil vi sandsynligvis opleve en del spillover, undskyldt med: “Det her er altså vanvittigt vigtigt, og der bliver ved med at komme nye problemer, hver gang jeg løser ét. Kan vi ikke bare lave en part 5 og så lukke part 4?”

Er opgaven så færdig efter næste iteration? Næppe. Kan det afhjælpes? Bestemt – hvis vi fortæller, hvad vi reelt laver, i stedet for at blande det hele sammen under samme titel, fordi det er let.

Står vi uden transparens i vores opgaver og virkelighed, så bliver det svært at agere korrekt og lave de nødvendige prioriteringer for at levere mest mulig værdi i den kommende iteration.

Vi kan også befinde os i en situation, hvor der er transparens, men hvor der ikke bliver reflekteret eller handlet.

F.eks. kunne det være helt tydeligt, at der ikke er en jordisk chance for at opnå Product Ownerens mål for iterationen.

Vi kender alle opgaverne, de er veldefinerede, og det står klart, at det ikke kan lade sig gøre. Teamet fylder sprintet op i forhold til målet – sandsynligvis med opgaver op over begge ører – og siger: “Held og lykke, folkens.”

Men er det sådan, vi har skabt mest mulig værdi? Kunne vi have omformuleret målet? Gjorde vi opmærksom på konsekvenserne?

Teamet burde stoppe op. Reflektere. Og træffe en hård, men nødvendig beslutning for at starte en realistisk iteration, hvor resultatet ikke blot er værdi skabt for stakeholders, men også en oplevelse af succes i teamet.

Det er dybt afhængighedsskabende at opleve succes – noget med dopamin. Look it up.

Den grimme sandhed

Som det nok efterhånden er tydeligt, lever jeg ud fra et ret simpelt verdensbillede.
Og jeg er pinligt bevidst om, at det er lettere sagt end gjort.

Men… i min verden bliver transformation ikke en kamp, hvis:

• teamet kan se sig selv i værdierne
• de forstår, hvad de får ud af dem
• procesforandringerne tydeligt understøtter dem

Det bliver en mulighed for individuel læring, succeser som hold og ægte forandring i adfærd.

Men hvis vi starter med at rulle et framework ud og håber, at adfærden følger med af sig selv?

Ja, så risikerer vi compliance uden commitment.
Tidskrævende ceremonier uden ægte refleksion.
Jira-boards uden transparens.

Og så undrer vi os over, hvorfor “det agile” ikke virker.

Så drop de frameworks

Eller rettere: drop blind framework-implementering. Frameworks kan være fremragende.
Men de er kun så gode som det værdisæt, de er forankret i, for transformation handler ikke om at gøre frameworket rigtigt. Det handler først og fremmest om at skabe en adfærd, der virker i jeres kontekst.

Og det starter ikke med PowerPoints og intromøder. Det starter med, at du som forandringsleder tør være tydelig omkring værdierne – og konsekvent i at lade dem styre processen.

Kan du det? Eller gemmer du dig bag frameworket?