Aktuelle udfordringer for testmanagement – et strategisk blik på fremtidens kvalitetsledelse

Testmanagement befinder sig i et af de mest turbulente og foranderlige årti i softwareudviklingens historie. Udviklingshastigheden stiger, produktkompleksiteten vokser, teams skifter arbejdstempo og organisering, og teknologier som AI og cloud ændrer forudsætningerne for, hvordan kvalitet overhovedet sikres. Samtidig bliver organisationernes forventninger til kvalitet, compliance, hastighed og forudsigelighed kun større. Midt i dette står testmanageren – ansvarlig for governance, risikostyring, strategi, proces, værktøjer og kvalitet.

Dette blogindlæg dykker ned i de mest aktuelle udfordringer, som testmanagers står overfor i dag, og forklarer, hvorfor de er opstået, samt hvordan de påvirker ledelsen af testfunktionen.

Stigende kompleksitet i systemer, integrationer og data

Moderne software består sjældent af ét samlet system. Det består af microservices, API-landskaber, cloud-miljøer, eksterne integrationer, IoT-komponenter og avancerede datalagre. Det betyder, at selv mindre ændringer kan få uforudsete konsekvenser på tværs af systemer. For testmanageren betyder det, at risikoanalysen er blevet langt mere kompleks end tidligere. Det er ikke længere nok at kende ét system – man skal forstå hele værdikæden, afhængighederne og de kritiske integrationspunkter. Dette stiller højere krav til både tværfaglig kommunikation, stakeholder-management og koordinering af testmiljøer og data.

Ustabile eller utilgængelige testmiljøer

I mange organisationer er testmiljøer stadig en akilleshæl. Miljøerne er ofte ustabile, dårligt dokumenterede eller ikke repræsentative for produktion. Fejl skyldes lige så ofte konfigurationsproblemer som egentlig produktdefekt. For testmanagers skaber dette en vedvarende udfordring: testdata er upræcise, reproduktion af fejl er besværlig, og planer skrider, fordi miljøerne ikke understøtter de ønskede testaktiviteter. Dette kræver bedre miljøstyring, investeringer i environments-as-code og en mere moden tilgang til testdatahåndtering. Men i mange organisationer er dette stadig et modningsarbejde, der kræver ressourcer og prioritering, som ikke altid er til stede.

Kravene ændrer sig hurtigere, end testorganisationen kan følge med

Agile og DevOps har øget udviklingshastigheden markant, men testorganisationerne har ikke altid haft mulighed for at følge med i samme tempo. Mange testmanagers oplever user stories, der er ufuldstændige, krav der ikke er valideret, og ændringer, der bliver introduceret sent i sprintet. Dette påvirker både testdesign, estimater og testexecution, og skaber frustration i testorganisationen. Uden stærk governance omkring definition of ready, kontinuerlig kravkvalitet og samarbejde på tværs af roller mister testmanageren muligheden for at forudsige og styre kvaliteten effektivt.

Mangel på tid, ressourcer og kompetencer

Testteams oplever ofte et skiftende pres: mere skal testes, på kortere tid, med færre ressourcer. Samtidig forventes testerne at beherske både automatisering, domæneviden, dataanalyse, sikkerhed og kvalitetssikring. Mange organisationer mangler de rette kompetencer, særlig inden for automatisering, testarkitektur og AI-understøttet test. Testmanagers står derfor i en dobbeltrolle: at sikre leverancer her og nu – samtidig med at opbygge den fremtidige kompetencebase. Dette kræver langsigtet strategi, træning, mentoring og ofte også en kulturforandring i organisationen.

Automatiseringens løfte – og virkelighed

Automatisering er fortsat en central hjørnesten i moderne teststrategier. Men automatisering er ikke gratis, og det løser ikke alle problemer. Mange testmanagers oplever automatiseringsprojekter, der er for komplekse, for skrøbelige, for dyre at vedligeholde eller ikke dækker de rigtige risikoområder. Automatisering skal designes, modelleres, dokumenteres og vedligeholdes – og uden en strategisk tilgang kan automatisering hurtigt blive en teknisk gæld snarere end en gevinst. Samtidig skaber AI-drevne automatiseringsværktøjer nye muligheder, men også nye spørgsmål om kvalitet, kontrol og governance.

DevOps-presset og nødvendigheden af kontinuerlig kvalitet

Med DevOps og CI/CD forventes test at være en naturlig del af en automatiseret og hurtig pipeline. Men testorganisationer bliver ofte klemt mellem hurtige deployment-cyklusser og krav om høj sikkerhed, stabilitet og compliance. Mange testmanagers oplever, at tid til dybdegående test og manuel verificering bliver reduceret, samtidig med at organisationens tolerance for fejl falder. Dette skubber testledelse i retning af mere data-drevet kvalitetsovervågning, shift-left og shift-right-test samt tættere samarbejde med drift, udvikling og arkitektur.

Mangelfuld dokumentation og uklare kvalitetskriterier

Et af de mest fundamentale problemer i testledelse er, at kvalitet sjældent er defineret tilstrækkeligt klart. Definitionen af “done”, acceptkriterier, kravspecifikationer og kvalitetsmål er ofte enten uklare eller skifter løbende. Det gør det svært for testmanageren at forankre en stabil teststrategi, planlægge realistiske aktiviteter og kommunikere risiko. Testmanagement bygger på styring – men styring kræver klare pejlemærker. Derfor bliver governance og procesdisciplin afgørende grundkomponenter i enhver moderne testorganisation.

Forventninger om hurtig rapportering og datadrevet styring

Interessenter forventer hyppigere, mere præcis og mere datadrevet rapportering end tidligere. Det stiller store krav til testmetrikker, dashboards og analysemodeller. Mange testorganisationer bruger stadig manuelle eller fragmenterede rapporteringsmetoder, hvilket skaber risiko for unøjagtige beslutninger. Testmanageren skal derfor både sikre valide data, rigtige metrikker og et rapporteringsformat, der understøtter ledelsens behov for transparens og handling – uden at drukne teamet i administration.

AI som både løsning og udfordring

AI tilbyder enorme muligheder for accelereret testdesign, automatiseret analyse og intelligent prioritering. Men AI skaber også nye udfordringer. Testmanageren skal kunne vurdere risikoen ved AI-genererede artefakter, sikre korrekt validering, forstå teknologiske begrænsninger og etablere governance for brug af AI. Det er en balancegang: AI kan forbedre testindsatsen betydeligt, men kun hvis det integreres med omtanke og kvalitetssikring. Det kræver, at testorganisatonen udvikler kompetencer inden for både teknologi og kritisk evaluering.

Konklusion: Testmanagement er blevet en strategisk disciplin

De aktuelle udfordringer for testmanagement viser, at rollen er mere strategisk og tværgående end nogensinde før. Testmanageren er ikke blot en koordinator, men en brobygger mellem forretning, udvikling, kvalitet, teknologi og governance. Der stilles større krav til risikostyring, ledelse, kommunikation, kompetenceopbygning og datastrategi.

Samtidig giver moderne metoder og teknologier – herunder AI, bedre automatiseringsværktøjer, observability og stærkere standarder – nye muligheder for at modernisere testområdet og skabe en mere moden, effektiv og proaktiv kvalitetsfunktion.

De testmanagers, der formår at navigere i denne nye virkelighed, vil ikke blot sikre høj kvalitet i deres organisation – de vil være blandt de få, der sætter retningen for fremtidens testdisciplin.

Hvordan AI kan understøtte softwaretesten– et strategisk perspektiv for testmanagers

Artificial Intelligence er på få år gået fra at være teknologisk kuriosum til et praktisk værktøj, der allerede har forandret arbejdet i udviklings- og QA-afdelinger verden over. Software bliver mere komplekst, releasefrekvensen stiger, og organisationer forventer kortere leveringstid uden at gå på kompromis med kvaliteten. I dette krydspres står testmanageren med en central opgave: Hvordan organiserer man testindsatsen, så effektivitet og kvalitet følges ad? AI giver her helt nye muligheder, men også nye ansvar.

Formålet med dette blogindlæg er at give dig som testmanager et realistisk, strategisk og praksisnært indblik i, hvordan AI kan understøtte softwaretest – hvor gevinsterne ligger, hvordan det integreres i teststyringen, og hvilke faldgruber du bør være opmærksom på.

AI som løftestang i testprocessen

Når man ser på testens grundlæggende udfordringer – høj vedligeholdelsesbyrde, mange repetitive opgaver, begrænset tid til dybdegående risikovurdering og svære testdata-scenarier – matcher AI netop de områder, hvor testorganisationer typisk mangler kapacitet. Moderne AI-teknologi kan generere testcases fra tekstbeskrivelser, foreslå testdesign baseret på krav eller userstories, identificere risikoområder i kode eller historiske fejl, analysere applikationens adfærd under test og endda selv vedligeholde automatiserede tests, når brugergrænsefladen ændrer sig.

Det er netop kombinationen af hurtighed, pattern-matching og kontinuerlig læring, der gør AI så interessant for testledelse. Hvis AI anvendes rigtigt, kan det frigøre betydelige ressourcer og flytte tyngdepunktet i testarbejdet fra produktion af artefakter til strategisk kvalitetssikring.

Generering af testcases og testdesign med AI

En af de mest håndgribelige gevinster er AI’s evne til at analysere krav, userstories eller endda ustruktureret tekst og generere forslag til testcases. Det erstatter ikke testanalytikerens faglige dømmekraft, men fungerer som en accelerationsmekanisme. AI kan generere mange initiale testidéer på få sekunder, hvorefter testeren validerer, kontekstualiserer og prioriterer dem.

Set fra et testmanagement-perspektiv betyder det, at du hurtigere får et struktureret udgangspunkt for testdækning, især når der arbejdes i agile teams, hvor userstories løbende ændres eller udvides. Det giver samtidig mulighed for at opdage kravuklarheder tidligere, fordi AI ofte afslører manglende detaljer eller implicitte antagelser, når den forsøger at generere tests.

AI-drevet vedligeholdelse af automatiserede tests

Testautomatisering er traditionelt forbundet med en tung vedligeholdelsesbyrde, særligt inden for UI-test. Små ændringer i layout, feltnavne eller flow kan få automatiserede tests til at bryde sammen. AI-baserede selv-helbredende automatiseringsværktøjer overvåger testkørsler og justerer selv locatorer, selector-strategier eller interaktionsmønstre, når UI’et ændrer sig.

For en testmanager betyder det en helt ny økonomi i automatisering. I stedet for at allokere store ressourcer til vedligeholdelse kan teamet fokusere på testdesign, kvalitet af de rigtige områder og evaluering af dækning. Det øger ROI på automatisering markant, især i organisationer med hyppige releases eller dynamiske UI’er.

AI i risikostyring og prioritering

Testledelse handler i høj grad om at prioritere den rigtige testindsats. AI-baserede modeller kan analysere historiske fejl, kodeændringer, commit-logs, modulers kompleksitet og brugeradfærd for at identificere områder med forhøjet risiko. I praksis betyder det, at testmanageren får et datadrevet grundlag for beslutninger om, hvor indsatsen skal lægges.

Når deadlines nærmer sig, og regressionstesten skal komprimeres, kan AI hjælpe med at foreslå hvilke tests der sandsynligvis opdager flest kritiske fejl. Det giver bedre styrbarhed, hurtigere eksekvering og stærkere argumentation over for projektledelse og interessenter.

AI som kvalitetssensor i drift og testmiljøer

Moderne systemer er ofte distribuerede, event-drevne og afhængige af mange integrationspunkter. Her kan AI fungere som en slags kontinuerlig kvalitetssensor. Ved at analysere logfiler, performance-målinger, API-trafik og brugeradfærd kan AI opdage anomalier, uregelmæssigheder eller mønstre, der indikerer potentielle fejl.

Testmanagerens fordel er, at kvalitetsovervågning ikke længere begrænser sig til testmiljøet. AI gør det muligt at opfange problemer tidligt – nogle gange før slutbrugeren mærker dem – og dermed bringe testorganisationen tættere på DevOps-tankegangen om kontinuerlig kvalitet.

AI og governance: hvordan integreres teknologien ansvarligt?

En almindelig misforståelse er, at AI kan “overtage” testarbejdet. Realiteten er, at AI kræver stærkere styring – ikke mindre. For at AI kan fungere som en pålidelig del af testprocessen, skal testmanageren etablere klare rammer for kvalitetssikring, dokumentation, validering og brug af data.

AI skal integreres i testpolitikken og teststrategien, så det er tydeligt, hvilke beslutninger AI assisterer med, hvilke testaktiviteter der automatiseres, og hvilke områder der fortsat kræver menneskelig dømmekraft. Dette er især vigtigt i regulerede domæner eller organisationer med strenge auditkrav.

Derudover bør testmanageren sikre en proces, hvor AI-genererede artefakter løbende valideres. Testcases, scripts, analyser og defektforudsigelser skal kvalitetstjekkes og journalføres som enhver anden del af testen. AI må aldrig blive en ukritisk autoritet; det skal være en kvalificeret assistent.

Faldgruber og realistiske begrænsninger

AI kan meget, men ikke alt. Den største risiko ligger i at overvurdere teknologien og undervurdere det menneskelige ansvar. AI kan generere imponerende mængder testcases, men det betyder ikke, at de er korrekte, relevante eller risikobaserede. Ustrukturerede eller mangelfulde datakilder kan føre til misvisende anbefalinger. Og AI-modellen forstår hverken domænekrav, organisationens kvalitetspolitiske mål eller de subtile risici i forretningsprocesserne.

Derfor bør AI ses som accelerationsmotor – ikke autopilot.

Hvordan testmanageren kommer i gang

Det mest effektive er at starte med et pilotprojekt med klart defineret scope, eksempelvis inden for automatiseret regressionstest, testdesign fra user stories eller AI-drevet analyse af logdata. Herefter etableres governance, metrikker og feedback-loops. Pilotens resultater bruges som datagrundlag for at skalere teknologien.

Kompetenceudvikling er afgørende. Testere skal ikke nødvendigvis være datascientists, men de skal forstå AI’s principper, begrænsninger og måde at generere output på. Den nye testerrolle er i højere grad kurator, validator og risikovurderende ekspert end traditionel “testskribent”.

Konklusion

AI rummer et stort potentiale for at styrke softwaretesten – især når det gælder effektivitet, kvalitet, risikostyring og vedligeholdelsesreduktion. Men AI er ikke en erstatning for testledelse; det er et værktøj, der udvider testmanagerens strategiske muligheder. Når teknologien integreres med stærk governance, datadisciplin og tydelige kvalitetsmål, kan AI blive et centralt element i en moderne, fremtidsorienteret testorganisation.

Den testmanager, der allerede nu begynder at arbejde bevidst med AI, lægger grundstenen til en testfunktion, der ikke blot følger med udviklingen – men sætter retningen for den.

Hvordan vælger man de rette testteknikker

Valget af testteknikker er en strategisk beslutning, der påvirker både testkvalitet, effektivitet og risikodækning. En testmanager skal balancere mellem teori, praktisk erfaring og kontekstuelle faktorer for at vælge den mest hensigtsmæssige tilgang. Dette blogindlæg udfolder de vigtigste kriterier, beslutningsparametre og praktiske anbefalinger.

1. Formålet med at vælge testteknikker

Testteknikker er metoder til at udlede, designe og vælge testtilfælde baseret på et givet testgrundlag. Valget af teknik skal understøtte projektets mål og teststrategien. Et godt valg sikrer:

• Effektiv testdækning (høj risikoafdækning pr. testindsats)

• Konsistens i testudførelse

• Sporbarhed mellem krav, risici og testdesign

• Skalerbarhed på tværs af teams og systemkomponenter

2. Centrale faktorer ved valg af testteknik

2.1 Testgrundlaget

Testgrundlaget er den primære kilde til at udlede testcases. Typiske overvejelser:

• Krav og specifikationers type og kvalitet:

  • Formelle, præcise krav → strukturerede teknikker som beslutningstabeller og tilstandsovergangstest.

  • Uformelle beskrivelser eller user stories → heuristiske teknikker som undersøgende test og checklister.

• Tilgængelighed af modeller:

  • Ved procesmodeller, domænemodeller eller arkitekturdiagrammer er modelbaseret test velegnet.

• Kompleksitet:

  • Høj kompleksitet → kombination af domæneanalyse og risikobaseret test.

2.2 Testernes viden, erfaring og færdigheder

Valget af teknik skal afspejle testteamets modenhed:

• Erfarne testanalytikere: kan anvende formelle teknikker (f.eks. årsags-virkning-diagrammer, klassifikationstræer).

• Mindre erfarne testere: bør anvende mere intuitive teknikker som ækvivalenspartitionering og grænseværdianalyse.

• Kombination af profiler: giver mulighed for par-testdesign, hvor erfarne coacher de mindre erfarne.

2.3 Risikoniveau

Risikobaseret test (RBT) anbefales som beslutningsramme.
Eksempler:

• Høj risiko: kombiner systematiske teknikker (beslutningstabeller, tilstandsovergang) med negative tests.

• Lav risiko: anvend erfaringsbaserede teknikker som error guessing og exploratory testing.

2.4 Systemets og domænets karakter

• Sikkerhedskritiske systemer: kræver formelle teknikker (f.eks. MC/DC, boundary value analysis).

• Forretningsapplikationer: egner sig til beslutningstabeller, use case-baserede tests og dataflow-test.

• AI- eller datadrevne systemer: kræver kombination af statistisk test, biasanalyse og exploratory testing.

2.5 Projektkontekst og livscyklus

I agile miljøer vægtes tidlig feedback og lav overhead, hvilket favoriserer letvægts teknikker.
I traditionelle V-modelprojekter prioriteres sporbarhed og dokumentation, hvor formelle teknikker er mere passende.

3. Fremgangsmåde til valg af testteknikker

Trin	Aktivitet	Output
1	Identificér testgrundlaget og vurder dets kvalitet	Klar forståelse af krav og modeller
2	Vurder risikoniveauer pr. funktion eller komponent	Risikomatrix
3	Match teknik med risikoniveau og testgrundlag	Tabel for teknikvalg
4	Vurder teamets kompetencer	Kompetencekort
5	Vælg kombination af teknikker	Dokumenteret teknikportefølje
6	Evaluer og justér ud fra resultater og dækningsgrad	Lessons learned og forbedringsplan

4. Eksempler

Kontekst	Typisk testteknik
Finansiel beregningstjeneste	Grænseværdianalyse + beslutningstabel
Webshop checkout-flow	Use case test + tilstandsovergangstest
AI-model for anbefalinger	Statistisk test + biasanalyse + exploratory
Legacy-system uden krav	Error guessing + exploratory testing

5. Faldgruber

• For ensidigt fokus: at vælge én teknik uden at supplere med andre.

• Manglende alignment med risici: fører til utilstrækkelig dækning.

• Manglende kompetencematch: testere anvender teknikker forkert.

• Uklart testgrundlag: forhindrer systematisk teknikvalg.

6. Moderne tendenser

• AI-assisteret teknikvalg: værktøjer som Testim og Xray AI kan analysere krav og foreslå testteknikker.

• Modelbaseret + generativ testdesign: brug af UML/SysML til automatisk testafledning.

• Hybridstrategier: kombination af klassiske og heuristiske teknikker understøttet af risk-based prioritization engines.

7. Konklusion

Valg af testteknikker er ikke et engangsvalg, men en kontinuerlig optimering. En dygtig testmanager evaluerer løbende:

• ændringer i risikolandskab,

• testgrundlagets modenhed, og

• teamets kompetenceudvikling.

En velovervejet kombination af teknikker øger testeffektiviteten, forbedrer kvaliteten og styrker dokumentationen — hvilket er nøglen til moden testledelse i praksis.

FMEA – Failure Mode and Effect Analysis

Introduktion

Når vi som testmanagers arbejder med risikobaseret test, er det afgørende at kunne vurdere, hvor fejl vil have størst indflydelse på forretningen, brugerne og teknologien. Failure Mode and Effect Analysis (FMEA) er en klassisk metode fra kvalitetsteknikken, oprindeligt udviklet i bilindustrien, som giver en struktureret tilgang til at identificere potentielle fejl, analysere deres konsekvenser og prioritere testindsatsen.

Ved at integrere FMEA i teststrategien kan vi dokumentere og kommunikere risikoovervejelser mere systematisk.

Fremgangsmåde – trin for trin

En FMEA-proces består typisk af følgende trin:

1. Definer scope og systemelementer

   • Afgræns den funktionalitet eller komponent, som skal analyseres.

   • Typisk: en modul, integration, proces eller brugerrejse.

2. Identificer failure modes (fejlmåder)

   • Hvordan kan en funktion fejle?

   • Eksempel: Et login kan fejle ved at afvise gyldige brugere, acceptere ugyldige brugere eller time-out.

3. Bestem effects (konsekvenser)

   • Hvilken indvirkning har fejlen på systemet eller brugeren?

   • Eksempel: Ugyldige brugere kan få adgang (høj forretningsrisiko).

4. Analyse af årsager og eksisterende kontrolforanstaltninger

   • Hvorfor kan fejlen ske (årsager)?

   • Hvilke eksisterende tests eller kontroller findes?

5. Score risiko

   • Vurder tre dimensioner (typisk på skala 1–10):

     • S (Severity – alvor)

     • O (Occurrence – sandsynlighed)

     • D (Detection – mulighed for at opdage fejlen tidligt)

   • Beregn RPN = S × O × D (Risk Priority Number).

6. Prioriter handlinger og testindsats

   • Testområder med høj RPN bør have fokus.

   • Handlinger kan være mere tests, bedre overvågning, eller forebyggende forbedringer.

7. Dokumentér og følg op

   • FMEA bør være et levende dokument, som justeres undervejs i projektet.

   • Opdater scoringer efterhånden som ny information eller kontrolmekanismer indføres.

Typiske faldgruber

Selv om FMEA er en stærk metode, er der velkendte udfordringer:

• Subjektivitet i scoringer
  – Teams scorer forskelligt afhængigt af erfaring, kultur og bias.
  – Afhjælpning: Brug workshops, tværfaglige perspektiver og faste skalaer.

• Overfokus på RPN
  – At sortere alene efter RPN kan skjule kritiske lav-frekvens/høj-severity risici.
  – Afhjælpning: Behandl severity som et særskilt kriterium.

• For omfattende analyser
  – Der er risiko for “analyse-paralyse”, hvor for meget tid går til scoring fremfor at handle.
  – Afhjælpning: Fokusér på forretningskritiske områder.

• Manglende vedligeholdelse
  – FMEA mister værdi, hvis den ikke opdateres løbende.
  – Afhjælpning: Integrer opfølgning i testplanens review-cyklus.

Relation til risikobaseret test

FMEA passer naturligt ind i ISTQB’s principper for risikobaseret test:

• Kobling til testprioritering:
  Høj RPN = mere testindsats, lav RPN = mindre test.

• Transparens i beslutninger:
  Stakeholders kan se, hvorfor visse områder testes mere intensivt.

• Alignment med ISO 29119 og ISO 31000:
  Giver dokumenterbarhed, hvilket styrker governance og audit-spor.

• Understøtter testdesign:
  Failure modes kan omsættes til konkrete testbetingelser og cases.

• Forbedrer samarbejde:
  Workshops omkring FMEA involverer udviklere, arkitekter, forretningen og testteamet, hvilket sikrer bredere risikodækning.

Konklusion

FMEA er ikke en “silver bullet”, men et effektivt værktøj til at operationalisere risikobaseret test. Når metoden bruges pragmatisk, kan den hjælpe testmanagers med at:

• Prioritere testindsats, hvor den giver mest værdi.

• Dokumentere risikobeslutninger for stakeholders.

• Skabe fælles forståelse af risici på tværs af organisationen.

Brugt korrekt kan FMEA være en game-changer i teststrategien – men kun hvis den holdes enkel, fokuseret og dynamisk.

Boganmeldelse: "How Big Things Get Done" af Bent Flyvbjerg og Dan Gardner – med fokus på testledelse

Introduktion

How Big Things Get Done (2023) er en indsigtsfuld og praksisnær bog, skrevet af Bent Flyvbjerg – verdens førende ekspert i megaprojekter – og Dan Gardner. Bogen analyserer systematisk, hvorfor store projekter (infrastruktur, software, energi mv.) så ofte fejler på tid, budget og mål – og hvad man kan gøre ved det.

For testmanagers og testledere, der opererer i komplekse projekter med høje krav til leverancer, risiko og kommunikation, rummer bogen værdifulde, direkte anvendelige principper.

Centrale pointer i bogen

Bogen stiller skarpt på, hvordan man bør planlægge rigtigt før man eksekverer hurtigt. Nøgleprincipperne inkluderer:

• "Think slow, act fast" – brug lang tid på planlægning, og udfør hurtigt og effektivt.

• Reference class forecasting (RCF) – planlæg ved at sammenligne med historiske data frem for optimistiske antagelser.

• Identificer og undgå "optimism bias" og "strategic misrepresentation".

• Modulær tilgang – tænk i små, gentagelige komponenter for at reducere kompleksitet.

• Start med slutmålet (design your project backwards).

• Opret en robust baseline og følg op med konstant realitetsjustering.

Anvendelighed for testmanagers og testledelse

Relevans for teststrategi og planlægning

Flyvbjergs gennemgang af systematiske fejl i planlægningsfasen er særligt relevant for testmanagers, som ofte står med teststrategien i store programmer. Mange teststrategier bygger (stadig) på ønsketænkning snarere end empirisk evidens. Her kan Flyvbjergs koncept om Reference Class Forecasting være et opgør med klassiske bottom-up estimater, og i stedet bringe en databaseret tilgang til testomkostninger, testindsats og risikobilledet.

Risikohåndtering og "optimism bias"

Testledere kender alt for godt til stakeholderes optimistiske opfattelse af hvor hurtigt og gnidningsfrit tests kan gennemføres – særligt under tidspres. Bogen tilbyder klare redskaber til at:

• Afsløre og imødegå urealistiske testforventninger.

• Dokumentere risici baseret på historiske data fra lignende projekter.

• Gøre beslutningstagere opmærksomme på skjulte antagelser.

Dette kan direkte kobles til ISTQBs risikobaseret teststrategi og testplan.

Modulær opbygning og MVP-tænkning i test

Flyvbjerg anbefaler at tænke i "small is beautiful": del store projekter op i små, testbare enheder. Dette matcher agile principper og giver testlederen et argument for at:

• Tidligt identificere testbare moduler.

• Skabe "early value" gennem test af delkomponenter.

• Bygge teststrategien op iterativt (inkrementel teststrategi).

I SAFe eller DevOps-kontekster, hvor kontinuerlig test og deployment er normen, er dette ekstremt anvendeligt.

Konkrete relationer til testmanagement

Bogsynspunkt	Testmanagement-anvendelse
RCF	Estimer testindsats baseret på data fra tidligere projekter (testware-reuse, målinger, MTTR)
Optimism bias	Indfør kritiske review-punkter i testplanlægningsfasen
Modularisering	Del testopgaven op i MVP’er, modultest, mikroservices, featureflags mv.
“Start with the end”	Definér testexitkriterier og coverage upfront – ikke som eftertanke
Realisme i tid/budget	Forlang tidsbuffer og plan for “non-happy-path” scenarier

Konstruktiv kritik

Mens bogen er lettilgængelig og inspirerende, kan dens eksempler (metrobyggerier, IT-infrastruktur) virke langt fra hverdagens testledelse. Der mangler dybdegående IT-case studies. Den empiriske styrke i Flyvbjergs forskning kunne have været suppleret med endnu mere konkret vejledning til fx softwareleverancer eller testteamledelse.

Derudover bruges der i nogle afsnit lidt populærpsykologiske greb (f.eks. "Seinfeld-effekten", storytelling), som testfagligt sindelag kan finde overfladiske – men det gør også bogen bredt tilgængelig.

Styrker og svagheder

Styrker	Svagheder
Evidensbaseret tilgang til planlægning	Mangler direkte testcases/eksempler
Relevant for alle med ansvar for leverancer	Fokuserer ikke på softwareprojekter alene
Kan bruges til at modgå urealistiske testkrav	Lidt gentagende mod slutningen
Let at læse, stærke anekdoter	Går ikke i dybden med agil/lean testkontekst

Konklusion og anbefaling

How Big Things Get Done bør være pensum for enhver testmanager, der arbejder i større projekter eller komplekse organisationer. Den tilbyder et nyt blik på planlægning, estimering og eksekvering, som mange testteams kan lære af. Bogen er særligt anvendelig til at udfordre eksisterende teststrategier og skabe en databaseret, realistisk tilgang til testplanlægning og governance.

Testmanagers bør især bruge bogen som argumentationsgrundlag overfor projektledere og styringsgrupper for at sikre realistiske testforløb, velbegrundede risikovurderinger og datadrevet planlægning.

Branching og Branchingstrategi – Testmanagerens Perspektiv

Indledning

Branching er en grundlæggende disciplin inden for versionsstyring. For testmanageren har valg af branchingstrategi stor indflydelse på kvalitetssikring, testbarhed og risikostyring. En veldefineret strategi kan reducere integration problemer, understøtte kontinuerlig test, og sikre bedre kontrol over releases. Omvendt kan en forkert strategi øge kompleksiteten, skabe flaskehalse og udvande kvaliteten af leverancer.

Fremgangsmåde til etablering af en branchingstrategi

En struktureret tilgang kan opdeles i følgende trin:

1. Analyse af kontekst

   • Udviklingsmodel (Scrum, SAFe, V-model)

   • Releasefrekvens (kontinuerlig vs. planlagte releases)

   • Teamstørrelse og geografi

2. Valg af strategi (typiske mønstre):

   • Feature branching: Nye funktioner udvikles i isolerede branches.

   • Release branching: Dedikerede branches til specifikke releases.

   • Hotfix branching: Hurtige rettelser håndteres separat.

   • Trunk-Based Development (TBD): Minimal branching, kontinuerlig integration.

   • GitFlow: Struktureret model med master, develop, feature-, release- og hotfix-branches.

3. Definér politikker og governance

   • Branch naming conventions

   • Pull request/code review regler

   • Testkrav (automatisk regressionstest, enhedstest, build pipelines)

4. Etabler integration med test

   • Automatiseret testkørsel på pull requests

   • Miljøer koblet til specifikke branches (feature miljøer, staging)

   • Testdata og konfigurationsstyring tilpasset branching-strategien

5. Monitorering og justering

   • Evaluer strategi løbende (velocity, antal integration konflikter, kvalitet af leverancer).

Fordele ved en stærk branchingstrategi

• Kontrolleret udvikling: Muliggør isolation af features og rettelser uden at forstyrre hovedlinjen.

• Forudsigelig test: Testteamet kan fokusere på stabiliserede branches fremfor ustabile integrationer.

• Risikoreduktion: Kritiske fejl kan håndteres separat (hotfix-branching).

• Skalerbarhed: Bedre understøttelse af store teams og parallelle releases.

• Spårbarhed: Lettere at dokumentere og rapportere status pr. branch.

Faldgruber

• Overkompleksitet: For mange branches skaber overhead og forsinker integration.

• "Integration hell": Forsinket sammenfletning fører til konflikter og uforudsigelig adfærd.

• Manglende testautomatisering: Branching mister sin værdi hvis test ikke er integreret i pipelines.

• Fejlfokus: Fokus på branch-struktur fremfor kvalitet og flow.

• Langlivede branches: Jo længere en branch lever isoleret, jo højere er integrationsrisikoen.

Risici for testmanagers

• Uklare releasekandidater: Risiko for at test udføres på forkerte branches.

• Miljømismatch: Ustabilitet når testmiljøer ikke matcher branches korrekt.

• Skjult teknisk gæld: Branching kan skjule midlertidige workarounds eller ufuldstændige tests.

• Afhængighed af governance: Hvis udviklerne ikke følger brancheregler, mister strategien sin værdi.

• Compliance-problemer: I regulerede miljøer (fx ISO 29119 eller ISO 27001) kan ukontrolleret branching bryde audit-sporbarhed.

Konklusion

En god branchingstrategi er ikke kun et udviklingsanliggende – den er afgørende for testmanageren. Strategien skal balancere fleksibilitet og kontrol, understøtte kontinuerlig test, og minimere risiko for integration hell. For testmanageren er nøglen at være med i design og governance af strategien, sikre at testautomatisering og miljøer understøtter branchingen, og løbende evaluere effekten på kvalitet og releasehastighed.

Hvorfor statisk test i form af reviews er en god idé

Indledning

Som testmanager har du ansvaret for at sikre kvaliteten gennem hele udviklingsprocessen. Ofte tænker vi på test som noget, der sker dynamisk – når softwaren kører. Men statisk test, især i form af reviews, er en undervurderet disciplin, der kan forebygge fejl langt tidligere. Det handler ikke kun om at finde bugs, men om at forbedre kvaliteten af krav, design og kode, før de bliver dyre at rette.

Fremgangsmåde for reviews

Et review er en struktureret gennemgang af artefakter (krav, testcases, design, kode), uden at køre softwaren. Ifølge ISO/IEC 1028 findes flere typer:

• Walkthroughs – uformelle gennemgange med forfatter og kolleger.

• Technical reviews – mere strukturerede, med eksperter som gennemgår tekniske detaljer.

• Inspections – højt formaliseret metode, ofte med checklister og definerede roller (forfatter, moderator, læser, recorder).

En typisk reviewproces indeholder:

1. Planlægning – identificér scope, deltagere, og reviewteknik.

2. Forberedelse – deltagere læser materialet og forbereder kommentarer.

3. Reviewmødet – diskussion og identifikation af problemer.

4. Rework – forfatteren retter fundne fejl.

5. Opfølgning – sikring af at fejlene er adresseret.

I moderne praksis ser vi også asynkrone reviews via værktøjer som GitHub/GitLab pull requests eller Confluence-kommentarer, hvilket kan være mere effektivt.

Fordele

• Tidlig defekt-detektion: Fejl i krav eller design kan findes før kodning, hvor omkostningen ved at rette er markant lavere.

• Forbedret kommunikation: Reviews fremmer tværfaglig dialog mellem udviklere, testere og forretning.

• Kvalitetsforbedring af artefakter: Bedre krav → bedre tests → bedre produkt.

• Træning og vidensdeling: Yngre teammedlemmer lærer af erfarne kolleger.

• Dokumenteret compliance: Inspections er særligt nyttige i regulerede domæner (f.eks. finans, healthcare).

• Reduceret testbyrde senere: Mindre behov for tidskrævende dynamisk test, når åbenlyse fejl er sorteret fra.

Ulemper og faldgruber

• Ressourcekrævende: Kræver tid fra flere roller, hvilket kan virke tungt i travle projekter.

• Kulturbarrierer: Nogle opfatter reviews som kritik frem for hjælp, hvilket kan hæmme åbenhed.

• Overformaliseret proces: Inspections kan blive bureaukratiske, hvis de ikke tilpasses organisationens modenhed.

• Fokus på småfejl: Risiko for at hænge sig i detaljer frem for at sikre de væsentligste kvalitetsaspekter.

• Manglende opfølgning: Hvis rework ikke gennemføres, mister reviewet sin effekt.

Moderne trends

• AI-assisterede reviews: Værktøjer som ChatGPT-plugins til kode- eller kravreviews kan accelerere processen og fange mønstre, mennesker overser.

• Integreret i DevOps pipelines: Automatiske statiske analyser kombineret med menneskelige reviews giver dobbelt værdi.

• Hybridmodeller: Kombination af letvægts peer reviews og formelle reviews, afhængig af risiko og artefaktets kritikalitet.

Konklusion

For en testmanager er det afgørende at sikre kvalitet så tidligt som muligt. Statisk test i form af reviews er en effektiv investering, der reducerer defekter, styrker samarbejde og mindsker risici. Ja, det kræver tid og disciplin, men gevinsten i reducerede fejlomkostninger og forbedret teamviden overstiger langt indsatsen.

Systemtest – Et centralt trin i kvalitetssikringen

Hvad er systemtest?

Systemtest er en testniveauaktivitet, hvor hele det integrerede system valideres mod de specificerede krav (funktionelle og ikke-funktionelle). Den udføres normalt efter integrationstest og før accepttest. Fokus er helheden – hvordan systemet opfører sig i et realistisk miljø, og hvorvidt det lever op til kvalitetskarakteristika defineret i fx ISO 25010 (funktionalitet, pålidelighed, ydeevne, brugervenlighed osv.).

For testmanagers er systemtest et strategisk knudepunkt: her bekræftes både produktets modenhed og organisationens evne til at levere et konsistent og pålideligt resultat.

Fremgangsmåde i systemtest

En struktureret fremgangsmåde kan opdeles i følgende trin:

1. Planlægning

   • Definér scope, teststrategi, testdata og miljøer.

   • Afstem forventninger med projektledelse og interessenter.

   • Dokumentér i testplan (jf. ISO/IEC/IEEE 29119-3).

2. Design og forberedelse

   • Udarbejd testcases baseret på kravspecifikation, user stories, use cases eller modeller.

   • Prioritér ud fra risikobaseret tilgang.

   • Opsæt testmiljø med realistiske data og konfigurationer.

3. Eksekvering

   • Udfør testcases (manuelt eller automatiseret).

   • Registrér resultater og afvigelser i test management-værktøjer.

   • Overvåg dækningsgrad og kvalitet af testdata.

4. Evaluering og rapportering

   • Sammenstil fund, fejlrapporter og dækningsanalyser.

   • Rapportér status til interessenter med fokus på risici, åbenstående defekter og systemets release-parathed.

   • Brug metrikker (fx fejl pr. testfase, kravdækning, testautomatiseringsgrad).

Tilgange til systemtest

Testmanageren kan vælge eller kombinere tilgange afhængigt af projektets natur:

• Funktionsbaseret test
  Testcases udarbejdes direkte fra krav eller use cases.

• Risikobaseret test
  Ressourcer fokuseres på systemdele med størst forretningskritisk betydning eller højeste sandsynlighed for fejl.

• Modelbaseret test (MBT)
  Brug af UML, tilstandsmaskiner eller lignende til automatisk at generere testcases.

• Automatiseret regressionstest
  Anvendes til stabilisering af systemet og sikring af, at ændringer ikke introducerer fejl.

• Non-funktionel test
  Fokus på ydeevne, sikkerhed, brugervenlighed, kompatibilitet og tilgængelighed.

• AI-understøttet test (ny trend)
  Brug af ML-modeller til at prioritere testcases, forudsige risikoområder og optimere testdata.

Fordele og ulemper

Fordele

• Helhedsvurdering: Bekræfter at hele systemet fungerer i et produktionslignende miljø.

• Risikoreduktion: Identificerer kritiske defekter før levering.

• Kravdækning: Sikrer at både funktionelle og ikke-funktionelle krav valideres.

• Kommunikation: Skaber fælles referencepunkt for projektledelse, udvikling og forretning.

Ulemper

• Ressourcekrævende: Kræver ofte komplekse miljøer og store mængder testdata.

• Sen feedback: Fejl findes sent i livscyklussen, hvilket gør dem dyrere at rette.

• Afhængigheder: Testen er afhængig af at alle komponenter er integrerede og stabile.

• Flaskehals: Kan blive kritisk flaskehals i release-processen, hvis planlægning ikke er agil.

Perspektiv for testmanagers

For en testmanager handler systemtest ikke kun om at udføre testcases, men om styring af kvalitet som helhed. Nøglen er at kombinere klassiske tilgange med moderne praksisser som CI/CD, automatisering og AI.

En best practice er at integrere systemtest løbende i en pipeline (shift-left/shift-right), så feedback kommer hurtigere, og defekter ikke ophobes.

Konklusion

Systemtest er et essentielt værktøj i testmanagerens arsenal. Det giver en samlet vurdering af systemets modenhed og release-parathed, men kræver omhyggelig planlægning, risikostyring og effektiv brug af værktøjer. Ved at balancere strukturerede metoder med nye teknologier kan testmanagers maksimere værdien af systemtest.

Accepttest – fra teori til praksis

Hvad er formålet med accepttest?

Accepttest (ofte benævnt User Acceptance Testing – UAT) er den endelige testaktivitet, der validerer, om et system lever op til forretningsmæssige behov, aftalte krav og kontraktlige forpligtelser. Formålet er at give forretningen, kunder eller brugere sikkerhed for, at løsningen er klar til drift. For testmanagers er accepttesten dermed et centralt led mellem udvikling og forretningsmæssig godkendelse.

Vigtige mål:

• Bekræfte at krav og brugerhistorier er korrekt implementeret.

• Sikre at løsningen understøtter reelle forretningsprocesser.

• Bygge tillid til systemets stabilitet og kvalitet.

• Afklare ansvar for "go/no-go"-beslutninger.

Fremgangsmåder for accepttest

Metoden for accepttest varierer afhængigt af udviklingsmodel og organisationens modenhed, men generelle tilgange omfatter:

1. Traditionel tilgang (V-model e.lign.)

   • Krav- og designbaseret test.

   • Testcases udarbejdes på baggrund af kontrakt og detaljerede specifikationer.

   • Testteam faciliterer, mens forretningen udfører test.

2. Agil tilgang (Scrum/SAFe)

   • Acceptkriterier defineres for hver user story.

   • Testcases (eller eksempler/scenarier) udvikles iterativt sammen med Product Owner.

   • "Definition of Done" omfatter fuldført accepttest.

3. DevOps/Continuous Delivery

   • Automatiserede business-facing (Agile testkvadranter) tests indgår i CI/CD pipelines.

   • Hurtig feedback til både udvikling og forretning.

   • Brug af syntetiske eller produktionsnære data.

4. Hybrid tilgang

   • Ofte nødvendigt i større organisationer, hvor kontraktlige forpligtelser (fx offentlig sektor) kombineres med agil levering.

Udfordringer for testmanagers

Som testmanager er det væsentligt at håndtere de klassiske udfordringer:

• Ejerskab: Forretningen skal eje og drive accepttesten – men ofte mangler tid og ressourcer.

• Forventningsafstemning: Krav kan være uklare eller ændrede undervejs.

• Testdata og miljøer: Tilgængelighed og kvalitet af realistiske data er ofte en barriere.

• Brugerkompetencer: Business-testere kan mangle erfaring med struktureret test.

• Tidsrammer: Accepttest presses ofte tidsmæssigt, hvilket reducerer kvaliteten.

• Automatisering: Vanskeligt at balancere manuel udforskning med automatiserede forretningsflows.

Risici forbundet med accepttest

Hvis accepttesten ikke gennemføres effektivt, kan det resultere i:

• Forretningsmæssige fejl i produktion: Kritiske processer understøttes ikke korrekt.

• Tab af tillid: Brugere mister tiltro til system og leverandør.

• Projektforsinkelser: Manglende godkendelse kan udskyde release.

• Øgede omkostninger: Sen fejlretning er dyrere og kan skabe driftsforstyrrelser.

• Compliance- og kontraktbrud: Særligt kritisk i regulerede industrier (fx finans, pharma, offentlig sektor).

Konklusion

Accepttest er broen mellem udvikling og forretning. For testmanagers handler succes med accepttest om klar rollefordeling, veldefinerede kriterier, god planlægning og risikostyring. I moderne agile og DevOps-miljøer er accepttest ikke blot en fase, men en integreret aktivitet, der kræver tæt samarbejde mellem IT og forretningen.

 

Agil test – muligheder og udfordringer i praksis

 Agil test er ikke blot en ændring i proces – det er en grundlæggende ændring i mindset, samarbejde og testens rolle i produktudvikling. Selvom de agile metoder har været dominerende i mange år, oplever testere stadig en række gennemgående udfordringer i implementeringen.

Hvad er agil test?

Agil test er test, der følger de agile værdier og principper som beskrevet i Agile Manifesto. Test er ikke en fase, men en integreret og kontinuerlig aktivitet, hvor testere arbejder tæt sammen med udviklere, produktejere og forretning – ofte i sprint-baserede iterationer.

Centrale principper i agil test:

• Tidlig og løbende test

• Forebyggelse frem for detektion

• Samarbejde i tværfunktionelle teams

• Kontinuerlig feedback og læring

• Fokus på forretningsværdi

“Agile testing is not about doing testing in an agile project, it’s about testing in an agile way.”
— Lisa Crispin & Janet Gregory

Typiske udfordringer ved agil test

Agil test har mange fordele, men testere støder ofte på følgende konkrete udfordringer:

1. Mangel på testinvolvering fra starten

Testere bliver stadig inddraget sent i udviklingen, selv i agile teams. Dette fører til ineffektive sprintslut-tests og manglende forebyggelse af fejl.

Løsning: Insistér på at testere deltager i backlog refinement, sprint planning og 3 Amigos sessions. Brug BDD (Behavior-Driven Development) for at formulere testbare krav tidligt.

2. Utilstrækkelig automatisering

Mange teams kæmper med testautomatisering – enten mangler den helt, eller den er ustabil og svær at vedligeholde. Dette underminerer kontinuerlig integration (CI/CD).

Løsning: Introducér testautomatisering som et delt ansvar i teamet. Start med kritisk regression og brug værktøjer som Cypress, Playwright eller Postman afhængig af kontekst.

3. Svækket testdækning og dokumentation

I jagten på agil hastighed ofres ofte testdækning og dokumentation. Dette fører til lav sporbarhed og problemer ved onboarding eller compliance-krav.

Løsning: Brug letvægtsdokumentation, fx test charter i exploratory testing eller test cases i Gherkin-syntax. Integrér testdækning i Definition of Done.

4. Roller og ansvar er uklare

I agile teams er det ofte uklart, hvem der "ejer" test. Dette kan føre til overlappende eller manglende ansvar og lav kvalitet.

Løsning: Klargør roller via en RACI-model eller Definition of Ready/Done. Sørg for at alle forstår, at kvalitet er et fælles ansvar.

5. Manglende teststrategi

Agile teams undervurderer ofte behovet for en samlet teststrategi, især ved komplekse løsninger, integrationer eller ved skift mellem teams.

Løsning: Udarbejd en agil teststrategi som levende dokument. Brug testtyper (unit, integration, UAT) og teknikker (risikobaseret test, exploratory test) systematisk.

Eksempler fra virkeligheden

• SAFe-setup: En tester i et SAFe ART-team etablerede en automatisk regressionspakke med Robot Framework og reducerede fejl ved release med 70 % over 3 måneder.

• Scrum-team uden testerrolle: Et team, der forsøgte "developer-only testing", måtte tilbageføre løsninger grundet manglende testdækning – de genindførte testkompetencer i teamet.

• BDD adoption i eCommerce: Overgang til Gherkin-formulerede krav forbedrede kommunikationen med Product Owner og halverede fejl i produktion.

Konklusion

Agil test handler om mere end at teste hurtigt – det handler om at teste intelligent og samarbejde hele vejen. Udfordringer opstår især, når de agile principper ikke omsættes til praksis for test. En professionel tester i det agile setup er ikke kun udførende, men også rådgiver, facilitator og garant for forretningsværdi.

 

Brug af Mendelows Matrix i Testledelse

I enhver testaktivitet – fra agil udvikling til store vandfaldsprojekter – er interessenterne ofte den afgørende faktor for succes. Uanset om det handler om godkendelse af teststrategi, prioritering af defekter eller accept af testresultater, spiller samarbejdet med interessenter en central rolle.

Men hvordan sikrer du som testmanager, at du kommunikerer med de rigtige personer på det rigtige tidspunkt i det rigtige omfang?

Svaret er: Mendelows Magt-Interesse Matrix.

Formålet med Magt-Interesse Matrixen

Formålet med Mendelows matrix er at:

• Kortlægge interessenter efter deres indflydelse (magt) og engagement (interesse) i testindsatsen.

• Understøtte en målrettet kommunikations- og involveringsstrategi for hver interessent.

• Minimere risikoen for overraskelser, flaskehalse og modstand.

• Optimere allokering af tid og ressourcer til interessenthåndtering.

Matrixen anvendes typisk under testplanlægningen, men bør justeres løbende, især ved ændringer i organisation, risiko eller testomfang.

Fremgangsmåde: Sådan anvendes matrixen i praksis

1. Identificér interessenterne

Start med at opstille en liste over relevante aktører, fx:

• Produktansvarlige

• Udviklingsteam

• UAT-brugere

• Support/Drift

• Leverandører

• Compliance/legal

• IT-sikkerhed

2. Vurder magt og interesse

Overvej følgende spørgsmål:

• Har de beslutningskompetence ift. testomfang, godkendelse eller budget?

• Har de en høj grad af engagement, fx fordi testresultatet påvirker deres daglige arbejde?

3. Placer interessenter i matrixen

Matrixen inddeler interessenter i fire felter:

Magt	Interesse	Strategi
Høj	Høj	Tæt samarbejde
Høj	Lav	Hold tilfredse
Lav	Høj	Hold informerede
Lav	Lav	Overvåg kun lejlighedsvis

4. Tilpas kommunikation og involvering

For hvert felt, overvej:

• Hvor ofte og i hvilken form skal der kommunikeres?

• Skal de inddrages i risikovurdering, testdesign eller review af resultater?

Eksempler: Brug af matrixen i testprojekter

Interessent	Magt	Interesse	Kategori	Strategi
Produktansvarlig	Høj	Høj	Tæt samarbejde	Ugentlige statusmøder, beslutningsinput
IT-drift	Høj	Lav	Hold tilfredse	Kvartalsvise opdateringer, risikoafdækning
UAT-brugere	Lav	Høj	Hold informerede	Workshops, early feedback på testcases
Juridisk afdeling	Lav	Lav	Overvåg lejlighedsvis	Involveres kun ved ændringer i compliance

Gevinster for testmanagers

Ved at anvende matrixen kan testmanagers:

• Fokusere deres tid og energi på de mest kritiske relationer.

• Øge sandsynligheden for accept af testresultater og releases.

• Forbedre risikostyring gennem rettidig involvering af nøgleinteressenter.

• Minimere kommunikationsstøj og misforståelser.

Typiske faldgruber – og hvordan du undgår dem

Udfordring	Løsningsforslag
Interessenters position ændrer sig	Revider matrixen ved større ændringer i projekt eller scope
Usynlige “magtspillere”	Brug interviews og observation for at identificere uformel indflydelse
For mange kategoriseres som “tæt samarbejde”	Prioritér – ellers drukner du i kommunikation
Ingen opfølgning på strategien	Integrer matrixen i testplan og kommunikationsplan (jf. ISO 29119-3)

Afslutning

Mendelows Magt-Interesse Matrix er et enkelt, men stærkt værktøj for testmanagers, der vil arbejde proaktivt med stakeholder management. Den giver overblik, skaber struktur og sikrer, at ingen vigtige aktører overses – eller får for lidt opmærksomhed.

Ved at anvende matrixen fra projektets start og tilpasse den løbende, kan du som testmanager sikre fokus, fremdrift og forankring i dine testinitiativer.