tirsdag den 8. september 2026

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.

mandag den 31. august 2026

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

søndag den 21. juni 2026

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.


onsdag den 6. maj 2026

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.


søndag den 29. marts 2026

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.


mandag den 23. februar 2026

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


fredag den 19. december 2025

Aktuelle udfordringer for testanalytikeren ved brug af kunstig intelligens i softwaretest

Kunstig intelligens (AI) har på kort tid bevæget sig fra eksperimentel teknologi til et dagligt værktøj i mange testteams. Testanalytikere bruger i stigende grad AI til at understøtte testdesign, testdata-generering, kravsanalyse, log-analyse og endda udforskende test.

Men med mulighederne følger også en række nye og komplekse udfordringer, som direkte påvirker testanalytikerens faglighed, ansvar og måde at arbejde på.

Dette blogindlæg fokuserer på de vigtigste aktuelle udfordringer, set fra testanalytikerens perspektiv – og hvordan de kan håndteres professionelt.

1. Risikoen for blind tillid til AI-genereret testdesign

Udfordringen

AI kan hurtigt generere testcases, testscenarier og forslag til dækning baseret på krav, user stories eller kode. Problemet opstår, når testanalytikeren:

  • accepterer output uden kritisk vurdering

  • overser domænespecifikke risici

  • mister fokus på hvorfor der testes, ikke kun hvad

AI er statistisk stærk – men forstår ikke kontekst, forretning eller implicitte risici.

Eksempel

En AI genererer komplette positive/negative testcases for en betalingsløsning, men overser:

  • regulatoriske edge cases

  • kombinationer af forretningsregler

  • tidligere produktionsfejl (known risks)

Mitigation

  • Anvend Human-in-the-Loop: AI foreslår – testanalytikeren beslutter

  • Brug AI som idé-generator, ikke beslutningstager

  • Kombinér AI-output med klassiske teknikker (BVA, EP, beslutningstabeller)

2. Manglende transparens og forklarbarhed (Explainability)

Udfordringen

Mange AI-værktøjer fungerer som “black boxes”:

  • Hvorfor foreslår AI netop disse testcases?

  • Hvilke antagelser ligger bag?

  • Hvad er datagrundlaget?

For testanalytikeren er dette problematisk, fordi:

  • testdækning skal kunne forklares

  • testdesign ofte skal reviewes og auditeres

  • ISO/ISTQB kræver sporbarhed og begrundelse

Mitigation

  • Foretræk værktøjer med forklarbart output (prompt → resultat → rationale)

  • Dokumentér AI-assisterede beslutninger eksplicit i testdesignet

  • Brug AI som supplement til – ikke erstatning for – strukturerede testteknikker

3. Bias og skævheder i AI’ens forslag

Udfordringen

AI lærer af eksisterende data, kode og dokumentation. Hvis disse er:

  • mangelfulde

  • historisk biased

  • teknisk fokuserede frem for brugerfokuserede

… vil testforslagene også være det.

Konsekvens

  • Overfokus på “happy paths”

  • Underrepræsentation af marginale brugergrupper

  • Manglende fokus på usability, etik og fairness

Mitigation

  • Kombinér AI med erfaringsbaseret test og exploratory testing

  • Stil bevidste “modspørgsmål” til AI (prompt engineering)

  • Supplér med persona-baseret test og risiko-workshops

4. Udvanding af testanalytikerens kernekompetencer

Udfordringen

Når AI:

  • analyserer krav

  • foreslår testcases

  • identificerer risici

… er der en reel risiko for, at testanalytikeren gradvist mister:

  • analytisk skarphed

  • domæneforståelse

  • evnen til selvstændigt testdesign

Dette er især kritisk for juniorer – men rammer også seniorer over tid.

Mitigation

  • Bevar manuel træning i testdesign som disciplin

  • Brug AI som “sparringspartner”, ikke autopilot

  • Reflektér aktivt: Hvad ville jeg selv have gjort uden AI?

5. Uklare roller og ansvar ved AI-baserede testbeslutninger

Udfordringen

Når AI bidrager til testanalyse og -design:

  • Hvem er ansvarlig for manglende testdækning?

  • Hvem “ejer” testbeslutningen?

  • Hvem forklarer fejl i produktion?

Svaret er (stadig): testanalytikeren.

Mitigation

  • Accepter at ansvar ikke kan delegeres til AI

  • Dokumentér beslutninger og fravalg

  • Sørg for fælles forståelse i teamet af AI’s rolle og begrænsninger

6. Krav til nye kompetencer hos testanalytikeren

Udfordringen

AI ændrer ikke behovet for testanalytikere – men ændrer kompetenceprofilen:

Nye nøglekompetencer:

  • Prompt engineering for testformål

  • Kritisk evaluering af AI-output

  • Forståelse af AI’s styrker/svagheder

  • Etik, bias og kvalitet i AI-systemer

Perspektiv

Testanalytikeren bevæger sig fra:

“Jeg designer testcases”
til
“Jeg orkestrerer kvalitet – med og uden AI”

Samlet vurdering

AI er et stærkt værktøj for testanalytikeren – men kun når det bruges bevidst, kritisk og ansvarligt.

De største udfordringer handler ikke om teknologi, men om:

  • faglig dømmekraft

  • ansvar

  • bevarelse af testdisciplinen

Den professionelle testanalytiker, der forstår både klassisk testteori og AI’s begrænsninger, vil stå stærkere end nogensinde.

Kort opsummering

  • AI kan accelerere testanalyse – men ikke erstatte den

  • Blind tillid, bias og black-box-output er centrale risici

  • Testanalytikeren har fortsat det fulde ansvar

  • Nye kompetencer er nødvendige – men fundamentet består

torsdag den 18. december 2025

Softwaretest for ledelsen – et strategisk anliggende

Softwaretest bliver ofte opfattet som et operationelt anliggende, der hører hjemme hos testteamet. I praksis er test dog et ledelsesværktøj, fordi testresultater direkte understøtter beslutninger om risiko, kvalitet, tid og forretning. For test managers er en af de vigtigste discipliner derfor at sikre meningsfuld involvering af ledelsen – uden at drukne dem i detaljer.

Dette blogindlæg fokuserer på:

  • Hvorfor ledelsen skal involveres i softwaretest

  • Hvilke beslutnings- og godkendelsesroller ledelsen typisk har

  • Hvordan test managers bedst understøtter disse roller

Hvorfor er ledelsesinvolvering i softwaretest nødvendig?

Set fra ledelsens perspektiv handler softwaretest ikke om testcases, værktøjer eller defekter i sig selv – men om forretningsrisiko.

Ledelsen har ansvar for:

  • Kundepåvirkning

  • Overholdelse af lovgivning og compliance

  • Omdømme

  • Økonomi og time-to-market

Test giver evidens for:

  • Om løsningen er tilstrækkeligt moden

  • Hvilke risici der er accepteret – bevidst eller ubevidst

  • Hvad konsekvenserne er ved at release (eller ikke release)

Uden test mister ledelsen sit faktuelle beslutningsgrundlag.

Ledelsens typiske beslutnings- og godkendelsesroller

Nedenfor er de mest centrale roller, hvor test managers aktivt bør inddrage ledelsen.

1. Strategisk rolle – fastlæggelse af kvalitetsambition

Beslutninger:

  • Hvad betyder “tilstrækkelig kvalitet” for organisationen?

  • Hvor høj risiko er acceptabel?

  • Hvor balanceres kvalitet vs. time-to-market?

Ledelsens ansvar:

  • Godkende teststrategi og kvalitetsmål

  • Prioritere risici på forretningsniveau

Testmanagers bidrag:

  • Oversætte tekniske risici til forretningskonsekvenser

  • Præsentere teststrategi i ledelsessprog (ikke test-sprog)

Eksempel:

“Hvis vi reducerer regressionstesten for at nå deadline, accepterer vi øget risiko for fejl i faktureringen – potentielt med økonomiske tab.”

2. Taktisk rolle – prioritering og scope-beslutninger

Beslutninger:

  • Hvad testes grundigt – og hvad testes mindre?

  • Skal testindsatsen justeres pga. tid, budget eller ressourcer?

Ledelsens ansvar:

  • Godkende ændringer i scope og prioritering

  • Træffe informerede trade-off-beslutninger

Test managers bidrag:

  • Risikobaserede testoversigter

  • Konsekvensvurderinger ved ændringer

God praksis:

Brug simple visualiseringer som:

  • Risiko-matrix

  • Heatmaps

  • “Hvis–så”-scenarier

3. Go / No-Go – den klassiske godkendelsesrolle

Beslutninger:

  • Må løsningen sættes i produktion?

  • Skal releaset udsættes?

Ledelsens ansvar:

  • Den endelige beslutning og ejerskab af risiko

Test managers bidrag:

  • Objektivt testgrundlag – ikke anbefaling forklædt som fakta

  • Klar status på:

    • Testdækning

    • Kendte fejl

    • Åbne risici

    • Afvigelser fra plan

Vigtigt princip:

Testmanager anbefaler – ledelsen beslutter.

4. Governance- og compliance-rolle

Beslutninger:

  • Opfylder løsningen interne og eksterne krav?

  • Kan vi dokumentere tilstrækkelig kvalitet?

Ledelsens ansvar:

  • Sikre audit- og compliance-parathed

Test managers bidrag:

  • Sporbarhed mellem krav, test og resultater

  • Testdokumentation iht. ISO/IEC 29119

  • Transparens i afvigelser

Dette er særligt vigtigt i regulerede domæner (finans, sundhed, offentlig sektor).

Hvordan taler man test med ledelsen? (praktiske råd)

Som testmanager er kommunikation afgørende:

Skift fokus fra:

  • Antal testcases

  • Antal fundne fejl

Til:

  • Forretningsrisiko

  • Kundepåvirkning

  • Sandsynlighed × konsekvens

  • Beslutningsmuligheder

Eksempel på omformulering:

Fra: “Der er stadig 12 åbne defects”
Til:  “Der er 3 kendte risici, som kan påvirke kundernes mulighed for at gennemføre betaling”

Typiske faldgruber (og hvordan de undgås)

FaldgrubeKonsekvensMitigation
For teknisk rapporteringLedelsen mister overblikOversæt til forretning
Skjulte anbefalingerUklart beslutningsansvarVær eksplicit
Manglende risikofokusFejlprioriteringBrug risikobaseret test
Sen involveringPanik ved go/no-goInddrag tidligt

Opsummering

For test managers er softwaretest for ledelsen ikke en ekstra opgave – det er kernen i professionel testmanagement.

Nøglepointer:

  • Test er beslutningsstøtte – ikke kun kvalitetssikring

  • Ledelsen skal involveres strategisk, taktisk og operationelt

  • Klart rolle- og ansvarsfordeling styrker governance

  • God testkommunikation skaber tillid og bedre beslutninger