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?

I denne artikel bruger jeg QA (Quality Assurance) som betegnelse for den funktion i organisationen, der har det faglige ansvar for kvalitet i IT-projekter. Uanset om den hos dig hedder test, kvalitetssikring, QC eller noget helt fjerde.

Sprintet er afsluttet. Velocity ser fornuftig ud, burndown-kurven er pæn, og teamet er allerede i gang med næste iteration. To uger senere opstår der en fejl i produktion, og der indkaldes til post mortem. Udvikleren troede, QA håndterede det. QA havde ikke mandat til at stoppe leverancen. Projektlederen kendte ikke til problemet. Scrum Masteren faciliterede processen som forventet. Ingen var ligeglade. Ingen gjorde noget forkert. Og alligevel gik det galt.

Det er ikke et menneskeligt problem. Det er et strukturelt et. Og det har en velkendt årsag: vi har i årevis fortalt hinanden, at kvalitet er alles ansvar – og derved gjort det til ingens.

Et godt princip, en svær praksis

Det agile manifest kom som en velfortjent reaktion på vandfaldsmodellens svagheder; Kvalitet som en isoleret gate til sidst i processen, og en QA-afdeling der fik tre uger til at validere seks måneders arbejde, var ikke bæredygtigt.

Intentionen om at integrere kvalitet løbende var rigtig. Men et princip er ikke det samme som en ansvarsstruktur. Problemet opstår, når princippet bliver brugt som erstatning for reel ansvarsplacering.

I organisationer med tydelig ansvarsplacering ved alle, hvem der kan sige stop, hvem der har faglig autoritet, og hvem der bærer det sidste ord, når risiko vægtes mod leverance. I organisationer der bruger “kvalitet er alles ansvar” uden en tilhørende struktur, er svarene ofte uklare.

Når ejerskabet er uklart, vinder deadlinen

Når ejerskabet er uklart, udfyldes tomrummet af deadlinen. I IT-projekter er det sjældent kvalitet, der har mest politisk pres, selvom vi er nogen der mener andet. Det er leverancetid, budget og forventninger opad i organisationen.

Derfor ender en faglig vurdering fra QA ofte som en anbefaling, og ikke som en retningsgivende beslutning. QA kan rådgive, men ikke bremse. Dermed træffes kvalitetskritiske beslutninger af dem, der står med pres for leverancen, og ikke af dem med den faglige indsigt i risikoen.

Det er et mønster, de fleste med erfaring fra IT-projekter vil genkende øjeblikkeligt. Ikke fordi folk er inkompetente eller ligeglade. Men fordi systemet er designet til at optimere på det, det måler. Og i mange organisationer måles der på tid og økonomi. Ikke på kvalitet.

Det er derfor ikke modstand mod kvalitet, der skaber problemerne, men en styringsmodel, der utilsigtet favoriserer andre hensyn.

Den skjulte regning

De synlige omkostninger ved dette er kendte: Fejl i systemerne og tab af kundetillid. Men der er også en mere langsigtet konsekvens. Når QA ikke har et tydeligt mandat, mister rollen gradvis gennemslagskraft. Fagligheden udvandes, erfarne medarbejdere søger væk, og dem der bliver tilbage, bruger mere energi på at forklare deres eksistensberettigelse end på at udøve deres faglighed. Fælles for disse konsekvenser er, at de er metrikker som oftest ikke måles, og derfor bliver usynlige.

Ikke et fripas

Det er ikke ensbetydende med at det kun er én person der skal bære hele ansvaret for kvaliteten.

Alle har stadig et del-ansvar. Product Owneren har ansvaret for at opgaver i pipeline skaber værdi for kunden og er tydelige og prioriterede. Udviklerne har ansvar for at sikre deres arbejde lever op til de aftalte kriterier, osv.

Det er vigtigt at alle holdes op på nogle basale kvalitetskrav som defineres fra starten.
Kvalitet der skabes i hele værdikæden, øger ejerskab og engagement fordi alle tager ansvar for deres egen kvalitet.

Det nødvendige valg

Der er ikke en nem vej ud af dette. Men der er et valg, som er mere kritisk end de fleste vil indrømme.

Du kan vælge at give kvalitet et formelt ejerskab med reelt mandat. En rolle der kan sige stop. En stemme der sidder ved bordet, når prioriteringer og beslutninger træffes.
Det er et ansvar der ikke kan fordeles ud til ”alle”, fordi ansvaret der fordeles ud til alle aldrig bæres af nogen.

Alternativet er at holde op med at bruge “alle ejer kvalitet” som om det er en styringsmodel. Det er det ikke. Det er en værdierklæring uden konsekvens.

Den nemme middelvej, hvor man fastholder mantraet og håber, at det ”denne gang går bedre”, er ikke gratis. Den betales løbende i fejl, teknisk gæld, udvandet faglighed og postmortems med de samme konklusioner som sidst.

Spørgsmålet er derfor ikke, om I har råd til at give kvalitet et tydeligt hjem i organisationen. Spørgsmålet er, om I har råd til at lade være.

Hvis du kan genkende mønstret, er du ikke alene. Spørgsmålet er bare: Hvad I vil gøre ved det?
Vil I have sparring på, hvordan kvalitet kan få et tydeligt mandat i jeres organisation uden at miste det agile momentum, så tag fat i os. Vi tager gerne en helt uforpligtende dialog om jeres setup.

I en tidligere artikel satte Gitte fokus på spørgsmålet: Er TPI Next død? 

Svaret var klart: nej. Tænkningen bag TPI Next – at arbejde struktureret og målrettet med testmodenhed – er stadig både relevant og værdifuld.

I denne artikel bygger Gitte videre på netop den pointe. For selvom en modenhedsassessment er et stærkt værktøj til at skabe overblik over organisationens styrker og forbedringsområder, er det langt fra her, den største udfordring ligger. Den opstår først, når indsigterne skal omsættes til konkrete forbedringer i en travl hverdag.

Og det er netop her, mange organisationer oplever, at det bliver svært.

En modenhedsassessment er et fantastisk startsted for forbedring. Den giver et klart billede af jeres nu-situation: hvad er der styr på, og hvad kan gøres bedre.

Hvis jeres assessment er lavet professionelt, står I med en grundig rapport, der ikke kun fortæller om jeres forbedringsmuligheder, men også om jeres styrker – og om hvad der ligger udenfor test, som kan styrkes for at bidrage til testprocessen (kaldet enablers).

Men for nogen bliver skridtet fra rapporten til at gennemføre forbedringerne simpelthen for svært eller for tungt. Resultatet er, at rapporten ender som et dødt dokument, der aldrig bliver fulgt op på.

Det kan skyldes mange ting:

• Manglende ejerskab
• Ledelsen prioriterer ikke opfølgningen
• For mange forbedringsområder på én gang
• Manglende kompetencer
• For lidt organisatorisk forankring
• Manglende tid – dagligdagen vinder

Og jeg forstår det godt. Forandring er svært. Det handler ikke bare om at give folk et tredages kursus og så forvente, at de bliver bedre til det, der skal forbedres. Det handler om forandring af helt grundlæggende mekanismer i deres hverdag – aktiviteter de har gjort på en bestemt måde (eller ikke har gjort) gennem mange år.

Forandringerne skal helt ind på rygsøjlen, før de bliver det nye normale. Og det kræver både tid og fokus.

Ejerskab og ledelsesopbakning

Nogle af de problemstillinger jeg listede før, er til at gøre noget ved.

Tag f.eks. manglende ejerskab. Her handler det om at udpege en tydelig ejer – ikke kun af opgaven med at få gennemført en assessment, men i endnu højere grad af det arbejde, der kommer bagefter. Det skal være en person med mandat til at gennemføre forandringer i praksis. Selvfølgelig i samarbejde med andre fagligheder – test er jo ikke en ø 😊.

Det samme gælder ledelsens prioritering af opfølgningen. Her kan man med fordel gøre opfølgning til et fast punkt i ledelsesfora eller etablere en egentlig styregruppe, der følger initiativerne løbende.

Det kan også være en god idé at koble initiativerne til den overordnede IT-strategi. På den måde skabes der en rød tråd og en bedre forståelse for vigtigheden af initiativerne – også hos dem, der ikke arbejder direkte med test.

Når forbedringer møder organisationens virkelighed

En anden klassiker er, at der simpelthen er for mange forbedringsområder i gang på én gang. Det er ofte et faktum, man må leve med. Men her vil jeg klart anbefale at starte med at skabe et overblik over, hvilke forandringsinitiativer der allerede er i gang i organisationen.

Få repræsentanter fra de enkelte initiativer samlet i en workshop, hvor I bliver skarpe på, hvordan de forskellige initiativer påvirker – eller måske endda konflikter med – hinanden.

Et klassisk eksempel fra testverdenen er arbejdet med testbasis, altså grundlaget for vores test: features, user stories, krav osv. En struktureret tilgang til testbasis er afgørende for, at vi kan lave en god testanalyse og implementere en effektiv test. Vi kan også bidrage til kvaliteten af testbasis ved at reviewe den med testperspektivet. Men her ligger der en vigtig pointe: Opgaven med at udvikle testbasis ligger reelt udenfor testprocessen. Den ligger hos product owners og forretningsanalytikere. Derfor kræver forbedringer på dette område ofte ændringer udenfor selve testorganisationen.

Organisatorisk forankring

Manglende organisatorisk forankring er også et reelt problem. Mere end én gang har jeg set organisationer købe eksterne konsulenter ind til at lave en assessment og udrulle forbedringer. Hele projektet bliver drevet af de eksterne konsulenter – og når de forlader organisationen, falder forbedringerne til jorden.

Derfor anbefaler vi altid, at der er en intern forankring. Det må ikke kun være os, der driver forbedringerne. Organisationens egne testfaglige skal være med i arbejdet, tage ejerskab og kunne drive forbedringerne videre, når vi en dag forlader organisationen.

Kompetencer – både faglige og organisatoriske

Hvad så med de manglende kompetencer? Det kan både handle om kompetencer inden for forandringsledelse og om manglende testfaglighed.

Her er der flere håndtag at trække i. Man kan selvfølgelig få hjælp udefra til både assessment og det efterfølgende forbedringsforløb. Men det er mindst lige så vigtigt, at organisationen selv opbygger de nødvendige kompetencer – både hos dem, der skal drive forbedringsarbejdet, og hos dem, der skal arbejde efter de nye processer.

I nogle af mine første opgaver med procesforbedring for mange år siden var løsningen kurser. Det kunne være generelle testkurser eller mere specialiserede kurser med fokus på konkrete forbedringer.

I nyere tid har jeg haft rigtig gode erfaringer med at kombinere tre elementer:

• små minikurser
• e-learning
• quality coaching

Minikurserne bruges ofte til at sætte scenen og komme i gang med forbedringen. Det kan være en introduktion til en teststrategi eller til test i en agil kontekst.

E-learning bruger vi til mere specifikke emner: produktrisikoanalyse, acceptkriterier, testdesign med fokus på data eller proces osv. Og især for nogle af de mere abstrakte emner  har vi haft stor succes med at gennemføre e-learning som en slags bogklub. Et team gennemfører et kursus, og bagefter bruger vi lidt tid sammen på at reflektere over emnet: hvordan kan vi bruge det i praksis i vores kontekst? På den måde får vi diskuteret emnet og sat det ind i teamets virkelighed.

Den sidste brik er quality coaching: en quality coach, der bevæger sig rundt mellem teams, deltager i ceremonier – fra refinement til PI planning, sprint planning og retrospektive – og fungerer som sparringspartner, når forandringerne skal omsættes til praksis.

“Vi har ikke tid”

Og så er der selvfølgelig den klassiske udfordring: vi har ikke tid.

Teamet har ikke plads i sprintet til at implementere forbedringer, fordi backloggen vinder. Vi er trods alt her for at levere værdi til brugerne – det første agile princip.

Her er det vigtigt at have én ting for øje: Hvordan spiser man en elefant? Ét stykke ad gangen.

Forbedringsforløbet skal brydes ned i små initiativer, som teams kan arbejde med lidt ad gangen. Når teams er pressede, nytter det ikke at sige: “Vi hører hvad I siger – men I skal lige nå at ændre 10 ting ved jeres måde at arbejde på.” Så skal vi finde små ting, der kan ændres gradvist. Og hvis det er muligt, skal ændringerne integreres i de ceremonier, teams allerede har.

Et eksempel er produktrisikoanalyse (PRA), som ofte er fundamentet for en risikobaseret teststrategi. I traditionelle projekter laver man typisk en stor workshop i starten af projektet eller releasen. I en agil kontekst kan vi i stedet arbejde med PRA i små bidder:

Når vi refiner features, taler vi om risiko og sætter en risikoklasse på work itemet i Jira (eller hvad vi nu bruger). Når featuren brydes ned i stories – eller senest i sprintplanlægningen – tager vi dialogen igen og sætter også en risikoklasse på user stories.

Det har faktisk flere andre fordele, men dem må vi tage i en anden artikel 😉

Det store billede og de små skridt

Selvfølgelig skal vi have det store billede. Vi skal vide, hvor vi vil hen. Men vejen derhen består af små skridt, som der kan findes plads til i en travl hverdag. Det øger sandsynligheden for, at forbedringerne faktisk bliver en del af organisationens hverdag – og ikke bare endnu en rapport i skuffen.

Fra assessment til forbedring

Når alt kommer til alt, kan ovenstående koges ned til fire helt afgørende præmisser for at gå fra en TPI-assessment til en succesfuld procesforbedring:

1. Ledelsesopbakning
2. Tydeligt ejerskab
3. Kompetencer i organisationen
4. Prioritering og fokus

Har I fået lavet en assessment, men oplever, at det er svært at få forbedringerne til at leve i hverdagen?

Det er helt normalt. Og det er netop her, det meste af arbejdet ligger.

Hos Key2Quality arbejder vi ikke kun med at identificere forbedringsområder, men med at få dem til at fungere i praksis sammen med jer og med respekt for jeres organisation og hverdag. Kontakt os for en uforpligtende snak om, hvordan vi kan hjælpe jer med at omsætte jeres assessment til konkrete forbedringer i hverdagen.