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.

 

Det fortsatte behov for manuel test i en automatiseret æra

I takt med at automatisering har udviklet sig til en hjørnesten i moderne softwareteststrategier, fristes mange til at tro, at manuel test er på vej ud. Men virkeligheden er mere nuanceret. For testmanagers er det afgørende at forstå, kommunikere og balancere værdien af manuel test i et landskab domineret af automatiseringsværktøjer og CI/CD-pipelines.

Automatisering er et værktøj, ikke en erstatning

Testautomatisering er uvurderlig i regressionstest, performance-tests og gentagne valideringer. Men automatisering:

• kan kun validere det, vi har specificeret og forudset

• fanger ikke let uventet adfærd, brugeroplevelse eller kontekstuelle fejl

Derfor opstår der et stort behov for menneskelig intuition og kontekstforståelse, især i følgende scenarier:

Scenarie	Manuel test er kritisk fordi...
Exploratory Testing	Kun mennesker kan opdage uventet adfærd gennem nysgerrig udforskning
Usability & Accessibility	Vurdering af brugeroplevelse kræver empati og menneskelig dømmekraft
Ny funktionalitet	Nye features har endnu ikke stabile scripts, og krav er ofte ufuldstændige
Visuelle ændringer	Subtile UI-ændringer overses ofte af automatiserede visual diff-værktøjer
Kritiske fejl under tidspres	Hurtig, manuel verifikation er ofte hurtigere end script-debugging

“Automatisering er som en metaldetektor. Den finder det, den er bygget til – men ikke nødvendigvis det farlige, skjulte objekt.”

Casestudie: Automatiseret regression ≠ total sikkerhed

I en e-commerce-virksomhed blev et nyt rabatsystem implementeret. Regressionstests var grønne – men manuel test opdagede, at rabatter fejlagtigt blev anvendt på gavekort, hvilket havde alvorlige forretningsmæssige konsekvenser. Automatiseringsscripts validerede kun “prisopdateringer”, ikke den forretningslogiske sammenhæng.

Denne case illustrerer:

• Testautomatisering kontrollerer det syntaktisk korrekte, ikke det semantisk rigtige

• Forretningsviden og domæneindsigt er ofte uden for rækkevidde for scripts

Strategisk balance: Hvornår man skal (og ikke skal) bruge manuel test

Når manuel test bør prioriteres:

• I early testing for ny funktionalitet

• Under acceptancetest med forretningsbrugere

• Ved risikobaseret test af high-impact funktioner

• I forbindelse med compliance og audit trail-kontrol

Når automatisering dominerer:

• Gentagne regressionstests

• API-tests med stabile endpoints

• Performance/load-test

• Langsigtet dokumentation af testresultater

Det handler ikke om enten eller, men om samarbejde og strategisk anvendelse.

Trends og AI: En ny æra – men ikke uden mennesker

AI-drevne testværktøjer som Copilot, Testim, og Mabl har reduceret behovet for visse manuelle opgaver. Men de kræver stadig:

• Menneskelig review af genererede test cases

• Beslutningstagning om hvad der skal automatiseres

• Håndtering af bias og ufuldstændige træningsdata

Desuden: Mange AI-værktøjer genererer tests ud fra kode – ikke krav. Dermed risikerer man at misse mismatch mellem krav og implementering.

Hvordan testmanagers bør agere

1. Kommunikér værdien af manuel test til ledelse og teams

   • Brug eksempler, hvor automation ikke var nok

   • Forklar hvordan manuel test bidrager til kvalitet ud over "bare grønne tests"

2. Opdel testtyper efter egnethed

   • Skab et testdækningsoverblik med klar differentiering mellem automatiserbare og menneskekrævende tests

3. Træn teamet i exploratory testing og domæneforståelse

   • Manuel test skal være kvalificeret, ikke "klik og håb"

4. Integrér manuel test i DevOps-pipelinen

   • Lav checkpoints i workflow, hvor manuelle vurderinger er nødvendige (fx feature flags, Go/No-Go gates)

Konklusion

Manuel test er ikke “gammeldags” – den er målrettet, menneskelig og kritisk i kontekster, hvor automatisering ikke kan forstå helheden. Som testmanager er din rolle at sikre den rigtige kombination af automation og menneskelig indsigt – og at kommunikere værdien af begge til stakeholders.