Testmanagerens ugentlige styringsrutine – fem dage, der skaber overblik, kvalitet og fremdrift

God testledelse handler ikke kun om at planlægge test og følge op på testcases. Det handler om løbende at skabe overblik, identificere risici, træffe beslutninger og sikre, at testindsatsen leverer værdi. En fast ugentlig styringsrutine kan være et enkelt, men effektivt redskab til netop dette.

Som testmanager er hverdagen ofte præget af mange samtidige aktiviteter. Testcases skal udarbejdes og afvikles, defekter skal håndteres, testmiljøer skal fungere, og interessenter forventer et retvisende billede af kvaliteten og fremdriften. Samtidig skal vi være opmærksomme på nye risici, ændrede forudsætninger og afhængigheder, der kan påvirke testforløbet.

Det er let at blive fanget i den daglige drift, hvor akutte problemer og møder kommer til at styre arbejdsdagen. Konsekvensen kan være, at testledelsen bliver mere reaktiv end proaktiv.

Men hvad nu, hvis vi organiserede vores styringsaktiviteter i en fast ugentlig rytme?

Ikke som endnu et administrativt lag, men som en praktisk tilgang til at sikre, at de vigtigste ledelsesopgaver faktisk bliver udført.

Mandag – Skab overblik over testfremdriften

Ugens fokus: Hvor står vi i forhold til testplanen?

Leverance: Opdateret teststatus og aftalte handlinger ved afvigelser.

Mandagen bør starte med en systematisk vurdering af testfremdriften. Ikke blot hvor mange testcases der er afviklet, men om testarbejdet bevæger sig i den rigtige retning, og om vi fortsat forventer at nå vores testmål.

En klassisk udfordring i testmanagement er, at fremdriften ofte vurderes ud fra antallet af gennemførte testcases. Men 80 % gennemførte testcases betyder ikke nødvendigvis, at 80 % af de væsentligste risici er afdækket.

Derfor bør testmanageren også interessere sig for, hvilke krav, funktionaliteter og produktrisici der faktisk er testet, og hvilke der fortsat mangler.

Det kan eksempelvis være relevant at undersøge, om de mest kritiske forretningsprocesser er tilstrækkeligt dækket, om testafviklingen følger den planlagte fremdrift, og om der er tegn på forsinkelser, der kræver korrigerende handlinger.

Min pointe: Testfremdrift handler ikke kun om aktivitet, men om opnået kvalitetssikring og reduceret usikkerhed.

Tirsdag – Gennemgå afhængigheder og testforudsætninger

Ugens fokus: Har vi forudsætningerne for at gennemføre testen?

Leverance: Opdateret oversigt over afhængigheder, blokeringer og nødvendige handlinger.

Test gennemføres sjældent isoleret. Vi er afhængige af udvikling, leverandører, testmiljøer, testdata, integrationer og ikke mindst de personer, der skal deltage i testaktiviteterne.

Derfor bør tirsdagen bruges til at vurdere, om de nødvendige forudsætninger fortsat er til stede.

Er testmiljøet stabilt? Er de forventede leverancer klar? Er der adgang til relevante og tilstrækkelige testdata? Er de nødvendige ressourcer til rådighed? Og er der ændringer i projektets tidsplan, som påvirker testaktiviteterne?

I projekter med mange integrationer eller eksterne leverandører er dette særligt vigtigt. En forsinket leverance eller et ustabilt testmiljø kan hurtigt få konsekvenser for både testdækning, fremdrift og kvalitet.

En væsentlig opgave for testmanageren er derfor at identificere afhængigheder, før de udvikler sig til egentlige problemer.

Min pointe: God testledelse handler i høj grad om at fjerne forhindringer, før de påvirker testteamets mulighed for at levere.

Onsdag – Følg op på defekter, kvalitet og testindsats

Ugens fokus: Hvad fortæller testresultaterne om kvaliteten?

Leverance: Opdateret kvalitetsvurdering, defektstatus og eventuelle ændringer i testindsatsen.

Midt på ugen er et godt tidspunkt at analysere de resultater, testaktiviteterne har produceret.

Her bør fokus flyttes fra fremdrift til kvalitet.

Hvor mange defekter er fundet? Hvor alvorlige er de? Hvor hurtigt bliver de rettet? Opstår der gentagne fejl inden for bestemte områder? Og er der tegn på, at fejlrettelser introducerer nye problemer?

Det er vigtigt at se på udviklingen over tid frem for blot at betragte antallet af åbne defekter. En faldende defektkurve kan være positiv, men den kan også skyldes, at testintensiteten er reduceret, eller at de mest komplekse test endnu ikke er gennemført.

Testmanageren bør derfor kombinere kvantitative målinger med kvalitative vurderinger fra testteamet.

Samtidig bør den resterende testindsats vurderes. Er der behov for at omprioritere testcases, øge regressionstesten eller gennemføre supplerende udforskende test?

Her kan AI-baserede analyseværktøjer være nyttige til eksempelvis at identificere mønstre i defekter, sammenfatte testresultater og fremhæve mulige kvalitetsproblemer. Men konklusionerne skal altid vurderes kritisk af mennesker med indsigt i løsningen og dens anvendelse.

Min pointe: Testmålinger skal understøtte beslutninger – ikke blot producere flotte dashboards.

Torsdag – Revurder produktrisici og håndter udfordringer

Ugens fokus: Hvad bekymrer os mest lige nu?

Leverance: Opdateret produktrisikoanalyse og prioriterede risikoreducerende handlinger.

En produktrisikoanalyse er ikke et dokument, der kun skal udarbejdes ved projektets begyndelse. Den skal være et aktivt styringsredskab gennem hele testforløbet.

Torsdagen kan derfor bruges til en systematisk revurdering af de væsentligste produktrisici.

Har testresultaterne ændret vores opfattelse af sandsynligheden for fejl? Er konsekvenserne af bestemte fejl blevet tydeligere? Er der opstået nye risici som følge af ændringer i løsningen, integrationerne eller de forretningsmæssige forudsætninger?

Et konkret eksempel kunne være et projekt, hvor konvertering af data viser sig at være mere fejlbehæftet end forventet. Her er det ikke tilstrækkeligt blot at registrere og følge op på de fundne defekter.

Testmanageren bør også vurdere, om den samlede risiko for datakvaliteten er steget, om testtilgangen skal ændres, og om der er behov for yderligere konverteringstest eller øget involvering af fagpersoner.

Det er netop her, testmanagement bevæger sig fra operationel styring til egentlig kvalitets- og risikorådgivning.

Min pointe: Testmanagerens vigtigste opgave er ikke at dokumentere, at der findes risici, men at sikre, at de bliver forstået og håndteret.

Fredag – Kommunikér kvalitet og skab grundlag for beslutninger

Ugens fokus: Hvad skal interessenterne vide og beslutte?

Leverance: Kort, beslutningsorienteret teststatus og prioriteringer for næste uge.

Fredagen bør bruges til at samle ugens observationer, resultater og vurderinger i en klar og forståelig kommunikation til projektets interessenter.

En god teststatusrapport skal ikke blot fortælle, hvad der er sket. Den skal gøre det tydeligt, hvad resultaterne betyder for projektet, og hvilke beslutninger der eventuelt skal træffes.

Det kræver, at testmanageren kan omsætte tekniske testresultater til et sprog, som projektledelse, forretning og styregruppe kan anvende.

I stedet for blot at rapportere, at 75 % af testcasene er gennemført, og at der er 23 åbne defekter, kan det være langt mere værdifuldt at forklare, at de væsentligste forretningsprocesser er testet, men at to kritiske fejl fortsat udgør en væsentlig risiko for den planlagte idriftsættelse.

Det handler om at kommunikere kvalitet, usikkerhed og konsekvenser – ikke blot testaktiviteter.

Fredagen er samtidig et naturligt tidspunkt at afstemme næste uges prioriteringer med projektledelsen, testteamet og andre relevante interessenter.

Min pointe: Den bedste teststatusrapport er ikke nødvendigvis den mest detaljerede, men den, der gør det lettere at træffe de rigtige beslutninger.

Næste uge – Fra opfølgning til handling

En ugentlig styringsrutine har kun værdi, hvis den fører til konkrete handlinger.

Derfor bør hver uge afsluttes med en tydelig prioritering af de vigtigste aktiviteter i den kommende uge. Hvilke risici skal reduceres? Hvilke defekter skal have særlig opmærksomhed? Hvilke testaktiviteter er vigtigst? Og hvilke beslutninger eller afklaringer er nødvendige?

Det er også værd at bruge et par minutter på at reflektere over selve testprocessen. Hvad fungerede godt? Hvad skabte unødvendige forsinkelser? Og hvad kan vi gøre anderledes?

Denne løbende forbedring ligger i naturlig forlængelse af PDCA-princippet (Plan–Do–Check–Act) og understøtter en mere moden og lærende testorganisation.

En fast rytme – men ikke en rigid proces

Det er vigtigt at understrege, at denne ugentlige styringsrutine ikke skal opfattes som en fastlåst model, hvor bestemte aktiviteter kun må gennemføres på bestemte ugedage.

Kritiske defekter skal naturligvis håndteres, når de opstår, og væsentlige produktrisici skal eskaleres med det samme. På samme måde kan testfremdrift, testmiljøer og afhængigheder kræve daglig opfølgning.

Formålet med den ugentlige rytme er derimod at sikre, at alle centrale styringsområder får systematisk opmærksomhed, og at testmanageren ikke mister det strategiske overblik i den operationelle hverdag.

I agile projekter kan aktiviteterne med fordel integreres i eksisterende ceremonier, mens de i mere traditionelle projekter kan fungere som en selvstændig styringsstruktur. Omfanget bør altid tilpasses projektets kompleksitet, risikoprofil og behov for governance.

Fra testadministrator til strategisk kvalitetsrådgiver

Jeg mener, at vi som testmanagers skal være varsomme med at reducere vores rolle til administration af testcases, defekter og rapporter.

Vores egentlige værdi ligger i at skabe gennemsigtighed, udfordre antagelser, identificere risici og rådgive projektet om kvalitet.

En struktureret ugentlig styringsrutine kan hjælpe os med netop dette. Den giver plads til både den operationelle opfølgning og de mere analytiske og strategiske overvejelser, som ellers let bliver nedprioriteret.

Samtidig giver den et godt grundlag for at anvende automatisering og AI til at understøtte arbejdet med eksempelvis statusopsamling, trendanalyser og identifikation af afvigelser. Men teknologien må aldrig erstatte den kritiske vurdering, dialogen med interessenterne eller det menneskelige ansvar for beslutningerne.

For i sidste ende handler testmanagement ikke om at have styr på flest mulige tal.

Det handler om at have styr på de forhold, der har størst betydning for kvaliteten – og sikre, at den viden bliver omsat til handling.

Og måske er det netop her, en enkel ugentlig styringsrutine kan gøre en overraskende stor forskel.

AI i testmanagement – en fantastisk assistent, men en farlig autopilot

Jeg er positiv over for kunstig intelligens i testmanagement. Faktisk ser jeg AI som en af de mest interessante muligheder for at udvikle vores fag i mange år. Men jeg er også skeptisk. Ikke fordi jeg er imod teknologien, men fordi jeg er bekymret for, hvad der sker, hvis vi begynder at stole mere på AI end på vores egen faglighed, erfaring og kritiske sans.

AI kan hjælpe os med at analysere, planlægge, prioritere, dokumentere og rapportere. Den kan på få minutter producere materiale, som tidligere kunne tage timer eller dage at udarbejde. Det er imponerende, og det skal vi naturligvis udnytte.

Men der er en væsentlig forskel på at producere noget hurtigt og på at producere noget, der er rigtigt, relevant og værdiskabende.

Og netop den forskel mener jeg, at vi som testmanagers skal være særligt opmærksomme på.

AI kan gøre os mere effektive – men gør den os også bedre?

Der er ingen tvivl om, at AI allerede kan understøtte en lang række af testmanagerens opgaver.

Vi kan eksempelvis anvende AI til at udarbejde udkast til teststrategier og testplaner, identificere potentielle produktrisici, foreslå testaktiviteter, analysere defektmønstre og formulere statusrapporter til projektledelse og styregrupper.

AI kan også være en værdifuld sparringspartner, når vi skal udfordre vores egne vurderinger. Har vi overset væsentlige risici? Er vores testtilgang tilstrækkelig? Er der sammenhæng mellem de identificerede risici og den planlagte testindsats?

Det er alt sammen områder, hvor jeg ser et betydeligt potentiale.

Men jeg mener samtidig, at vi skal passe på med at forveksle effektivitet med kvalitet.

En AI-genereret teststrategi kan være velformuleret, struktureret og tilsyneladende komplet. Men det betyder ikke nødvendigvis, at den er rigtig for det konkrete projekt.

AI kender ikke automatisk organisationens kultur, de politiske forhold, historikken med leverandøren, interessenternes bekymringer eller de erfaringer, som testmanageren har opbygget gennem dialog med projektets deltagere.

Og måske vigtigst af alt: AI har ikke det personlige ansvar for konsekvenserne af sine anbefalinger.

AI kan udarbejde en testplan på få minutter. Men den kan ikke alene afgøre, om det er den rigtige testplan.

Den største risiko er måske ikke, at AI tager fejl

Vi taler ofte om hallucinationer, når vi diskuterer risici ved generativ AI. Altså situationer, hvor AI producerer oplysninger, der virker overbevisende, men som er faktuelt forkerte eller udokumenterede.

Det er naturligvis en reel udfordring.

Men jeg mener faktisk, at en endnu større risiko er, at vi holder op med at stille de kritiske spørgsmål.

Når AI leverer et velformuleret svar, kan vi let blive fristet til at acceptere det. Særligt hvis svaret bekræfter vores egne antagelser eller passer ind i den konklusion, vi allerede havde forestillet os.

Det er en form for automatiseringsbias, hvor vi tillægger teknologiens anbefalinger større troværdighed, end de nødvendigvis fortjener.

Forestil dig eksempelvis, at AI analyserer en række testresultater og anbefaler, at et system er klar til idriftsættelse.

Anbefalingen bygger måske på en høj testdækning, få åbne alvorlige defekter og en positiv udvikling i testafviklingen.

Men hvad nu, hvis de vigtigste forretningsmæssige risici slet ikke er tilstrækkeligt testet? Hvad hvis testmiljøet ikke er repræsentativt? Eller hvad hvis brugerne har mistet tilliden til systemet efter et problematisk testforløb?

Den slags forhold kan være vanskelige at udlede af testmetrikker alene.

Her er der brug for en erfaren testmanager, der tør stille spørgsmålstegn ved konklusionerne – også når de kommer fra en avanceret AI-model.

Human touch er ikke en begrænsning – det er en forudsætning

Jeg tror ikke på en fremtid, hvor AI fuldstændig overtager testmanagement. Jeg tror derimod på en fremtid, hvor de dygtigste testmanagers bliver dem, der formår at kombinere teknologiens muligheder med menneskelig dømmekraft.

For testmanagement handler om langt mere end planer, processer, testcases og rapporter.

Det handler også om mennesker.

Det handler om at skabe tillid, forstå bekymringer, håndtere konflikter, kommunikere usikkerhed og træffe beslutninger på et ufuldstændigt grundlag.

En testmanager skal eksempelvis kunne mærke, når en projektgruppe ikke længere har tillid til leverandørens leverancer. Vedkommende skal kunne forstå, hvorfor forretningen er skeptisk over for testresultaterne, og hvorfor en teknisk korrekt løsning ikke nødvendigvis opleves som en god løsning af brugerne.

AI kan hjælpe os med at analysere sådanne situationer, hvis vi giver den det nødvendige grundlag.

Men den menneskelige dialog, forståelsen af konteksten og evnen til at skabe fælles ejerskab kan ikke blot erstattes af en algoritme.

For mig handler human touch derfor ikke kun om at kontrollere AI-genererede resultater. Det handler om at fastholde mennesket som den, der forstår sammenhængen, udfordrer antagelserne og tager ansvar.

Fra testmanager til kritisk kvalitetsrådgiver

Jeg ser også AI som en mulighed for at udvikle selve testmanagerrollen.

I mange organisationer bruger testmanagers fortsat betydelig tid på administrative og dokumentationsmæssige opgaver. Vi udarbejder statusrapporter, sammenfatter testresultater, opdaterer planer og følger op på aktiviteter.

Det er nødvendige opgaver, men ikke nødvendigvis dér, vi skaber den største værdi.

Hvis AI kan reducere tidsforbruget på disse aktiviteter, kan vi i stedet bruge mere tid på det, der virkelig kræver vores faglighed.

Vi kan arbejde mere målrettet med produktrisici, udfordre projektets kvalitetsforståelse, rådgive ledelsen om konsekvenserne af forskellige beslutninger og sikre, at testindsatsen faktisk understøtter forretningens behov.

Dermed kan AI være med til at flytte testmanageren fra primært at være koordinator og rapporteringsansvarlig til i endnu højere grad at være strategisk kvalitetsrådgiver.

Men det kræver, at vi ikke blot bruger den frigjorte tid til at producere endnu flere dokumenter.

Vi skal bruge den til at skabe bedre beslutninger.

Kritisk sans skal være en del af vores AI-kompetence

Jeg mener, at vi fremover skal stille større krav til testmanagerens kompetencer inden for AI.

Det er ikke tilstrækkeligt at kunne formulere gode prompts.

Vi skal også kunne vurdere kvaliteten af AI's output, forstå teknologiens begrænsninger og gennemskue, hvornår et svar bygger på dokumenterede oplysninger, og hvornår det bygger på antagelser.

Det betyder blandt andet, at vi skal kunne:

• Udfordre AI's anbefalinger og efterspørge dokumentation.

• Kontrollere, om analyser og konklusioner bygger på korrekte og tilstrækkelige data.

• Identificere manglende kontekst, bias og usikre antagelser.

• Vurdere, om AI's forslag understøtter projektets reelle risici og kvalitetsmål.

• Sikre, at fortrolige oplysninger og persondata håndteres forsvarligt.

• Fastholde et tydeligt menneskeligt ansvar for væsentlige kvalitetsbeslutninger.

Særligt det sidste finder jeg vigtigt.

Vi må aldrig ende i en situation, hvor en kritisk beslutning begrundes med, at "det var det, AI anbefalede".

En anbefaling fra AI er ikke dokumentation for, at beslutningen er korrekt.

Og en flot formuleret konklusion er ikke nødvendigvis en velunderbygget konklusion.

Vi skal også turde være uenige med AI

Noget af det, jeg personligt finder mest værdifuldt ved AI, er muligheden for at anvende teknologien som en kritisk sparringspartner.

Men det kræver, at vi bruger den rigtigt.

Hvis vi alene beder AI om at bekræfte vores eksisterende teststrategi, risikovurdering eller beslutning, risikerer vi blot at få vores egne antagelser serveret tilbage i en mere overbevisende formulering.

I stedet bør vi aktivt bede AI om at udfordre os.

Hvilke svagheder er der i vores teststrategi? Hvilke risici har vi overset? Hvilke argumenter taler imod vores anbefaling? Hvilke yderligere oplysninger bør vi indhente, før vi træffer en beslutning?

På den måde kan AI være med til at styrke vores kritiske tænkning frem for at svække den.

Men vi skal også selv være parate til at sige: "Det er jeg ikke enig i."

For AI skal ikke være den autoritet, vi retter os efter. Den skal være den sparringspartner, vi tør udfordre.

Min tilgang: AI som copilot – aldrig som ukritisk autopilot

Jeg er overbevist om, at AI kommer til at spille en stadig større rolle inden for testmanagement.

Og det synes jeg grundlæggende er positivt.

Vi skal eksperimentere med teknologien, udvikle vores kompetencer og finde de områder, hvor AI reelt kan forbedre kvaliteten og effektiviteten af vores arbejde.

Men vi skal gøre det med åbne øjne.

Vi skal ikke anvende AI, blot fordi vi kan. Vi skal anvende AI, når det giver mening, og når vi kan sandsynliggøre, at det skaber værdi.

Og vi skal huske, at selv den mest avancerede AI-model ikke fritager os for at tænke selv.

For mig er den ideelle tilgang derfor ikke AI i stedet for testmanageren, men AI sammen med testmanageren.

AI kan analysere. AI kan foreslå. AI kan udfordre. AI kan effektivisere.

Men det er stadig testmanageren, der skal forstå konteksten, vurdere risiciene, skabe tillid og stå på mål for sine anbefalinger.

Afslutning – teknologien skal styrke vores faglighed, ikke erstatte den

Jeg ser et stort potentiale i AI, og jeg glæder mig til at følge udviklingen og selv være en del af den.

Men min begejstring er ledsaget af en sund portion skepsis.

Ikke over for teknologien i sig selv, men over for risikoen for, at vi som fagpersoner bliver for ukritiske i vores anvendelse af den.

Måske bliver en af fremtidens vigtigste kompetencer for en testmanager derfor ikke at kunne anvende AI, men at vide, hvornår man skal stole på AI, hvornår man skal udfordre den, og hvornår man skal lade sin egen faglige dømmekraft veje tungere.

For i sidste ende handler testmanagement ikke om at producere flest mulige testplaner, rapporter eller analyser.

Det handler om at skabe grundlaget for kvalificerede beslutninger om kvalitet og risiko.

Og det ansvar kan vi ikke outsource til AI.

Min konklusion er enkel: Brug AI offensivt, men tænk kritisk. Lad teknologien gøre os mere effektive – uden at vi mister det menneskelige perspektiv, der gør os til dygtige testmanagers.

Agentic AI i testmanagement – hvor meget bør vi overlade til AI?

AI i softwaretest er ikke længere kun et spørgsmål om at generere testcases eller automatiseringskode.

Vi bevæger os mod Agentic AI – AI-agenter, der ikke blot besvarer spørgsmål, men selv kan analysere situationer, planlægge aktiviteter, anvende værktøjer, udføre handlinger og tilpasse deres næste skridt.

Inden for testmanagement kan det betyde, at en AI-agent kan:

• analysere kodeændringer

• identificere risikoområder

• prioritere regressionstest

• generere testdesign

• gennemføre tests

• analysere fejl

• foreslå rodårsager

• anbefale næste handling.

Det centrale spørgsmål bliver derfor ikke længere:

“Hvordan kan AI hjælpe med test?”

men:

“Hvor meget af testmanagement kan vi delegere til en AI-agent – og hvad bør fortsat være et menneskeligt ansvar?”

Fra automatisering til autonomi

Traditionel testautomatisering udfører noget, mennesker allerede har besluttet.

Agentic AI kan i stigende grad selv beslutte:

• Hvad skal testes?
• Hvornår?
• Hvordan?
• Hvad betyder resultatet?
• Hvad bør næste handling være?

Det er en væsentlig forskel.

Vi automatiserer ikke længere kun aktiviteter.

Vi begynder også at automatisere beslutninger.

Det er netop her, Agentic AI bliver et testmanagement-emne og ikke blot endnu en testteknologi.

Delegering bør være risikobaseret

At en AI-agent teknisk kan træffe en beslutning betyder ikke nødvendigvis, at den bør have mandat til det.

Et godt princip er derfor:

Jo større konsekvensen af en forkert beslutning er, desto større bør den menneskelige kontrol være.

En agent kan eksempelvis med relativt lav risiko:

• gruppere testfejl

• foreslå ekstra tests

• analysere logs

• identificere påvirkede komponenter.

Men beslutninger som:

• at reducere testomfanget

• at ignorere en alvorlig defekt

• at ændre en quality gate

• at acceptere residual risiko

• at anbefale eller godkende produktionsrelease

kræver et langt højere kontrolniveau.

Det vigtigste spørgsmål er derfor ikke:

“Hvor intelligent er agenten?”

men:

“Hvad sker der, hvis agenten tager fejl?”

Human-in-the-loop skal designes bevidst

Det er ikke nok blot at sige, at “et menneske skal være involveret”.

Der bør skelnes mellem forskellige kontrolformer:

Human-in-the-loop: mennesket skal godkende handlingen.

Human-on-the-loop: agenten handler, men mennesket overvåger og kan stoppe den.

Human-over-the-loop: mennesket fastlægger politikker, guardrails og eskalationsregler.

Lavrisikoaktiviteter kan ofte automatiseres langt mere end beslutninger med stor forretningsmæssig konsekvens.

Derfor bør autonomi designes efter risiko.

Hvem tester testagenten?

Hvis en AI-agent skal være med til at skabe evidens om produktets kvalitet, skal organisationen samtidig have evidens for agentens egen kvalitet.

Det betyder, at vi bør kunne måle og overvåge blandt andet:

• hvor ofte agenten træffer korrekte beslutninger

• false positives og false negatives

• om den eskalerer på de rigtige tidspunkter

• hvilke data den anvender

• hvilke handlinger den foretager

• om dens adfærd ændrer sig over tid.

Det er ikke nok, at agentens output ser overbevisende ud.

Vi skal kunne stole på processen bag handlingerne.

Auditability bliver vigtigere end perfekte forklaringer

I praksis er det måske mindre vigtigt, om en agent kan forklare sin “tankegang”, og mere vigtigt, om vi kan rekonstruere dens handlinger.

Vi bør kunne se:

• Hvad observerede den?
• Hvilke data anvendte den?
• Hvilke værktøjer brugte den?
• Hvad besluttede den?
• Hvad udførte den?
• Hvornår eskalerede den?

Det gør revisionsspor til en central del af Agentic AI governance.

Observability viser retningen

Udviklingen inden for observability og IT operations giver et godt billede af, hvor testmanagement kan bevæge sig hen.

Vi går fra:

Detect → Alert → Human investigates

mod:

Detect → Analyze → Decide → Act → Verify

Noget tilsvarende kan ske i test:

Change → Risk analysis → Test → Result analysis → Action

I stedet for at mennesker manuelt orkestrerer hvert trin, kan en agent udføre store dele af kæden.

Testmanagement bliver dermed mere kontinuerligt og tættere integreret med CI/CD, observability og drift.

Testmanagerens rolle ændrer sig

Agentic AI behøver ikke gøre testmanageren mindre relevant.

Men den kan gøre dele af den traditionelle rolle mindre værdifulde.

Aktiviteter som:

• fordeling af testarbejde

• opfølgning på execution

• manuel sammenstilling af resultater

• statusrapportering

kan i stigende grad automatiseres.

Testmanagerens værdi flytter derfor mod:

• risikostyring
• governance
• kvalitetsevidens
• beslutningsstøtte
• orkestrering af mennesker og AI-agenter.

Fremtidens testmanager bliver måske mindre leder af testaktiviteter og mere Quality Orchestrator.

Hvad bør aldrig delegeres fuldt ud?

Der findes beslutninger, hvor det menneskelige ansvar bør være tydeligt.

Det gælder især:

Accept af væsentlig forretningsrisiko.

AI kan analysere og anbefale, men den relevante risikoejer bør acceptere risikoen.

Etiske og værdibaserede beslutninger.

AI kan levere information, men organisationen bør eje værdierne.

Fastlæggelse af kvalitetspolitik.

AI kan hjælpe med at håndhæve politikken, men bør ikke definere den alene.

Ansvarlighed.

En organisation bør aldrig kunne forklare en kritisk beslutning med:

“AI-systemet besluttede det.”

Man kan delegere handlinger.

Man kan ikke delegere ansvar.

Governance of Autonomy

En central fremtidig testmanagement-disciplin bliver derfor styring af autonomi.

For hver agent bør organisationen definere:

• formål

• scope

• dataadgang

• værktøjsadgang

• beslutningsmandat

• guardrails

• eskalationsregler

• audit trail

• overvågning

• mulighed for at stoppe agenten.

Det er sandsynligvis her, testmanagerrollen bliver mest interessant.

Ikke som den person, der følger alle testcases.

Men som den person, der sikrer, at autonome kvalitetssystemer opererer inden for kontrollerede og risikobaserede rammer.

Den vigtigste pointe

Agentic AI ændrer softwaretest, fordi vi bevæger os fra:

AI, der hjælper os med at udføre testarbejde

til:

AI, der selv begynder at træffe testbeslutninger.

Derfor bliver fremtidens centrale spørgsmål ikke:

“Hvor meget kan vi automatisere?”

men:

“Hvad kan vi trygt delegere, hvad skal vi kontrollere, og hvad skal vi fortsat selv tage ansvar for?”

Det er sandsynligvis en af de vigtigste ledelsesdiskussioner inden for testmanagement de kommende år.

Testmanageren som strategisk risikorådgiver – fra teststatus til beslutningsstøtte

I mange organisationer bliver testmanageren stadig først og fremmest betragtet som den person, der har ansvaret for at få testen gennemført. Testplanen skal udarbejdes, testcases skal være klar, testmiljøet skal fungere, defekter skal håndteres, og fremdriften skal rapporteres.

Når releasedatoen nærmer sig, kommer det velkendte spørgsmål:

“Er testen færdig?”

Det lyder som et rimeligt spørgsmål. Problemet er, at det ofte er det forkerte spørgsmål.

For hvad betyder “færdig”?

At alle planlagte testcases er udført? At 98 procent er bestået? At der ikke er åbne kritiske defekter? At exit-kriterierne er opfyldt?

Ingen af disse oplysninger fortæller i sig selv ledelsen, om det er forsvarligt at sætte løsningen i produktion.

Et langt mere interessant spørgsmål er derfor:

“Har vi tilstrækkelig evidens til at acceptere den resterende risiko?”

Forskellen mellem de to spørgsmål kan virke lille. Men den repræsenterer efter min vurdering en fundamental ændring af testmanagerens rolle.

Testmanageren skal ikke blot styre test.

Testmanageren skal hjælpe organisationen med at forstå og træffe beslutninger om risiko.

Test har aldrig kun handlet om at finde fejl

Softwaretest bliver ofte beskrevet som en aktivitet, der skal identificere defekter. Det er naturligvis en vigtig del af test, men det er kun en del af formålet.

Test skaber også information.

Når vi gennemfører en test, producerer vi evidens om systemets kvalitet. Når testen består, får vi evidens for, at systemet under de givne testbetingelser opførte sig som forventet. Når testen fejler, får vi evidens for det modsatte.

Test reducerer dermed ikke automatisk risiko.

Test reducerer usikkerheden om risiko.

Det er en vigtig sondring.

Forestil dig eksempelvis et betalingssystem, hvor der er identificeret risiko for, at en dobbeltbetaling kan gennemføres under bestemte samtidighedsforhold.

Vi kan gennemføre omfattende test af scenariet.

Hvis alle test består, er risikoen ikke nødvendigvis væk.

Vi har derimod fået mere evidens for, at sandsynligheden for problemet er lavere, end vi måske oprindeligt vurderede.

Men testen kan have begrænsninger. Vi har måske ikke testet samme belastning som i produktion. Testdata kan være mindre komplekse. Produktionsarkitekturen kan være anderledes. Eller der kan eksistere kombinationer, vi ikke har afprøvet.

Der eksisterer derfor stadig en residual risiko.

Spørgsmålet er ikke, om risikoen er nul.

Spørgsmålet er, om organisationen er villig til at acceptere den.

Testmanageren ejer ikke risikoen

Her ligger samtidig en vigtig grænse for testmanagerens ansvar.

Testmanageren bør normalt ikke være den person, der accepterer forretningsrisikoen.

Det ansvar tilhører den relevante risikoejer – eksempelvis en Product Owner, systemejer, forretningsansvarlig, projektejer eller ledelse.

Testmanagerens opgave er noget andet:

At gøre risikoen synlig, forståelig og beslutningsbar.

Det betyder, at testmanageren skal kunne sige:

• Vi har identificeret disse væsentlige kvalitetsrisici.
• Vi har gennemført disse aktiviteter for at undersøge dem.
• Dette er den evidens, vi har opnået.
• Dette ved vi fortsat ikke.
• Dette er den resterende risiko.
• Og dette er vores vurdering af konsekvensen ved at acceptere den.

Herefter kan risikoejeren træffe beslutningen.

Det er væsentligt mere værdifuldt end blot at rapportere:

“Testen er 94 procent færdig.”

Fra teststatus til risikostatus

Traditionel testrapportering er ofte aktivitetsorienteret.

Vi rapporterer eksempelvis:

• 1.240 testcases planlagt

• 1.087 testcases udført

• 1.012 bestået

• 75 fejlet

• 37 åbne defekter

• 82 procent test completion.

Tallene kan være relevante for den daglige styring af testarbejdet.

Men forestil dig, at du sidder i en styregruppe og skal beslutte, om et system må gå i produktion.

Hvad betyder det egentlig, at 82 procent af testcasene er udført?

Det afhænger fuldstændigt af, hvilke 18 procent der mangler.

Hvis de resterende testcases vedrører kosmetiske problemer på sjældent anvendte administrationssider, kan risikoen være beskeden.

Hvis de vedrører betalinger, adgangskontrol, dataintegritet eller regulatoriske krav, kan situationen være en helt anden.

Derfor bør testmanagerens rapportering gradvist bevæge sig fra:

Testafslutning

til:

Riskdækning og residual risiko.

Det ændrer dialogen med ledelsen markant.

100 procent beståede tests betyder ikke nul risiko

En af de farligste illusioner i softwaretest er forestillingen om, at mange beståede testcases nødvendigvis betyder høj kvalitet.

Forestil dig følgende rapport:

2.846 testcases udført.
2.846 bestået.
0 kritiske defekter.

Det ser fantastisk ud.

• Men hvad hvis ingen har testet recovery efter tab af netværksforbindelse?
• Hvad hvis adgangskontrollen kun er testet med normale brugerroller?
• Hvad hvis integrationen til det vigtigste eksterne system ikke er belastningstestet?
• Hvad hvis de 2.846 testcases primært tester funktionalitet, hvor risikoen i forvejen var lav?

Så kan vi have 100 procent beståede tests og samtidig have en uacceptabel residual risiko.

Det illustrerer et centralt princip:

Antallet af gennemførte tests er ikke det samme som mængden eller kvaliteten af evidens.

Evidens bliver testmanagerens vigtigste produkt

Hvis testmanageren skal fungere som strategisk risikorådgiver, bør vi måske ændre vores opfattelse af, hvad testorganisationen producerer.

Det primære produkt er ikke testcases.

Det er heller ikke automatiserede scripts.

Og det er ikke defektrapporter.

Det vigtigste produkt er:

beslutningsrelevant kvalitetsevidens.

Evidensen kan komme fra mange forskellige kilder:

• Funktionelle tests

• Automatiserede regressionstests

• Performance- og belastningstests

• Sikkerhedstest

• Statisk analyse

• Kodedækning

• Reviews

• Penetrationstest

• Brugervenlighedstest

• Produktionsdata

• Observationer

• Tidligere hændelser

• Defektdata

• Leverandørtest

• Compliance-kontroller.

Testmanagerens opgave bliver derfor også at samle forskellige typer evidens og omsætte dem til et samlet risikobillede.

Det er tættere på risk intelligence end traditionel testadministration.

Fra testplan til risikohypotese

Det påvirker også måden, vi planlægger test på.

Traditionelt tager vi ofte udgangspunkt i spørgsmålet:

“Hvad skal vi teste?”

En mere risikoorienteret tilgang starter tidligere:

“Hvad er vi bange for kan gå galt?”

Derefter:

“Hvilken evidens skal vi bruge for at reducere usikkerheden omkring denne risiko?”

Det kan illustreres som en simpel kæde:

Forretningsmål → Risiko → Informationsbehov → Test/evidens → Residual risiko → Beslutning

Forestil dig eksempelvis en netbank.

Et forretningsmål kunne være:

Kunder skal kunne gennemføre betalinger korrekt og sikkert.

En kritisk risiko kunne være:

En kunde kan gennemføre en betaling fra en konto, som kunden ikke har adgang til.

Informationsbehovet bliver derfor:

Har vi tilstrækkelig evidens for, at autorisationsmekanismerne forhindrer dette på tværs af relevante roller, kontotyper, API'er og brugergrænseflader?

Først derefter vælger vi testtilgangen.

Test bliver dermed et middel til at producere den nødvendige evidens – ikke et mål i sig selv.

Det kræver en anden type testmanager

Denne udvikling ændrer kompetenceprofilen.

Den klassiske testmanager har typisk været stærk inden for testplanlægning, estimering, testprocesser, defekthåndtering, testværktøjer, rapportering og koordinering.

Disse kompetencer forsvinder ikke.

Men de er ikke længere tilstrækkelige.

Den strategiske testmanager skal også forstå:

Forretningen.
Hvilke produkter, services og processer skaber værdi? Hvad kan organisationen ikke tåle går galt?

Risiko.
Hvordan identificeres, analyseres, behandles og accepteres risici?

Økonomi.
Hvad er den potentielle økonomiske konsekvens af kvalitetsproblemer?

Compliance.
Hvilke regulatoriske eller kontraktuelle krav påvirker kvalitetsbeslutningerne?

Teknologi.
Hvor findes de væsentligste arkitektoniske afhængigheder og failure modes?

Data.
Hvilken evidens understøtter vores vurdering – og hvor stærk er den?

Kommunikation.
Hvordan omsættes kompleks teknisk information til beslutningsrelevant information?

Det sidste punkt er måske det vigtigste.

En strategisk testmanager skal kunne kommunikere med både udviklere og direktion – men ikke nødvendigvis på samme måde.

Stop med at tale testsprog til ledelsen

Testorganisationer har ofte udviklet deres eget sprog:

testcases, test execution, pass rate, defect severity, coverage, regression packs, environments og test completion.

Problemet er, at ledelsen sjældent træffer beslutninger ud fra disse begreber.

Ledelsen tænker snarere i:

• forretningsmæssig konsekvens

• økonomi

• kunder

• omdømme

• compliance

• driftsstabilitet

• strategiske mål

• sandsynlighed og konsekvens.

Testmanagerens opgave bliver derfor at oversætte.

Ikke:

“Regressionstesten er 87 procent gennemført, og vi har seks severity 2-defekter.”

Men eksempelvis:

“Vi har høj sikkerhed for de centrale betalingsflows, men mangler fortsat evidens for systemets stabilitet under spidsbelastning. Hvis vi releaser nu, accepterer vi derfor en forhøjet risiko for længere svartider eller utilgængelighed på de travleste tidspunkter.”

Den tekniske information er ikke væk.

Den er oversat til noget, beslutningstageren kan handle på.

Testmanageren skal også kommunikere usikkerhed

Det kræver samtidig, at vi bliver bedre til at sige:

“Det ved vi ikke.”

Det kan føles ubehageligt.

Testorganisationer bliver ofte forventet at give klare svar:

Er systemet testet?

Er kvaliteten god?

Kan vi release?

Men test kan sjældent bevise, at et komplekst system er fejlfrit.

En professionel risikorådgiver skjuler derfor ikke usikkerhed.

Tværtimod.

En god kvalitetsrapport bør kunne skelne mellem:

Det ved vi.

Det har vi evidens for.

Det antager vi.

Det har vi ikke undersøgt.

Det ved vi endnu ikke.

Det giver en langt mere moden beslutningsproces.

AI gør denne rolle endnu vigtigere

AI vil efter min vurdering accelerere denne udvikling markant.

Generativ AI kan allerede hjælpe med at producere testcases, automatiseringskode, testdata, analyser og dokumentation.

Agentiske AI-løsninger vil kunne overtage endnu større dele af det operationelle testarbejde.

Det betyder ikke nødvendigvis, at testmanageren bliver mindre relevant.

Men det betyder, at testmanageren bliver mindre værdifuld, hvis rollen primært består i at administrere testaktiviteter.

Når AI kan generere tusindvis af testcases, bliver spørgsmålet ikke:

“Hvor mange tests kan vi producere?”

Det bliver:

“Hvilken evidens har vi brug for?”

Og endnu vigtigere:

“Kan vi stole på evidensen?”

AI kan eksempelvis generere 5.000 testcases.

Det ser imponerende ud.

Men hvis de bygger på de samme forkerte antagelser, overser den samme forretningsrisiko eller reproducerer de samme blinde vinkler, har vi blot automatiseret falsk tryghed.

Derfor kan AI paradoksalt nok gøre den strategiske testmanager mere relevant.

Releasebeslutningen bør være en risikobeslutning

I nogle organisationer ender testmanageren stadig med at skulle give et simpelt svar:

GO eller NO-GO?

Det kan være problematisk.

Testmanageren kan og bør levere en faglig anbefaling. Men selve accepten af en væsentlig forretningsrisiko bør ligge hos den relevante risikoejer.

En mere moden releasebeslutning kunne derfor bestå af:

Risiko: Hvad kan gå galt?

Eksponering: Hvem eller hvad påvirkes?

Evidens: Hvad har vi gjort for at undersøge risikoen?

Resultat: Hvad viser evidensen?

Usikkerhed: Hvad ved vi stadig ikke?

Residual risiko: Hvilken risiko eksisterer efter vores kvalitetsaktiviteter?

Mitigering: Hvilke kompenserende kontroller findes?

Anbefaling: Hvad anbefaler test-/quality-funktionen?

Beslutning: Accepterer risikoejeren den resterende risiko?

Det giver samtidig langt bedre sporbarhed.

Hvis noget efterfølgende går galt, kan organisationen se, hvilken information der var tilgængelig, hvilke antagelser beslutningen byggede på, og hvem der accepterede risikoen.

Fra Quality Assurance til Quality Intelligence

Det interessante er derfor, om selve begrebet Quality Assurance efterhånden bliver for snævert.

Fremtidens testmanagement handler måske mere om Quality Intelligence.

Quality Intelligence betyder i denne sammenhæng evnen til løbende at kombinere information om:

produkt + risiko + test + defekter + kode + drift + kunder + forretning

og omsætte den til beslutningsstøtte.

Her får testmanageren en interessant position.

Testmanageren befinder sig allerede i krydsfeltet mellem:

forretning ↔ udvikling ↔ drift ↔ leverandører ↔ risiko ↔ kvalitet

Det er faktisk en ret unik organisatorisk position.

Men værdien realiseres kun, hvis testmanageren løfter blikket fra testplanen.

Fem spørgsmål den strategiske testmanager bør stille

Hvis man ønsker at bevæge sin rolle i denne retning, kan man begynde med fem spørgsmål:

1. Hvilke forretningsrisici forsøger vores test faktisk at reducere usikkerheden omkring?

Hvis svaret ikke er tydeligt, er der risiko for, at testen er aktivitetsdrevet frem for risikodrevet.

2. Hvilken evidens har beslutningstagerne brug for?

Ikke hvilken rapport testværktøjet kan generere – men hvilken information der faktisk er nødvendig for beslutningen.

3. Hvad ved vi ikke?

Ukendt risiko og manglende evidens bør være synligt.

4. Hvem ejer den resterende risiko?

Hvis ingen eksplicit ejer den, bliver testmanageren let den implicitte risikoejer.

5. Hvordan kommunikerer vi risikoen, så den kan forstås uden testfaglig baggrund?

Hvis ledelsen skal forstå 14 testmetrics for at kunne træffe beslutningen, har vi sandsynligvis ikke oversat informationen godt nok.

En ny definition af “testen er færdig”

Måske skal vi derfor også udfordre selve idéen om, at test bliver “færdig”.

Et system kan have gennemført alle planlagte tests og stadig være for risikabelt til produktion.

Omvendt kan det i nogle situationer være rationelt at release et system, selvom alle planlagte tests ikke er gennemført.

Det afhænger af risikoen.

Derfor bør testafslutning ikke alene forstås som:

“Vi har udført det, vi planlagde.”

En mere moden definition kunne være:

“Vi har produceret tilstrækkelig og troværdig evidens til, at den ansvarlige risikoejer kan træffe en informeret beslutning om den resterende risiko.”

Det er efter min vurdering en langt stærkere definition af værdien af moderne testmanagement.

Testmanageren forsvinder ikke – men rollen ændrer karakter

Der bliver løbende diskuteret, om AI, DevOps, Quality Engineering og selvstyrende teams gør testmanageren overflødig.

Det kan de måske gøre, hvis testmanagerens primære funktion er at koordinere testcases, indkalde til defektmøder og producere statusrapporter.

Men der er stadig behov for mennesker, som kan forbinde teknisk kvalitet med forretningsmæssig risiko.

Måske mere end nogensinde.

Komplekse distribuerede systemer, cloud, cybersikkerhed, regulatoriske krav, tredjepartsleverandører, AI-systemer og stadig hurtigere releases gør kvalitetsbeslutninger vanskeligere – ikke lettere.

Det skaber plads til en anden type testmanager.

Ikke testmanageren som testadministrator.

Men testmanageren som strategisk risikorådgiver.

En person, der kan udfordre organisationen med spørgsmål som:

Hvad kan gå galt?

Hvor stor er konsekvensen?

Hvad ved vi faktisk?

Hvor stærk er vores evidens?

Hvad ved vi ikke?

Hvilken risiko er tilbage?

Hvem accepterer den?

Og måske vigtigst:

Er den beslutning, vi er ved at træffe, faktisk understøttet af tilstrækkelig evidens?

Det er en væsentligt mere strategisk rolle end at kunne svare på, om testen er færdig.

For det egentlige mål med test er ikke at gennemføre test.

Det er at give organisationen bedre grundlag for at træffe beslutninger under usikkerhed.

Artikler om test og testmanagement

Jeg har efterhånden skrevet en del artikler om test og testmanagement - du finder her en oversigt pr. 31/8 2026:

Emnerne er:

- AI genererede testcases - produktivitetsgevinst eller falsk tryghed?

- AI gør ikke en umoden testorganisation moden

- Proaktiv testmanagement - Den overset nøgle til stabile leverancer

- Manuel test i 2026 - Strategisk relevans i en automatiseret æra

- AI-Enabled testmanagement

- Metamorfisk test

- Konverteringstest - en guide for testmanagement

- Test af AI-baserede systemer - teknikker, udfordringer og retningslinjer

- Fra QA Gatekeeper til kvalitetspartner

- Fra klassisk testmanager til Quality Coach

- DORA-Forordningen - Implikationer for softwaretest i finanssektoren

- Fra klassisk til moderne - testteknikker der gør en forskel i 2025 - Del 2

- Fra klassisk til moderne - testteknikker der gør en forskel i 2025 - Del 1

- Testmanager i 2025: Er du klar til fremtidens krav?

Artiklerne kan læses på Q Nations LinkedIn profil eller på hjemmesiden: Blog 3 — Q NATION A/S

CAIO – Den nye lederrolle, som testledere bør holde øje med

I takt med at kunstig intelligens bevæger sig fra eksperimenter og pilotprojekter til at blive en integreret del af virksomheders forretningsmodeller, ser vi også nye roller opstå i ledelseslagene. En af de mest interessante er rollen som Chief Artificial Intelligence Officer (CAIO).

For få år siden var det primært CIO'er, CTO'er og CDO'er, der havde ansvaret for virksomhedens digitale udvikling. Men AI har vist sig at være mere end blot endnu en teknologi. Kunstig intelligens påvirker måden, vi træffer beslutninger på, udvikler produkter, interagerer med kunder og automatiserer arbejdsprocesser. Derfor vælger flere organisationer nu at placere det overordnede ansvar for AI hos en dedikeret leder – en CAIO.

CAIO'ens opgave er ikke blot at sikre, at virksomheden anvender AI. Rollen handler i lige så høj grad om at sikre, at AI anvendes ansvarligt, sikkert og med dokumenteret forretningsværdi. Det kræver en balance mellem innovation, governance, risikostyring og compliance. Med EU AI Act og stigende regulatoriske krav bliver dette ansvar kun mere centralt i de kommende år.

For mange testledere kan CAIO-rollen umiddelbart virke langt væk fra den traditionelle testverden. Men ser man nærmere på udviklingen, er der faktisk en tæt forbindelse mellem de to områder.

Historisk har testmanagement primært fokuseret på at verificere og validere softwareløsninger. Vi har arbejdet med krav, testdesign, fejlrapportering, risikostyring og kvalitetssikring af systemer. Når AI bliver en del af løsningen, ændrer selve kvalitetsbegrebet sig imidlertid markant.

I traditionelle systemer kan vi ofte afgøre, om et resultat er korrekt eller forkert. En beregning giver enten det rigtige svar eller ikke. En funktion opfører sig enten som specificeret eller afviger fra kravene. Med AI er virkeligheden langt mere kompleks.

En generativ AI-model kan producere forskellige svar på det samme spørgsmål. En machine learning-model kan levere statistisk korrekte resultater, men samtidig introducere bias eller uønskede mønstre. En beslutningsmodel kan fungere korrekt i dag, men ændre adfærd over tid som følge af ændringer i data eller omgivelser.

Derfor bliver spørgsmål som "Virker systemet?" gradvist erstattet af spørgsmål som "Kan vi stole på systemet?", "Er beslutningerne retfærdige?" og "Er risikoen acceptabel?". Disse spørgsmål ligger i krydsfeltet mellem CAIO'ens strategiske ansvar og testorganisationens kvalitetsansvar.

I mange organisationer vil CAIO'en derfor få behov for en stærk partner i testledelsen. Hvor CAIO'en fastlægger AI-strategien og governance-modellen, vil testmanageren være med til at omsætte disse principper til konkrete kvalitetssikringsaktiviteter. Det gælder blandt andet etablering af teststrategier for AI-løsninger, dokumentation af risici, validering af modeller og sikring af compliance med både interne og eksterne krav.

Dette indebærer samtidig en udvikling af testfaget. Fremtidens testorganisation skal ikke alene kunne teste software. Den skal også kunne teste AI.

Det betyder blandt andet, at testteams skal opbygge kompetencer inden for modelvalidering, datakvalitet, bias-analyse og robusthedstest. Når virksomheder implementerer generative AI-løsninger, bliver områder som hallucinationstest, prompt testing og sikkerhedstest lige så relevante som klassiske funktionelle testcases.

Samtidig bliver overvågning efter idriftsættelse vigtigere end nogensinde før. Traditionelle systemer ændrer normalt ikke adfærd uden nye releases. AI-systemer kan derimod gradvist ændre deres performance som følge af dataændringer eller modeldrift. Derfor bliver kvalitetssikring i stigende grad en kontinuerlig aktivitet fremfor en fase, der afsluttes før produktion.

Denne udvikling åbner også nye muligheder for testledere. Mange af de kompetencer, som allerede findes inden for moderne testmanagement – risikobaseret test, kvalitetssikring, governance og måling – er direkte anvendelige i arbejdet med AI. Faktisk kan man argumentere for, at testledere er blandt de bedst placerede kandidater til at tage lederskab inden for det voksende område, der ofte betegnes som AI Assurance.

På samme måde som informationssikkerhed gennem de seneste årtier har udviklet sig til et selvstændigt fagområde med egne ledelsesroller, standarder og processer, ser vi nu AI Assurance udvikle sig som et nyt disciplinområde. Her vil samarbejdet mellem CAIO, CISO, CIO og testledelsen blive afgørende.

For testmanageren betyder det, at fremtidens kompetenceprofil sandsynligvis kommer til at omfatte langt mere end klassisk testledelse. Kendskab til AI-governance, EU AI Act, ISO/IEC 42001, datakvalitet og AI-risikostyring bliver stadig vigtigere. Samtidig vil evnen til at dokumentere og skabe tillid til AI-systemer blive en strategisk nøglekompetence.

CAIO-rollen er derfor ikke blot endnu en titel i organisationens ledelsesstruktur. Den repræsenterer et skifte i måden, virksomheder tænker kvalitet, risiko og teknologi på. For testledere er det en udvikling, der bør vække interesse. Hvor testmanagement tidligere handlede om at sikre, at systemet fungerede korrekt, kommer fremtidens fokus i stigende grad til at handle om at sikre, at kunstig intelligens opfører sig ansvarligt, pålideligt og troværdigt.

For testledere handler forberedelsen først og fremmest om at udvide kvalitetsbegrebet. Det er ikke længere tilstrækkeligt kun at tænke i funktionelle test, regressionstest og klassiske acceptkriterier. Når AI indgår i løsningen, skal testlederen også kunne forholde sig til datakvalitet, modeladfærd, bias, forklarbarhed, robusthed og løbende overvågning efter idriftsættelse. Det kræver ikke nødvendigvis, at testlederen bliver data scientist, men det kræver en forståelse for, hvilke risici AI introducerer, og hvordan disse risici kan omsættes til konkrete test- og kontrolaktiviteter.

En god start er at etablere et fælles sprog mellem testorganisationen, forretningen, data-specialisterne og den kommende eller eksisterende CAIO-funktion. Testlederen bør kunne forklare, hvordan kendte discipliner som risikobaseret test, sporbarhed, testdokumentation og kvalitetsrapportering kan anvendes i AI-sammenhæng. Samtidig bør testlederen være nysgerrig på nye teknikker som prompt testing, hallucinationstest, bias testing og model drift-overvågning.

Det er også vigtigt, at testledere begynder at tænke mere i governance og evidens. En CAIO vil typisk have behov for dokumentation, der viser, at AI-løsninger er vurderet, testet og kontrolleret på en systematisk måde. Her kan testmanagement bidrage stærkt med teststrategier, risikovurderinger, testresultater, afvigelsesrapporter og beslutningsgrundlag for release eller fortsat drift.

Endelig bør testledere se CAIO-rollen som en mulighed for at løfte testområdet tættere på den strategiske ledelse. AI skaber nye kvalitetsrisici, men også nye muligheder for testfaget. De testledere, der formår at kombinere klassisk testmanagement med AI Assurance, compliance og forretningsforståelse, vil stå stærkt i de kommende år. De kan blive nøglepersoner i arbejdet med at sikre, at organisationens AI-løsninger ikke blot er teknisk imponerende, men også pålidelige, ansvarlige og værdiskabende.

Og netop her mødes CAIO'en og testmanageren.

Boganmeldelse: Kvalitative undersøgelser med AI

 

Bog: Kvalitative unsersøgelser med AI

Af: Charlotte Albrechtsen og Tine Wirenfeldt Jensen

Forlag: Samfundslitteratur

Artificial Intelligence er ikke længere et eksperimenterende nicheområde for teknologer og udviklere. AI er begyndt at flytte ind i de dele af organisationen, hvor analyse, vurdering og beslutningsstøtte tidligere primært var menneskelige discipliner. Det gælder også inden for kvalitetsarbejde og testmanagement. Derfor rammer Kvalitative undersøgelser med AI af Charlotte Albrechtsen og Tine Wirenfeldt Jensen et både aktuelt og vigtigt emne.

Bogen beskæftiger sig med, hvordan generativ AI kan understøtte kvalitative undersøgelser og analysearbejde. Selvom målgruppen ikke specifikt er softwaretest eller QA-professionelle, er der overraskende mange perspektiver, som er direkte relevante for moderne test managers. Særligt i en tid, hvor testorganisationer arbejder med stadigt større datamængder, hurtigere releasecyklusser og et voksende behov for datadrevet beslutningsstøtte, bliver spørgsmålet om AI-understøttet analyse yderst relevant.

Noget af det mest positive ved bogen er dens pragmatiske tilgang. Forfatterne falder ikke i den klassiske fælde, hvor AI enten fremstilles som en revolutionerende erstatning for menneskelig ekspertise eller som en ukontrollerbar risiko. I stedet beskrives AI som et værktøj, der kan understøtte refleksion, strukturering og analyse — men stadig kræver menneskelig dømmekraft. Det er en tilgang, som harmonerer meget godt med moderne principper inden for test og kvalitetssikring, hvor automatisering og AI netop bør ses som støttefunktioner og ikke som erstatning for professionel vurdering.

Bogen lykkes særligt godt med at gøre AI konkret og operationel. Mange bøger om AI bliver hurtigt abstrakte eller teknologitunge, men her holdes fokus på det praktiske analysearbejde. Det gør indholdet tilgængeligt, også for ledere og specialister uden dyb teknisk AI-baggrund. For testmanagers er det interessant, fordi store dele af testledelse i virkeligheden består af kvalitative analyser: vurdering af risici, analyse af fejlmønstre, opsummering af retrospectives, stakeholderrapportering og prioritering af kvalitetsindsatser.

Netop her bliver bogen særligt relevant. Mange testorganisationer ligger inde med enorme mængder tekstbaseret viden i form af defects, incidents, supporthenvendelser, retrospectives og testnoter. Traditionelt har det været vanskeligt at analysere disse data systematisk, fordi arbejdet er tidskrævende og ofte manuelt. Bogen illustrerer flere måder, hvorpå AI kan hjælpe med at identificere mønstre, kategorisere observationer og skabe hurtigere overblik.

Det er især inden for fejlanalyse, at potentialet bliver tydeligt. Moderne test managers arbejder ikke kun med at registrere fejl, men i høj grad med at forstå, hvorfor fejl opstår, og hvilke organisatoriske eller tekniske mønstre der ligger bag. Her kan AI være et interessant supplement. Forestil dig eksempelvis en analyse af flere hundrede Jira-defects, incidentrapporter og retrospectives, hvor AI hjælper med at identificere tilbagevendende problemområder, typiske årsager eller risikoområder, som ellers ville være vanskelige at opdage manuelt. Bogen giver ikke færdige modeller til dette, men den inspirerer til netop denne type anvendelse.

Det samme gælder rapportering. Mange test managers bruger betydelig tid på at omsætte tekniske observationer til ledelsesinformation. Her kan AI hjælpe med at kondensere komplekse analyser, formulere executive summaries og skabe mere målrettet kommunikation til forskellige interessenter. I agile og DevOps-orienterede organisationer, hvor rapportering skal være hurtig, løbende og ofte datatung, kan denne type AI-understøttelse blive meget værdifuld.

Bogen er dog ikke uden svagheder. Set fra et testmanagement-perspektiv savnes der mere dybde omkring governance, kvalitetssikring og risiko ved brugen af AI. Forfatterne berører problemstillinger som bias og fejltolkninger, men emnet kunne med fordel være behandlet langt mere kritisk. I kvalitetskritiske miljøer er det ikke nok, at AI genererer plausible analyser — analyserne skal også kunne valideres, forklares og spores.

Dette er især vigtigt i forbindelse med root cause analysis og risikovurderinger. Hvis AI fejlagtigt identificerer mønstre eller overser kritiske sammenhænge, kan det påvirke både prioriteringer og beslutninger omkring releases og kvalitet. Her kunne bogen med fordel have inddraget flere principper fra klassisk kvalitetssikring og softwaretest, eksempelvis peer review, validering, confidence scoring eller sporbarhed mellem data og konklusioner.

Derudover mangler bogen efter min vurdering en egentlig modenhedsmodel for organisationers anvendelse af AI i analysearbejde. Mange virksomheder er stadig meget umodne i deres AI-anvendelse, og særligt inden for testmanagement er der store forskelle på, hvor langt organisationer er kommet. Her kunne bogen have været styrket af mere konkrete anbefalinger til trinvis implementering, governance-strukturer og organisatorisk readiness.

Disse kritikpunkter ændrer dog ikke ved, at bogen er både relevant og inspirerende. Dens største styrke er måske netop, at den får læseren til at reflektere over, hvordan analysearbejde kommer til at ændre sig i de kommende år. For test managers er dette særligt vigtigt. Testledelse handler i stigende grad ikke blot om koordinering af testaktiviteter, men om evnen til at analysere kvalitetsdata, identificere risici og understøtte hurtige beslutninger i komplekse organisationer. Her bliver AI sandsynligvis en naturlig del af værktøjskassen.

Kvalitative undersøgelser med AI er derfor ikke nødvendigvis en bog, man læser for at få en færdig metode eller en komplet manual. Den fungerer bedre som et refleksions- og inspirationsværk, der hjælper professionelle med at forstå mulighederne og begrænsningerne ved AI-understøttet analyse. For test managers og QA-ledere, der ønsker at arbejde mere strategisk med analyse, rapportering og organisatorisk læring, er bogen absolut værd at læse.

Måske er bogens vigtigste budskab i virkeligheden, at AI ikke først og fremmest handler om automatisering, men om augmentation — altså hvordan teknologien kan styrke menneskelig analyse og refleksion. Det er en vigtig pointe, særligt i kvalitets- og testdiscipliner, hvor dømmekraft, kontekstforståelse og kritisk tænkning fortsat vil være afgørende kompetencer.

AI-testmanageren – fremtidens helt

I mange år har testmanageren været den person, der stod mellem kaos og kontrol. Rollen har handlet om planer, koordinering, risikostyring, rapportering og den evige kamp for kvalitet i en verden, hvor deadlines næsten altid vinder over ambitioner. Men noget fundamentalt er ved at ændre sig.

Ikke bare i test.

Ikke bare i softwareudvikling.

Men i selve måden organisationer tænker kvalitet, beslutninger og ansvar på.

AI er ikke længere et eksperiment i periferien. Den er blevet en aktiv deltager i udviklingsprocessen. AI skriver kode, genererer testcases, analyserer logs, forudsiger fejl, optimerer pipelines og foreslår løsninger hurtigere, end mange teams kan følge med. Det betyder, at testmanagerens rolle enten kan blive marginaliseret — eller forvandlet til en af de vigtigste roller i fremtidens digitale organisation.

Og netop derfor bliver AI-testmanageren fremtidens helt.

Fra teststyring til intelligent kvalitetsledelse

Den klassiske testmanager har traditionelt været ansvarlig for koordinering af testaktiviteter. Fokus har været på testplaner, ressourcer, rapportering, estimering og kvalitetsoverblik. Men AI ændrer spillereglerne dramatisk.

Når AI kan generere tusindvis af testcases på få minutter, bliver udfordringen ikke længere mangel på test. Udfordringen bliver at forstå:

• hvilke tests der skaber reel værdi
• hvilke risici der er vigtigst
• hvilke beslutninger der er forsvarlige
• hvilke AI-resultater man kan stole på
• hvordan kvalitet styres i et miljø med autonome systemer

Det betyder, at testmanagerens værdi flytter sig fra administration til intelligens.

Fremtidens AI-testmanager bliver ikke den person, der manuelt organiserer alting. Rollen bliver i højere grad en strategisk kvalitetsleder, der orkestrerer mennesker, AI-systemer, data og risikobeslutninger i realtid.

Det er ikke mindre vigtigt.

Det er langt vigtigere.

AI gør ikke testmanageren irrelevant

En af de største misforståelser omkring AI er forestillingen om, at automatisering fjerner behovet for ledelse og menneskelig dømmekraft. Historien viser det modsatte.

Jo mere automatisering organisationer indfører, desto større bliver behovet for governance, kvalitetssikring og risikoforståelse.

AI kan være ekstremt effektiv til at generere output. Men AI forstår ikke nødvendigvis forretningens konsekvenser, regulatoriske krav, menneskelig adfærd eller organisatorisk risiko. Den kan foreslå tests, som ser imponerende ud, men som ikke adresserer de vigtigste risici. Den kan optimere mod forkerte mål. Den kan skabe falsk tryghed gennem enorme mængder data.

Her bliver AI-testmanageren afgørende.

Ikke som “kontrollør af AI”, men som den professionelle, der sikrer, at AI bruges ansvarligt, effektivt og strategisk.

Fremtidens testmanager bliver AI-dirigent

Mange taler om AI som et værktøj. Men i praksis bevæger vi os hurtigt mod et miljø, hvor AI fungerer som en digital medarbejder.

AI-agenter kan allerede:

• generere testdesign
• analysere krav
• identificere manglende coverage
• overvåge produktionsmiljøer
• prioritere fejl
• udføre root cause analysis
• skabe syntetiske testdata
• vedligeholde automatisering

I fremtiden vil mange teams arbejde sammen med flere specialiserede AI-agenter samtidigt.

Derfor bliver AI-testmanagerens rolle mindre operationel og mere orkestrerende. Rollen handler ikke længere kun om at styre mennesker, men også om at styre intelligente systemer.

Den moderne testmanager skal forstå:

• hvordan AI-modeller træffer beslutninger
• hvordan bias påvirker testresultater
• hvordan hallucinationer opdages
• hvordan AI-output valideres
• hvordan compliance og governance håndteres
• hvordan mennesker og AI samarbejder effektivt

Det er et markant kompetenceskifte.

Testmanagement bliver i stigende grad en disciplin inden for intelligent beslutningsledelse.

Kvalitet bliver et realtidsproblem

Traditionelt har test været organiseret i faser. Selv i agile miljøer tænker mange stadig i sekvenser: udvikling først, test bagefter.

AI accelererer alt.

Kode genereres hurtigere.
Deployments sker hurtigere.
Forandringer sker hurtigere.
Risici opstår hurtigere.

Dermed bliver kvalitet heller ikke længere noget, man “evaluerer til sidst”. Kvalitet bliver en kontinuerlig strøm af signaler, data og beslutninger.

AI-testmanageren bliver den person, der skal skabe mening i denne kompleksitet.

Forestil dig en organisation, hvor:

• AI overvåger produktionsrisici i realtid
• testcases genereres dynamisk
• fejlmønstre opdages automatisk
• releases vurderes kontinuerligt
• risikoniveauer ændrer sig fra time til time

I sådan et miljø bliver klassiske statusrapporter hurtigt irrelevante.

Fremtidens testmanager skal kunne arbejde med prediktive kvalitetsmodeller, observability, AI-baseret risikovurdering og datadrevet beslutningsstøtte.

Det kræver nye kompetencer — men giver også rollen en langt mere central position i organisationen.

Den menneskelige faktor bliver vigtigere, ikke mindre

Paradoksalt nok bliver menneskelige kompetencer mere værdifulde i takt med, at AI bliver bedre.

AI kan analysere mønstre.

Men den forstår ikke nødvendigvis mennesker.

Den forstår ikke frygten hos brugerne.
Den forstår ikke politiske spændinger i organisationer.
Den forstår ikke kulturel modstand.
Den forstår ikke etiske gråzoner.

AI-testmanageren bliver derfor brobygger mellem teknologi og mennesker.

Det handler ikke kun om teknik. Det handler om tillid.

Kan organisationen stole på AI?
Kan kunderne stole på løsningen?
Kan ledelsen stole på kvaliteten?
Kan compliance stole på beslutningerne?

Tillid bliver fremtidens vigtigste kvalitetsparameter.

Og her får testmanageren en ny strategisk betydning.

AI-testmanageren bliver organisationens risikoarkitekt

I mange organisationer bliver software mere autonomt. Systemer træffer selv beslutninger. AI-modeller ændrer sig over tid. Data påvirker adfærd dynamisk.

Det betyder, at traditionelle teststrategier ikke længere er tilstrækkelige.

Man kan ikke blot teste én gang og erklære systemet stabilt.

AI-systemer kræver kontinuerlig evaluering.

Derfor vil AI-testmanageren i stigende grad arbejde med:

• AI governance
• model validation
• data quality
• fairness og bias
• explainability
• compliance
• sikkerhed og robustness
• overvågning af driftssystemer

Det er ikke længere nok at spørge:
“Virker systemet?”

Man skal også spørge:
“Virker systemet ansvarligt?”
“Virker det stabilt over tid?”
“Virker det sikkert under uforudsete forhold?”
“Virker det etisk forsvarligt?”

Her bliver testmanageren central for virksomhedens samlede risikostyring.

Fremtidens helt er ikke den hurtigste

I AI-æraen bliver det fristende at optimere mod hastighed alene. Hurtigere releases. Hurtigere test. Hurtigere beslutninger.

Men historien viser, at teknologiske spring ofte skaber nye former for risiko.

Netop derfor bliver AI-testmanageren vigtig.

Ikke fordi rollen bremser innovation.

Men fordi rollen sikrer bæredygtig innovation.

Den organisation, der lykkes bedst med AI, bliver sandsynligvis ikke den, der automatiserer mest aggressivt. Det bliver den organisation, der bedst kombinerer:

• menneskelig dømmekraft
• intelligent automatisering
• ansvarlig governance
• datadrevet kvalitet
• kontinuerlig læring

AI-testmanageren bliver personen, der skaber denne balance.

Testfaget står foran sin største transformation

Mange brancher taler om AI som en revolution. For testfaget er det mere end det.

Det er et identitetsskifte.

Test går fra at være en støttefunktion til at blive en strategisk disciplin for tillid, risiko og beslutningskvalitet.

Det betyder også, at testprofessionelle skal udvikle sig.

Fremtidens testmanager skal forstå mere end testmetoder. Rollen kræver forståelse for:

• AI-systemer
• dataanalyse
• forretningsrisiko
• cybersikkerhed
• etik
• governance
• menneske-maskine-samarbejde

Men netop derfor bliver rollen også langt mere spændende.

AI fjerner ikke behovet for testledelse.

AI gør ægte testledelse vigtigere end nogensinde før.

Konklusion

AI-testmanageren bliver ikke fremtidens helt, fordi rollen kan kontrollere al teknologi.

Rollen bliver vigtig, fordi ingen andre har det samlede perspektiv på kvalitet, risiko, tillid og forretningsmæssige konsekvenser.

I en verden fyldt med autonome systemer, generativ AI og konstant forandring får organisationer desperat brug for mennesker, der kan skabe overblik, stille de rigtige spørgsmål og sikre ansvarlige beslutninger.

Det er præcis her, fremtidens AI-testmanager står.

Ikke som administrator.

Ikke som rapportgenerator.

Men som strategisk kvalitetsleder i en AI-drevet verden.

Og måske er det netop testfagets største mulighed nogensinde.

AI i softwaretest – trussel eller transformation?

Kunstig intelligens har for alvor fundet vej ind i softwaretest, og det er ikke længere et spørgsmål om, hvorvidt teknologien vil påvirke testfaget, men hvordan og i hvilket omfang. Mange testere oplever i dag en vis usikkerhed: Hvis AI kan generere testcases, automatisere regressionstest og analysere fejl hurtigere end mennesker, hvad er så testerens rolle i fremtiden?

Dette spørgsmål er både legitimt og nødvendigt. Men det kræver en nuanceret analyse at besvare det.

AI ændrer ikke behovet for test – den ændrer måden, vi tester på.

AI som accelerator i testprocessen

I praksis ser vi allerede, hvordan AI bliver anvendt på tværs af hele testlivscyklussen. Særligt inden for testdesign har generativ AI vist sig effektiv til hurtigt at omsætte krav og user stories til testscenarier. Det betyder, at testere i højere grad kan fokusere på at validere og forbedre testene frem for at starte fra bunden. Det sparer tid, men ændrer også fokus fra produktion til kvalitetssikring af testartefakter.

Inden for testautomatisering bevæger vi os væk fra traditionelle, skrøbelige scripts og hen imod mere intelligente løsninger. AI-baserede værktøjer kan eksempelvis tilpasse sig ændringer i brugergrænseflader og dermed reducere vedligeholdelsesomkostninger. Samtidig kan testeksekvering optimeres ved hjælp af risikobaseret prioritering, hvor AI analyserer historiske data og identificerer de mest kritiske tests.

Derudover spiller AI en stadig større rolle i analysefasen. Logfiler, fejlrapporter og performance-data kan gennemgås langt hurtigere og mere systematisk, end det tidligere har været muligt. Dette gør det muligt at identificere mønstre og årsager til fejl på et niveau, som tidligere krævede betydelig manuel indsats.

Set i dette lys er AI først og fremmest en kraftig accelerator. Den gør eksisterende processer hurtigere og mere skalerbare.

Begrænsningerne – hvor AI kommer til kort

Det er dog afgørende ikke at forveksle acceleration med forståelse. AI arbejder på baggrund af mønstre i data og har ingen reel forståelse af forretningens intentioner eller kontekst. Den kan generere testcases, der ser overbevisende ud, men som ikke nødvendigvis adresserer de vigtigste risici.

Denne mangel på kontekstforståelse er central. Softwaretest handler ikke kun om at verificere funktionalitet, men om at vurdere kvalitet i forhold til forretningsværdi. Det kræver indsigt, erfaring og kritisk tænkning – egenskaber, som AI ikke besidder.

Derudover er AI stærkt afhængig af kvaliteten af input. Dårligt formulerede krav eller upræcise prompts vil føre til tilsvarende utilstrækkelige resultater. Dette betyder, at testeren i stigende grad får en rolle som “kurator” af AI-output snarere end producent.

Endelig er der spørgsmålet om ansvar. AI kan foreslå, analysere og optimere, men den kan ikke stå til ansvar for kvaliteten af et system. Det ansvar ligger fortsat hos mennesker – og i praksis hos testere og kvalitetsansvarlige.

Risikoen for at testere bliver overflødige

Bekymringen for, at AI vil eliminere behovet for testere, udspringer ofte af en antagelse om, at test primært består af gentagelige og regelbaserede opgaver. Det er netop disse opgaver, AI er bedst til at overtage.

Men testfaget er langt mere end det.

Hvis en testers rolle reduceres til manuel eksekvering af testcases, så er der en reel risiko for, at denne type arbejde bliver automatiseret væk. AI er særdeles effektiv til netop denne type opgaver. Men dette repræsenterer kun en begrænset del af testdisciplinen.

Den egentlige værdi af test ligger i evnen til at stille de rigtige spørgsmål, identificere skjulte risici og udfordre antagelser. Det er her, testere skaber værdi – og det er netop her, AI ikke kan erstatte menneskelig dømmekraft.

I stedet for at eliminere testere vil AI derfor skabe en opdeling: rutineprægede opgaver vil forsvinde eller blive stærkt reduceret, mens behovet for højt kvalificerede testere vil stige.

En ny rolle for testeren

Udviklingen peger mod en transformation fra traditionel test til det, man i stigende grad betegner som “quality engineering”. Her flyttes fokus fra udførelse til strategi, fra testcases til risikostyring og fra kontrol til rådgivning.

Testere vil i højere grad arbejde med at definere teststrategier, vurdere kvaliteten af AI-genererede artefakter og sikre, at testindsatsen er målrettet de mest kritiske områder. Samtidig bliver forståelse for AI en vigtig kompetence. Det handler ikke nødvendigvis om at udvikle AI-modeller, men om at forstå deres styrker og begrænsninger.

En anden vigtig udvikling er, at AI i sig selv introducerer nye testudfordringer. Systemer baseret på machine learning kræver test af bias, robusthed og forklarlighed – områder, som ligger uden for traditionel funktionel test. Dette åbner nye specialiseringsmuligheder for testere.

Transformation frem for trussel

Det mest realistiske perspektiv er derfor ikke, at AI erstatter testere, men at den redefinerer deres rolle. Testere, der fastholder et fokus på manuelle og repetitive opgaver, risikerer at blive mindre relevante. Omvendt vil testere, der formår at kombinere testfaglighed med forståelse for AI, blive endnu vigtigere.

AI skal ikke ses som en konkurrent, men som et værktøj. Et meget kraftfuldt værktøj, som kan løfte testarbejdet til et nyt niveau – hvis det anvendes korrekt.

Konklusion

AI ændrer fundamentalt måden, vi arbejder med softwaretest på. Den automatiserer, accelererer og optimerer – men den erstatter ikke behovet for menneskelig dømmekraft, kontekstforståelse og kritisk tænkning.

Fremtidens testere vil ikke være dem, der udfører flest tests, men dem, der bedst forstår, hvad der skal testes – og hvorfor.

Næste skridt

For testere betyder dette, at det er nødvendigt aktivt at forholde sig til AI. Det indebærer at eksperimentere med AI-værktøjer, udvikle evnen til kritisk at vurdere deres output og styrke kompetencer inden for teststrategi og risikobaseret test.

Organisationer bør samtidig sikre, at AI integreres ansvarligt i testprocessen, og at der fortsat er fokus på kvalitet som en menneskelig disciplin.

Boganmeldelse - Sæt mennesker først - skab topresultater med emotionel intelligens

Titel: Sæt mennesker først – skab topresultater med emotionel intelligens

Forfatter: Mikkel Severin
Målgruppe for anmeldelsen: Testmanagers og testledere (agilt, hybrid, projekt)

Overordnet vurdering

“Sæt mennesker først” rammer et område, som mange testmanagers undervurderer: At testresultater sjældent bliver bedre af mere proces alene – men ofte bliver markant bedre af bedre samarbejde, tydeligere kommunikation og en sundere feedbackkultur.

Bogens styrke er, at den (formentlig) tager emotionel intelligens (EI) ned fra “blød” HR-retorik og gør det til en konkret ledelsesdisciplin. For en testmanager er det relevant, fordi kvalitet ofte fejler på mennesker og forventningsafstemning – ikke på testteknik.

Når det er sagt, er bogen også et klassisk eksempel på en genre, der kan blive lidt for optimistisk omkring, hvor meget EI alene kan “fikse”. Testmanagement kræver både mennesker og hård styring af risiko, scope, kvalitet og beslutninger. Den balance er afgørende.

Hvorfor bogen er relevant for testmanagement

Som testmanager sidder du i krydsfeltet mellem:

• udvikling, drift, forretning, compliance og ledelse

• deadlines og risici

• konflikter om “hvad betyder kvalitet?”

• prioriteringer af testindsats og acceptkriterier

I den virkelighed er EI ikke pynt. Det er et produktionsværktøj.

Bogen passer især godt til testmanagers, der:

• skal skabe alignment mellem stakeholders

• oplever “QA vs Dev”-konflikter

• arbejder i agile teams med høj autonomi

• skal påvirke uden formel magt

Bogens styrker (set med testmanager-briller)

1) Den adresserer den skjulte årsag til mange testproblemer

Mange testproblemer lyder tekniske (“for mange defects”, “for lidt tid”, “uklare krav”), men er ofte sociale:

• krav bliver uklare, fordi ingen tør stille dumme spørgsmål

• test bliver presset, fordi konfliktskyhed gør at man ikke eskalerer

• UAT fejler, fordi forretningen føler sig overhørt

EI-tilgangen er god, fordi den går efter årsagen: relationer, tryghed og kommunikation.

2) Den understøtter psykologisk tryghed (uden at gøre det fluffy)

Psykologisk tryghed er ikke “vi skal være søde”. Det er:

• vi kan tale om risiko uden at blive straffet

• vi kan sige “jeg forstår det ikke”

• vi kan stoppe en release uden at blive stemplet som negativ

Det er ekstremt relevant i test, hvor “dårlige nyheder” er en del af jobbet.

3) Den giver et sprog for ledelse i komplekse miljøer

Testmanagers har ofte et kommunikationsproblem:
De siger noget korrekt (risiko, kvalitet, coverage), men bliver misforstået som “bremseklods”.

EI hjælper med at oversætte:

• fra “vi mangler test” → “vi tager en beslutning med øget risiko – er det acceptabelt?”

• fra “det er en fejl” → “det her kan skade kunden / driften / økonomien”

Kritiske pointer (konstruktivt)

1) Risikoen: EI kan blive en undskyldning for ikke at være tydelig

I testledelse er tydelighed en pligt.
Hvis EI bliver “jeg vil ikke skabe dårlig stemning”, ender du med:

• for sene eskaleringer

• urealistiske testplaner

• falsk tryghed (“vi er næsten klar”)

EI skal bruges til at levere sandheden på en måde, der kan handles på – ikke til at polere den.

Testmanager-takeaway:
Brug EI til at gøre dine budskaber mere modtagelige, men aldrig mindre præcise.

2) Den typiske blind vinkel: strukturer og systemer

Mennesker er vigtige – men testmanagement er også:

• governance

• entry/exit criteria

• risikobaseret prioritering

• defekttriage og release readiness

Hvis bogen lægger for meget vægt på individets følelsesmæssige kompetencer, kan man overse:

at dårlige systemer skaber dårlige adfærdsmønstre.

Et team kan være nok så empatisk – hvis testmiljøet altid er nede, går alt i stykker alligevel.

3) “Topresultater” er et farligt ord i test

I test er “topresultater” ikke altid lig med:

• høj velocity

• færre testdage

• hurtigere release

Nogle gange er topresultatet, at man:

• stopper en release i tide

• får et ærligt billede af kvalitet

• skaber læring, der reducerer fejl næste kvartal

Hvis bogen måler succes primært som performance og output, skal testmanageren selv oversætte det til kvalitet og risikostyring.

Konkrete anvendelser i testmanagement (praktisk værdi)

1) Defektkonflikter: “Det er ikke en bug”

EI kan hjælpe dig med at styre defekttriage uden at det bliver personligt.

Praktisk greb:

• Skift fra skyld → konsekvens

• Skift fra debat → beslutningskriterier

Eksempel:

“Hvis vi shipper det her, hvad er worst-case for kunden? Hvad koster det at fixe nu vs senere?”

2) Release readiness: at sige nej uden at blive fjenden

Testmanagers skal ofte sige:

• “Nej, vi kan ikke anbefale release”

• “Ja, men med kendt risiko”

EI gør dig bedre til at:

• være rolig under pres

• læse rummets reaktion

• kommunikere risiko uden drama

3) Stakeholder management: forretning vs IT

EI hjælper dig med at opdage, hvad konflikten egentlig handler om:

• forretningen vil have forudsigelighed

• IT vil have frihed

• drift vil have stabilitet

• sikkerhed vil have kontrol

Du kan bruge bogen som en mental model for “hvad er det her menneske bange for at miste?”

Hvem bør læse den (og hvem bør ikke)?

Bør læse den

• Testmanagers i agile/hybrid teams

• Testledere der ofte ender som “mægler”

• Testmanagers med ansvar for UAT og stakeholders

• Folk der vil løfte deres ledelse uden at blive “mini-PM”

Bør supplere den med noget andet

Hvis du primært kæmper med:

• testproces, governance, modenhed

• teststrategi, risikobaseret test, metrics

• ISO 29119-artefakter og struktur

…så er EI kun en del af løsningen. Du skal have både mennesker og mekanik.

Samlet dom

Bogen er et stærkt bud på en “testmanager-superpower”: emotionel intelligens.
Den kan gøre dig bedre til at:

• skabe samarbejde

• håndtere konflikter

• drive kvalitet uden autoritet

• få dine budskaber igennem

Men du skal læse den med en testleders kritiske sans:
EI er ikke et alternativ til teststyring, risikostyring og tydelige beslutninger. Det er en forstærker.

Bedste måde at bruge bogen på (anbefaling)

Læs den med én konkret udfordring i baghovedet, fx:

• “Hvordan får jeg forretningen til at tage test alvorligt?”

• “Hvordan stopper jeg ‘QA vs Dev’?”

• “Hvordan får jeg ærlig status uden spin?”

Og omsæt derefter til 2-3 konkrete vaner:

• bedre feedback

• tydeligere forventningsafstemning

• mere rolig konflikthåndtering