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:
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:
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:
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.