Teststyring: Fundamentet for effektiv kvalitetskontrol

Teststyring er en disciplin, der sikrer planlægning, udførelse og overvågning af testaktiviteter med fokus på kvalitet, fremdrift og risikominimering. Det kræver struktureret tilgang, tydelige artefakter og løbende tilpasning. Dette blogindlæg gennemgår teststyringens kerneelementer og giver konkrete pejlemærker for praksis.

Fremgangsmåde for effektiv teststyring

Teststyring følger typisk en struktureret tilgang, f.eks. baseret på ISTQB Advanced Test Manager-pensum og ISO/IEC 29119-3. Processen opdeles i følgende faser:

1. Testplanlægning

   • Udarbejdelse af teststrategi, mål, testomfang og estimering

   • Fastlæggelse af testmiljø, roller og ansvar (RACI)

   • Inddragelse af risikovurdering og afhængigheder

2. Testovervågning og -styring

   • Opfølgning på testaktiviteter via statusmøder og målinger

   • Indsamling og analyse af metrikker for fremdrift og kvalitet

   • Identifikation og iværksættelse af korrigerende handlinger

3. Konfigurationsstyring og testdata

   • Sikring af versionsstyring og sporbarhed mellem krav, tests og fejl

   • Opsætning og kontrol af testmiljø og testdata

4. Afvigelseshåndtering

   • Klassificering og prioritering af fejl

   • Håndtering af afvigelser i krav, plan eller fremdrift

5. Evaluering og afslutning

   • Testopsummering og rapportering

   • Evaluering mod testmål og acceptkriterier

   • Lessons learned og procesforbedring

Input til teststyring

Artefakt	Formål
Projektplan	Afstemning med overordnet tidsplan og ressourcer
Kravspecifikationer	Grundlag for testdesign og risikovurdering
Risikovurdering	Prioritering af testindsats og dækning
Arkitektur- og designspecifikationer	Understøttelse af systematisk testdesign og teknisk risikoanalyse
Releaseplaner og miljøoversigt	Koordinering af testcyklusser og testmiljøer

Output fra teststyring

Artefakt	Formål
Testplan	Rammesætning for alle testaktiviteter
Statusrapporter	Overblik over fremdrift, afvigelser og risici
Afvigelsesrapporter	Dokumentation af fundne fejl og uoverensstemmelser
Testafslutningsrapport	Opsummering af opnået testdækning og målopfyldelse
Lessons Learned	Input til procesforbedring og fremtidige projekter

Centrale metrikker for fremdrift

Teststyring kræver valide metrikker for at understøtte beslutningstagning. Nedenstående metrikker bør tilpasses kontekst og projekttype (ref. GQM):

Metrik	Beskrivelse	Formål
Test case execution rate	% gennemførte testcases vs. planlagte	Fremdrift
Fejltæthed (Defect Density)	Antal fejl pr. testet funktion eller KLOC	Kvalitetsindikator
Defect leakage	Fejl opdaget efter testfasen	Effektivitet af test
Test coverage	Krav eller kode dækket af tests	Dækningsgrad
Mean time to resolve defect	Gennemsnitlig fejlreparationstid	Procesmodenhed og samarbejde

Korrigerende handlinger

Ved afvigelser i fremdrift, kvalitet eller ressourcer bør testlederen:

• Replanlægge testcyklusser eller prioritere tests (scope trimming)

• Allokere ekstra ressourcer eller forstærke automatisering

• Eskalere blokeringer eller beslutningsbehov

• Gennemføre root cause-analyse (f.eks. 5 Why's) og indføre procesforbedringer

Disse handlinger bør dokumenteres og forankres i afvigelsesstyring og lessons learned.

Risikohåndtering

Risikohåndtering er integreret i teststyring og følger ofte en risikobaseret teststrategi:

Aktivitet	Beskrivelse
Identifikation	Hvilke testrelaterede risici truer kvalitet eller fremdrift? (fx ustabile miljøer, dårlige krav, teknisk kompleksitet)
Vurdering	Sandsynlighed × Konsekvens → prioritering
Mitigering	Forebyggende tiltag (tidlig test, prototyper, teknisk spike)
Overvågning	Risikoer valideres løbende gennem målinger og observationer

Risikologgen opdateres som levende dokument.

Afslutning og anbefalinger

Teststyring er mere end koordinering – det er et styringshåndværk med klare processer, dataunderstøttet beslutningstagning og løbende tilpasning. Brugen af internationalt anerkendte standarder (f.eks. ISO/IEC 29119) og metoder (ISTQB, GQM, risikobaseret test) sikrer en solid og skalerbar teststyringsproces.

Næste skridt:

• Tilpas metrikker og testplan til jeres konkrete projekt og modenhedsniveau

• Sørg for at risiko- og fejlstyring indgår i den daglige opfølgning

• Udnyt Lessons Learned og retrospektiver til at modne teststyringen løbende
  
  

Sådan udarbejder du en effektiv testpolitik – En praktisk guide baseret på ISO 29119

I en verden med stigende kompleksitet, højere regulatoriske krav og et voksende fokus på kvalitet og risikostyring, bliver behovet for en formel testpolitik stadig vigtigere. En testpolitik er ikke blot et dokument – det er et styringsværktøj, der forankrer testindsatsen i organisationens overordnede strategi og sikrer konsistens, transparens og målopfyldelse.

Denne artikel guider dig gennem, hvordan du udarbejder en testpolitik med afsæt i ISO 29119, og hvordan du sikrer, at den skaber reel værdi.

🔍 Hvad er en testpolitik?

En testpolitik er en organisations brede erklæring om mål, principper og strategier for test. Den beskriver det overordnede formål med test, relationen til forretningsmål og kvalitetspolitikker samt grundlæggende principper for teststyring og testpraksis.

ISO 29119 definerer testpolitikken som et "test-governance dokument, der fastlægger ledelsens intentioner og retningslinjer for test i organisationen."

Fremgangsmåde – sådan gør du

1. Fastlæg scope og interessenter

• Identificer hvem testpolitikken gælder for: hele organisationen, en afdeling, eller et specifikt domæne.

• Involver nøgleinteressenter: testledere, QA, forretningsledelse, projektledere, compliance.

2. Indhent og analyser input

Inputkilde	Beskrivelse
Kvalitetspolitik	Overordnet organisatorisk strategi for kvalitet og compliance.
Forretningsmål	Særligt ift. time-to-market, risikovillighed og kundekrav.
Eksisterende teststrategier	Giver kontekst og mulighed for harmonisering.
Risikoanalyse	Definerer behovet for testniveauer, testdybde og governance.
Udviklingsmodeller	F.eks. DevOps, SAFe, V-model – påvirker testtilgang.
Lovgivning og standarder	F.eks. ISO 27001, GDPR, FDA, ISTQB Foundation, Advanced, Expert.
Modenhedsniveau	TMMi/TPI NEXT vurdering anbefales som baseline.

3. Udarbejd politikken

Følgende struktur er anbefalet (baseret på ISO 29119):

Sektion	Indhold
1. Formål	Hvorfor testpolitik er nødvendig, og hvad den skal opnå.
2. Omfang	Afgrænsning af organisatorisk scope.
3. Definitioner og referencer	Terminologi og kobling til standarder.
4. Testprincipper	F.eks. risiko-baseret test, early testing, automation first.
5. Roller og ansvar	Hvem ejer politikken, og hvem efterlever den.
6. Retningslinjer for teststyring	Strategisk tilgang til teststyring og dokumentation.
7. Måling og forbedring	Hvordan effekten af test evalueres.
8. Revisions- og vedligeholdelsesplan	Frekvens og ansvar for opdatering.
9. Godkendelse og publicering	Formel godkendelse fra ledelsen.

Typiske risici og hvordan du håndterer dem

Risiko	Konsekvens	Afhjælpning
For bredt eller vagt formuleret	Politikken bliver irrelevant eller ubrugelig	Skab tydelige scope-afgrænsninger og målbare principper
Manglende forankring i organisationen	Ingen efterlevelse eller kendskab	Inddrag ledelse og testansvarlige i formulering og udrulning
Konflikt med eksisterende politikker	Inkoherens og forvirring	Koordiner med QA og governance-funktioner
Ingen opfølgning	Politikken bliver forældet	Indbyg KPI'er og audits (f.eks. via intern test review board)

Forankring og vedligeholdelse

En testpolitik er kun effektiv, hvis den:

1. Er godkendt af ledelsen.

2. Kommunikeres bredt i organisationen.

3. Integreres i teststrategier og testplaner.

4. Følges op gennem audits, retrospektiver og kvalitetsmålinger.

Tænk testpolitikken som en levende del af kvalitetsledelsessystemet – ikke et statisk dokument.

Eksempel på principper i en moderne testpolitik

• "Alle tests skal planlægges og dokumenteres i overensstemmelse med ISO/IEC/IEEE 29119-3."

• "Testautomatisering skal evalueres som standard for alle nye projekter."

• "Test skal tilpasses risikoprofiler for komponenter og systemer."

• "Testdata skal følge gældende regler for databeskyttelse (f.eks. GDPR)."

Konklusion og anbefalinger

En veldesignet testpolitik skaber alignment, sikrer governance og styrker kvaliteten. Den bør være tilpasset både organisationens modenhed og kontekst.

Anbefalinger:

• Brug ISO 29119 som ramme.

• Involver relevante interessenter.

• Skab målbare principper.

• Tænk vedligehold fra starten.
  
  

SWOT-analyse i test og testmanagement – Strategisk overblik og retning

Introduktion til SWOT-analysen

SWOT er en klassisk strategisk analysemodel, der identificerer fire centrale områder i en organisation, et projekt eller en proces:

• Strengths (Styrker) – Hvad gør vi godt?

• Weaknesses (Svagheder) – Hvad kan forbedres?

• Opportunities (Muligheder) – Hvilke eksterne faktorer kan vi udnytte?

• Threats (Trusler) – Hvilke risici eller udfordringer truer vores succes?

Modellen er især velegnet som beslutningsstøtte i planlægning, risikostyring og strategiformulering. Den giver et helikopterperspektiv og egner sig til både workshops og individuelle analyser.

Anvendelse af SWOT i test og testmanagement

1. Teststrategi og testplanlægning

Ved udarbejdelse af teststrategi (jf. ISO 29119 og ISTQB Test Management) anvendes SWOT til at:

• Identificere styrker i testteamets kompetencer, værktøjer og processer

• Afsløre interne begrænsninger (fx utilstrækkelig testdata, teknisk gæld)

• Spotte eksterne muligheder (fx automatisering, shift-left, AI-støtteværktøjer)

• Vurdere trusler (fx stramme deadlines, afhængighed af 3. parter)

Eksempel: I et DevOps-miljø kan en SWOT fremhæve stærke CI/CD pipelines (S), men også afsløre manglende test i release-noter (W), og en mulighed i at indføre “Feature Toggles” (O), mens øget kompleksitet i microservices-arkitekturen udgør en trussel (T).

2. Testprocesvurdering og modenhed

SWOT anvendes i forbindelse med vurdering af testmodenhed (fx TMMi, TPI NEXT) til at supplere kvantitative data:

• Komplementerer GQM (Goal-Question-Metric)

• Afklarer organisatorisk modstand, ressourcemangel, eller politiske barrierer

Eksempel: Under en TMMi-assessment på niveau 2 viste en SWOT-analyse, at testteamet havde høj domæneviden (S), men ingen dokumenteret testproces (W), mens der var ledelsesopbakning til procesforbedringer (O), men også risiko for personaleudskiftning (T).

3. Kommunikation med interessenter

SWOT-analyse er et fremragende værktøj i dialog med projektledere, udviklingsledere og forretning:

• Skaber fælles forståelse af testens rolle og behov

• Giver grundlag for prioritering og forhandling

Styrker og svagheder ved SWOT-modellen i test

Styrker	Svagheder
Let at forstå og anvende	Kan blive for overfladisk uden opfølgning
Styrker refleksion og helhedstænkning	Subjektiv – afhænger af deltageres erfaring og åbenhed
Godt til workshops og teamalignment	Kræver analyseforankring for at føre til handling
Kan kobles med risikoanalyse og teststrategi	Ofte manglende kvantificering af faktorer

Praktisk eksempel: SWOT-analyse i testprojekt

Projekt: Udrulning af ny selvbetjeningsløsning til borgere

SWOT-element	Indhold
Strengths	Erfarent testteam med domænekendskab; god regressionstest-suite
Weaknesses	Manglende performance testmiljø; afhængighed af legacy-systemer
Opportunities	Mulighed for at introducere AI-baseret testdata-generering; stærk opbakning fra ledelse
Threats	Kort frist og afhængighed af eksternt API; potentiel modstand fra supportafdeling

➡ Denne analyse dannede grundlag for en teststrategi med fokus på risikoafdækning, prioriteret testdesign og tidlig involvering af slutbrugere.

Tips til brugen af SWOT i testledelse

1. Involver tværfaglige interessenter – testere, udviklere, PO’er og drift

2. Facilitér aktivt – stil åbne spørgsmål og giv eksempler

3. Brug whiteboards eller digitale værktøjer (fx Miro, LucidSpark)

4. Kombinér med risikoanalyse (fx ISO 31000-baseret)

5. Dokumentér input og opfølgning i testplanen

Konklusion og anbefalinger

SWOT-analysen er et værdifuldt kvalitativt værktøj i testmanagement, især til:

• Strategisk planlægning og kommunikation

• Identifikation af organisatoriske og tekniske forhold

• Styrkelse af alignment i testteams og med interessenter

Brugt korrekt giver SWOT et fælles sprog og et strategisk afsæt for risikobaseret test og testmodenhedsforbedringer.

 

Testprocesforbedring – Vejen til mere moden og effektiv test

Testprocesforbedring handler om systematisk at analysere, evaluere og optimere testaktiviteter med det formål at øge effektivitet, kvalitet og forretningsværdi. For organisationer med komplekse IT-leverancer er en moden testproces ikke blot en konkurrencefordel – det er en nødvendighed.

Hvorfor testprocesforbedring?

• Øget kvalitet og forudsigelighed i leverancer

• Reducering af fejl og omarbejde

• Bedre risikostyring gennem strukturerede teststrategier

• Styrket samarbejde på tværs af IT og forretning

• Effektiv ressourceanvendelse og kontinuerlig læring

Fremgangsmåde – sådan gribes det an

En struktureret tilgang til testprocesforbedring følger typisk disse faser:

1. Opstart og forankring

   • Fastlæggelse af mål og scope

   • Identifikation af stakeholders og roller

   • Commitment fra ledelsen

2. Assessment / Baseline

   • Gennemførsel af modenhedsvurdering (fx TMMi Assessment eller TPI NEXT scan)

   • GAP-analyse: Hvad er forskellen mellem "as-is" og "to-be"?

3. Analyse og prioritering

   • Identifikation af forbedringsområder (f.eks. teststrategi, testdesign, målinger, værktøjsunderstøttelse)

   • Forretningsmæssig prioritering (impact vs. indsats)

4. Handlingsplan og implementering

   • Udarbejdelse af realistisk roadmap

   • Pilotprojekter eller trinvis implementering

5. Overvågning og tilpasning

   • Brug af målinger og retrospektiver til validering

   • Justering af indsatsen efter behov (PDCA)

Testmodenhedsmodeller: TMMi og TPI NEXT

TMMi (Test Maturity Model integration)

• Struktur: 5 modenhedsniveauer (Initial → Optimizing)

• Fokus: Procesmål, underbygget af ISO/IEC 33063

• Styrker:

  • Klar reference til IEEE/ISO-standarder

  • Velegnet til regulatoriske miljøer

• Eksempel på mål:

  • "Organizational Test Policy and Strategy"

  • "Test Planning" og "Test Monitoring & Control"

TPI NEXT

• Struktur: 16 Key Areas (fx Defect Management, Test Environment, Stakeholder Commitment)

• Fokus: Fleksibel evaluering, ofte brugt i Agile setups

• Styrker:

  • Tilpasselig til forskellige kontekster

  • Viser balance mellem controllability, efficiency og responsiveness

• Output:

  • TPI NEXT Matrix med nuværende og ønsket modenhed

  • Konkrete anbefalinger per område

Roller og ansvar i testprocesforbedring

Rolle	Ansvar
Test Manager / Quality Coach	Driver processen, faciliterer assessment og roadmap
Projektledelse	Understøtter med ressourcer og prioritering
Testanalytikere og -designere	Leverer input til forbedringsområder og deltager i implementering
Arkitekter/DevOps	Sikrer teknisk forankring af forbedringer (CI/CD, testautomatisering)
Forretningen	Bidrager til behovsafklaring og vurdering af værdi

Output fra testprocesforbedring

• Assessment-rapport med modenhedsprofil og GAP-analyse

• Forbedringsroadmap med konkrete initiativer, faser og KPI'er

• Opdaterede processer, skabeloner og værktøjer

• Målinger: Fx Defect Leakage Rate, Test Cost of Quality, Requirement Coverage

• Læring og kulturændring gennem workshops og governance

Eksempel – Virksomhed med lav defektopdagelse i test

En organisation havde høj produktionsfejlrate. En TMMi-inspireret assessment afslørede manglende struktureret testdesign og utilstrækkelig review af krav. Efter forbedring af testplanlægningsprocessen og indførelse af parvis testdesign faldt antallet af produktionsfejl med 40%.

Konklusion og næste skridt

Testprocesforbedring er ikke et engangsprojekt, men en kontinuerlig rejse. Uanset om du bruger TMMi, TPI NEXT eller en skræddersyet tilgang, er nøgleordene: struktur, forankring og måling. Det handler ikke kun om at teste bedre – men om at skabe bedre software.

 

ADKAR: En målrettet metode til varig forandring i organisationer

Forandring er ikke længere et midlertidigt vilkår – det er et permanent grundvilkår. For at imødekomme dette, må organisationer gå systematisk og menneskeligt til værks. Her tilbyder ADKAR-modellen (af Prosci) en praksisnær, struktureret og evidensbaseret tilgang til individuel og organisatorisk forandring.

Hvad er ADKAR-modellen?

ADKAR er en forkortelse for Awareness, Desire, Knowledge, Ability og Reinforcement. Modellen fokuserer på de menneskelige aspekter af forandring, idet forandringer i organisationer kun lykkes, når de lykkes hos individerne.

Komponent	Formål
Awareness	Skabe forståelse for nødvendigheden af forandringen
Desire	Skabe vilje og motivation til at deltage i forandringen
Knowledge	Sikre viden om, hvordan man gennemfører forandringen
Ability	Understøtte evnen til at anvende ny viden og adfærd
Reinforcement	Fastholde forandringen og forhindre tilbagefald

Fremgangsmåde: Sådan anvendes ADKAR i praksis

1. Foranalyse og kortlægning

   • Analyse af forandringens art, interessenter, og potentielle modstand.

   • Fastlæggelse af forandringsmål og forventet adfærdsændring.

2. Diagnosticering (ADKAR-vurdering)

   • Gennemførelse af en ADKAR-assessment på målgrupper.

   • Identifikation af svageste led i ADKAR-kæden – her skal indsatsen starte.

3. Planlægning og interventioner

   • Udvikling af målrettede aktiviteter til hver komponent:

     • Awareness → kommunikationsstrategier

     • Desire → ledelsesengagement, incitamenter

     • Knowledge → træning, e-learning

     • Ability → coaching, praksistræning

     • Reinforcement → belønning, anerkendelse, måling

4. Implementering og monitorering

   • Rulles ud som en integreret del af projekt- eller transformationsforløb.

   • Løbende justering baseret på feedback og målinger.

5. Evaluering og forankring

   • Måling af ændret adfærd og resultater.

   • Dokumentation og læring til fremtidige forandringsprojekter.

Output og resultater

Output-type	Eksempel
Individniveau	Forståelse, ejerskab, nye kompetencer, vedvarende adfærdsændringer
Organisationsniveau	Øget forandringsparathed, succesfuld implementering af strategiske projekter, reduceret modstand
Ledelsesniveau	Klarere kommunikation, bedre interessenthåndtering, KPI-opfølgning på forandringseffekt

Styrker ved ADKAR

• Menneskecentreret tilgang – fokuserer på individets rejse gennem forandring.
• Struktureret og målbar – giver klare indikatorer og mulighed for statusmåling.
• Skalerbar – kan anvendes i små teams såvel som globale organisationer.
• Kompatibel med andre modeller – fungerer godt sammen med Kotter, Lewin, Agile Change Management mv.
• Praktisk og værktøjsbaseret – understøttet af Prosci-materialer, assessments og træning

Svagheder og faldgruber

• Kræver organisatorisk modenhed – ledere skal være aktive sponsorer.
• Kan virke mekanisk uden kulturforståelse – relationelle aspekter må ikke negligeres.
• Ignorerer delvist systemiske faktorer – f.eks. organisatorisk struktur, incitamenter og magtforhold.
• Ressourcekrævende at implementere korrekt – især ved komplekse transformationer.

ADKAR i praksis: Eksempel

Case: Offentlig digitaliseringsrejse
En kommune skal indføre et nyt sagsbehandlingssystem. ADKAR anvendes til at identificere:

• Lav awareness hos medarbejdere: tiltag → workshops og nyhedsbreve.

• Lav ability: tiltag → hands-on træning og superbrugerordning.

• Lav reinforcement: tiltag → ledelsesopfølgning, anerkendelse af succesfuld anvendelse.

Resultat: 85 % adoption inden for 3 måneder, markant fald i fejlmeldinger, højere brugerengagement.

Sammenligning med andre modeller

Model	Fokus	Sammenhæng med ADKAR
Kotter	Organisationens faser i forandring	ADKAR fokuserer mere på individet
Lewin	"Unfreeze-Change-Refreeze"	ADKAR detaljerer individets rejse
Bridges	Psykologisk overgang	ADKAR mere operationel og målbar

Konklusion

ADKAR er en effektiv og evidensbaseret metode til at sikre, at organisatoriske forandringer bliver adopteret, internaliseret og fastholdt. Dens menneskefokus, systematik og målelighed gør den særligt velegnet til komplekse forandringer, hvor individets motivation og evne er afgørende.

Men: succes kræver bevidst anvendelse, ledelsesopbakning og kulturforståelse. ADKAR er ikke en "plug-and-play"-løsning, men et rammeværk, der skal tilpasses og integreres i den organisatoriske virkelighed.

 

Samarbejdet mellem testmanager og projektleder – udfordringer og løsninger

Introduktion

Et velfungerende samarbejde mellem testmanager og projektleder er afgørende for at sikre en succesfuld leverance og en tilfredsstillende kvalitet i softwareprojekter. Mens projektlederen fokuserer på at levere til tiden, inden for budgettet og med de rette funktionaliteter, har testmanageren ansvar for at sikre kvaliteten gennem teststrategi, risikostyring og testgennemførelse.

Selvom disse roller supplerer hinanden, kan de også føre til interessekonflikter. Hvordan kan testmanageren og projektlederen navigere i disse udfordringer og opnå et produktivt samarbejde?

Typiske udfordringer i samarbejdet

1. Forskellige fokusområder

• Eksempel: I et ERP-implementeringsprojekt havde projektlederen et skarpt fokus på leveringsfristen, mens testmanageren identificerede kritiske fejl, der krævede mere testtid. Uden enighed om testens værdi blev testfasen skæret ned, hvilket førte til omfattende fejl i produktion.
• Løsning: En risikobaseret testtilgang kunne have hjulpet med at prioritere de mest kritiske tests uden at forsinke projektet unødigt.

2. Stramme tidsplaner og presset på testaktiviteter

• Eksempel: I en stor banks digitale transformation blev testfasen reduceret på grund af forsinkelser i udviklingen. Projektlederen pressede på for en hurtigere testafslutning, mens testmanageren insisterede på, at testdækningen ikke var tilstrækkelig.
• Løsning: Ved at involvere testteamet tidligere i projektet kunne nogle tests være automatiseret og integreret i CI/CD-processen for at undgå en presset testfase.

3. Udfordringer med risikostyring og testdækning

• Eksempel: Et softwarefirma lancerede en ny platform, hvor testmanageren advarede om manglende test af integrationspunkter. Projektlederen vurderede risikoen som lav og prioriterede andre opgaver. Ved release viste det sig, at systemet ikke kunne kommunikere korrekt med kundernes eksisterende systemer.
• Løsning: Enighed om en risikostyringsstrategi og en formel risikoanalyse kunne have forhindret denne fejl.

4. Kommunikation og forventningsafstemning

• Eksempel: I et internationalt projekt med teams i forskellige tidszoner blev teststatus og kritiske fejl ikke kommunikeret hurtigt nok, hvilket resulterede i en forsinket release.
• Løsning: Indførelse af daglige stand-up-møder og et transparent dashboard kunne have sikret en bedre informationsstrøm.

5. Ændringshåndtering og agile udfordringer

• Eksempel: I et Scrum-team blev kravene konstant ændret midt i sprinten, hvilket gjorde det svært for testmanageren at planlægge testaktiviteter.
• Løsning: Definition af en klar "Definition of Ready" for kravene og bedre brug af testautomatisering kunne have hjulpet.

Hvordan udfordringerne kan håndteres

1. Klare ansvarsområder og fælles målsætninger

• Aftal fra start, hvilke kvalitetskrav der skal være opfyldt, før projektet kan gøre fremskridt.

2. Regelmæssig og struktureret kommunikation

• Etabler faste ugentlige alignment-møder mellem testmanager og projektleder.

3. Risikobaseret testtilgang for bedre prioritering

• Skab et risikoheatmap sammen med projektlederen for at beslutte, hvor testen skal have mest fokus.

4. Samarbejde om testplanlægning og ressourceallokering

• Planlæg testkapacitet på samme niveau som udviklingsopgaver.

5. Involvering af test tidligt i projektet

• Brug en "shift-left"-strategi, hvor test starter allerede i kravspecifikationsfasen.

Samarbejdet i forskellige udviklingsmodeller

1. Vandfald/V-model

• Eksempel: I et offentligt IT-projekt blev testen skubbet til slutningen, hvilket resulterede i store forsinkelser, da mange fejl blev opdaget for sent.
• Løsning: Indførelse af reviews og tidlig testning kunne have reduceret de sene opdagelser.

2. Agile (Scrum, SAFe)

• Eksempel: I et Scrum-team blev test ignoreret i de første sprints, hvilket skabte teknisk gæld.
• Løsning: Implementering af testautomatisering og "Definition of Done" kunne have sikret bedre testdækning.

3. Hybridmodeller

• Eksempel: Et firma, der skiftede fra vandfald til SAFe, oplevede problemer, da testprocesserne ikke blev tilpasset de agile iterationer.
• Løsning: Testmanageren og projektlederen burde have revideret teststrategien til at matche den nye model.

Konklusion

Et godt samarbejde mellem testmanager og projektleder er nøglen til succes i ethvert softwareprojekt. Ved at forstå hinandens mål, arbejde proaktivt med kommunikation og risikostyring samt tilpasse samarbejdet til udviklingsmodellen, kan mange af de typiske udfordringer overvindes.

Uanset om det er i et klassisk vandfaldsprojekt eller et agilt SAFe-miljø, er fælles forståelse og tilpasning af strategier den bedste vej til et effektivt samarbejde – og et kvalitetsprodukt.

 

Udfordringer i Testmanagement for Forskellige Udviklingsmodeller

Introduktion

Testmanagement spiller en afgørende rolle i softwareudvikling, hvor kvalitet, risiko og effektiv testplanlægning skal sikres. Valget af udviklingsmodel har stor indflydelse på teststrategien, planlægningen og udfordringerne, som testmanagers står over for.

Dette blogindlæg belyser testmanagement-udfordringer i tre forskellige udviklingsmodeller: V-model, SAFe (Scaled Agile Framework) og Scrum/Agile. Formålet er at give testmanagers en forståelse af, hvordan testarbejdet skal tilpasses og optimeres afhængigt af udviklingsmetoden.

Testmanagement i V-modellen

V-modellen er en struktureret og sekventiel tilgang til softwareudvikling, hvor testplanlægning sker parallelt med udviklingen.

Udfordringer

1. Sen inddragelse af test – Testarbejdet starter ofte sent i projektet, hvilket kan føre til flaskehalse.
2. Tunge dokumentationskrav – Omfattende testplaner og testcases kræver betydelig tid og ressourcer.
3. Håndtering af ændringer – Da krav fastlægges tidligt, kan ændringer senere i processen være dyre og tidskrævende.
4. Afhængighed af færdigudviklet kode – Test kan først udføres, når hele systemet eller komponenter er færdigudviklet, hvilket forsinker fejlidentifikation.

Håndtering af udfordringer

• Tidlig testinddragelse – Implementering af testdrevet udvikling (TDD) og reviews i tidlige faser.
• Agil tilpasning – Introduktion af iterativ test i parallelle udviklingsfaser.
• Automatisering – Brug af testautomatisering til at reducere den manuelle testbyrde.

Testmanagement i SAFe (Scaled Agile Framework)

SAFe er en skaleret agil tilgang, der sigter mod at koordinere flere teams i store organisationer.

Udfordringer

1. Koordinering af test på tværs af teams – Sikring af testdækning på tværs af forskellige agile teams og leverancer.
2. Test i PI Planning – Manglende testinddragelse i Program Increment (PI) planning kan resultere i utilstrækkelig testdækning.
3. Automatisering og kontinuerlig test – Implementering af CI/CD kræver omfattende testautomatisering.
4. Håndtering af ikke-funktionelle krav – Ydeevne, sikkerhed og compliance kan overses i agile kontekster.

Håndtering af udfordringer

• Teststrategi på programniveau – Definere en overordnet teststrategi, der sikrer konsistens.
• Inddragelse i PI Planning – Sikre at testopgaver inkluderes i sprintplanlægningen.
• Automatisering af regressionstest – Brug af testautomatiseringsværktøjer til at opretholde kvalitet i korte iterationer.

Testmanagement i Scrum/Agile

Scrum og Agile fokuserer på iterative udviklingsmetoder med korte udviklingscyklusser.

Udfordringer

1. Testkapacitet i korte sprints – Begrænset tid til test mellem udvikling og release.
2. Manglende formel testplanlægning – Ingen traditionelle testplaner, hvilket kan føre til uensartet testdækning.
3. Regressionstest og CI/CD – Sikring af løbende kvalitet og testautomatisering.
4. Testansvar i selvorganiserede teams – Testansvaret er ofte fordelt mellem udviklere og testere, hvilket kan skabe udfordringer.

Håndtering af udfordringer

• Definition of Done (DoD) – Tydelige kvalitetskriterier for hvornår et produkt er klar til release.
• Automatisering af test – Brug af testautomatisering til at reducere manuelle opgaver.
• Shift-left testing – Tidlig testning i udviklingsprocessen for at fange fejl hurtigere.

Sammenligning og Konklusion

Forskellige udviklingsmodeller stiller forskellige krav til testmanagement:

• V-modellen kræver en struktureret og dokumentationstung tilgang, men kan optimeres med tidligere testinddragelse og automatisering.
• SAFe fokuserer på koordinering af testindsatser på tværs af teams og kræver en stærk teststrategi samt automatisering.
• Scrum/Agile kræver en fleksibel og integreret testtilgang, hvor test og udvikling smelter sammen.

For testmanagers er det afgørende at forstå og tilpasse teststrategien til udviklingsmodellen for at sikre optimal kvalitet og effektivitet i testarbejdet.

 

Risikobaseret Test – En Introduktion

Risikobaseret test (Risk-Based Testing, RBT) er en strategisk testtilgang, hvor testindsatsen prioriteres baseret på de identificerede risici for systemet. Denne metode sikrer, at testressourcer anvendes optimalt ved at fokusere på de dele af systemet, hvor fejl vil have størst konsekvens, eller hvor sandsynligheden for fejl er højest.

1. Fremgangsmåde i Risikobaseret Test

Risikobaseret test følger en systematisk fremgangsmåde, der typisk består af følgende trin:

1. Identifikation af risici

   • Risikoanalyse gennemføres ved at identificere potentielle risici for systemet.
   • Input hentes fra forretningsanalytikere, udviklere, testere og andre interessenter.
   • Kilder kan være tidligere fejl, kompleksiteten af funktionalitet, integrationspunkter, regulatoriske krav osv.

2. Vurdering af risici

   • Hver risiko vurderes ud fra:
     • Sandsynlighed: Hvor stor er chancen for, at fejlen opstår?
     • Konsekvens: Hvor alvorlig vil en fejl være, hvis den opstår?
   • Risikoen kvantificeres ved at tildele en risikoscore (ofte en skala fra 1 til 5 eller lav/middel/høj).

3. Prioritering af testindsats

   • Højrisikoområder testes grundigere og tidligere i forløbet.
   • Lavrisikoområder får mindre opmærksomhed og kan evt. testes med standard dækning.
   • Teststrategien justeres baseret på ressourcer og tidsbegrænsninger.

4. Testdesign og eksekvering

   • Testcases designes for at dække de mest kritiske risici først.
   • Der anvendes ofte teknikker som grænseværdianalyse, ekvivalenspartitionering og fejlbaseret testdesign.
   • Testdata og testmiljø tilpasses risikobilledet.

5. Overvågning og justering

   • Risikobilledet evalueres løbende, da det kan ændre sig undervejs i projektet.
   • Teststrategien tilpasses baseret på nye risici eller ændrede prioriteter.

2. Konsekvenser for Testprocessens Hovedaktiviteter

Risikobaseret test påvirker samtlige faser i testprocessen, ofte som beskrevet i ISTQB-standarden:

• Testplanlægning

  • Risikoanalyse integreres i teststrategien og testplanen.
  • Ressourcer allokeres efter risikoniveauer.
  • Testmiljøet klargøres til at dække de kritiske områder.

• Testanalyse og testdesign

  • Testtilfælde udvikles med fokus på højrisikoområder.
  • Testdækning optimeres for at sikre tilstrækkelig validering af risikofyldte funktioner.

• Testimplementering og eksekvering

  • Testudførelse prioriterer højrisikoområder først.
  • Automatisering kan anvendes for gentagne og kritiske tests.
  • Defektrapportering følger et struktureret format for at sikre hurtig opfølgning på kritiske fejl.

• Testafslutning og rapportering

  • Testresultater rapporteres i forhold til risiko, så interessenter forstår dækning og rest-risici.
  • Testafslutningsrapporten fokuserer på risikoreduktion og dokumenterer de valgte afvejninger.

3. Styrker og Svagheder ved Risikobaseret Test

Styrker

• Fokus på de vigtigste områder – Kritiske funktioner testes grundigt, hvilket mindsker sandsynligheden for alvorlige produktionsfejl.
• Effektiv ressourceanvendelse – Testindsatsen optimeres ved at investere tid og ressourcer, hvor de har størst effekt.
• Øget forretningsværdi – Sikrer, at systemets vigtigste funktioner fungerer korrekt, hvilket understøtter forretningsmål.
• Bedre risikostyring – Muliggør en objektiv prioritering af testindsatsen og skaber bevidsthed om rest-risici.
• Understøtter agil udvikling – Giver fleksibilitet ved at rette testindsatsen mod nye eller kritiske risici i løbet af udviklingsforløbet.

Svagheder

• Afhænger af korrekt risikovurdering – En fejlagtig risikoanalyse kan resultere i enten over- eller undertestning.
• Kræver kontinuerlig opdatering – Risikoer ændrer sig, og analysen skal løbende revideres for at være effektiv.
• Kan være subjektiv – Vurderingen af sandsynlighed og konsekvens kan variere mellem interessenter.
• Potentiel undervurdering af lavrisikoområder – Funktioner med lav risiko kan indeholde skjulte fejl, der først opdages sent.

4. Involvering af Interessenter

For at risikobaseret test skal være succesfuldt, skal flere interessenter involveres aktivt:

• Forretningsanalytikere – Bidrager med indsigt i forretningskritiske funktioner.
• Udviklere – Identificerer tekniske risici og systemkompleksitet.
• Testere – Bringer testekspertise og tidligere erfaring med fejltyper.
• Projektledere – Hjælper med at balancere risici, testindsats og projektmål.
• Kvalitetsansvarlige – Overvåger teststrategi og risikohåndtering på tværs af projekter.
• Brugere/kunder – Kan identificere de mest kritiske anvendelsesområder.

God kommunikation mellem interessenter er essentiel for at sikre en velafbalanceret risikoprofil.

5. Øvrige Relevante Forhold

• Integration med Agile og DevOps
  Risikobaseret test passer godt til agile metoder, hvor backlog-prioritering kan baseres på risiko. I DevOps-miljøer kan testautomation målrettes risikofyldte områder for kontinuerlig validering.

• Automatisering i Risikobaseret Test
  Automatisering bør prioriteres for højrisikoområder, især regressionstest og ydelsestest.

• Risikobaseret Test i Regulerede Brancher
  I brancher med lovgivningsmæssige krav (f.eks. finans, medicinsk udstyr, luftfart) er risikobaseret test ofte påkrævet for at sikre compliance.

Konklusion

Risikobaseret test er en strategisk og værdidrevet testtilgang, der prioriterer testindsatsen baseret på sandsynlighed og konsekvens af potentielle fejl. Det optimerer ressourceforbruget, sikrer test af kritiske områder og hjælper med at styre risici i softwareudvikling. Dog kræver det kontinuerlig overvågning, veldefinerede vurderingskriterier og aktiv involvering af interessenter for at være effektivt.

 

Introduktion til EUs AI-forordning for softwaretestere

 EU's forordning om kunstig intelligens (AI-forordningen) blev vedtaget i august 2024 og er verdens første omfattende lovgivning, der regulerer brugen af kunstig intelligens. Formålet med forordningen er at skabe klare rammer for udvikling og anvendelse af AI-systemer, sikre ansvarlig og sikker brug af teknologien samt beskytte borgernes rettigheder og sikkerhed.

Indhold og anvendelse

AI-forordningen anvender en risikobaseret tilgang og opdeler AI-systemer i fire kategorier baseret på deres potentielle risici:

1. Minimal eller ingen risiko: Disse systemer anses for at være lavrisiko og er ikke underlagt særlige krav. Eksempler inkluderer anbefalingssystemer i streamingtjenester og autokorrektur. 

2. Begrænset risiko: Systemer under denne kategori skal overholde specifikke gennemsigtighedskrav. For eksempel skal brugere informeres, når de interagerer med en chatbot, eller når de præsenteres for AI-genereret indhold som deepfakes. 

3. Højrisiko AI-systemer: Disse systemer har en væsentlig risiko og er underlagt strenge krav, herunder detaljeret dokumentation, risikostyring og overvågning. Eksempler er AI-systemer anvendt i kritisk infrastruktur, uddannelse (fx bedømmelse af eksaminer) og ansættelsesprocedurer (fx sorteringssoftware til rekruttering). 

4. Forbudte AI-systemer: Systemer, der udgør en klar trussel mod sikkerhed, borgernes rettigheder eller værdighed, er forbudt. Dette inkluderer AI anvendt til masseovervågning eller til automatisk at vurdere risikoen for, at personer begår kriminalitet. 

Konsekvenser for softwaretest

For softwaretest har AI-forordningen flere betydelige konsekvenser, især for højrisiko AI-systemer:

• Strengere testkrav: Højrisiko AI-systemer skal gennemgå omfattende test for at sikre, at de opfylder forordningens krav. Dette inkluderer validering af systemets nøjagtighed, robusthed og cybersikkerhed. 

• Dokumentation og sporbarhed: Der er krav om detaljeret dokumentation af testprocedurer og resultater for at sikre sporbarhed og ansvarlighed. Dette betyder, at softwaretestere skal føre nøjagtige optegnelser over testforløb og -resultater. 

• Gennemsigtighed og forklarbarhed: Test skal sikre, at AI-systemer opererer på en gennemsigtig måde, hvilket kræver, at systemernes beslutningsprocesser kan forklares og forstås af mennesker.

• Løbende overvågning: Efter implementering skal højrisiko AI-systemer underkastes løbende overvågning og periodiske evalueringer for at sikre, at de fortsat overholder kravene og fungerer som tiltænkt. 

For softwaretestere betyder dette, at der skal udvikles nye teststrategier og -metoder, der adresserer disse krav, hvilket kan medføre behov for yderligere uddannelse og opkvalificering inden for AI-specifikke testprocedurer.

 

Boganmeldelse: Agile 2 – The Next Iteration of Agile

Forfattere: Clifford Berg m.fl.
Forlag: Wiley
Udgivelsesår: 2021

 

En nødvendig evolution af Agile

Siden det agile manifest blev formuleret i 2001, har agile metoder transformeret softwareudvikling, test og projektledelse. Men med Agile 2 præsenterer Clifford Berg og hans medforfattere en kritisk refleksion over Agile-praksisser og foreslår en mere nuanceret, pragmatisk og moderne tilgang. Bogen Agile 2 – The Next Iteration of Agile er en nødvendig og velfunderet videreudvikling af Agile, der adresserer mange af de udfordringer, teams og organisationer har oplevet i de sidste to årtier.

Bogen går dybere end det klassiske Agile-manifest og foreslår en mere afbalanceret og situationsbestemt tilgang, der tager hensyn til både ledelse, teamsamarbejde, teknologi og forretningsmæssige behov.

Styrker ved bogen

1. Kritisk refleksion over Agile's styrker og svagheder

En af de store styrker ved Agile 2 er dens ærlige tilgang til Agile’s udfordringer. Forfatterne anerkender, at mens Agile har haft stor succes, har det også ført til visse rigiditeter, misforståelser og overforenklinger – eksempelvis overdreven fokus på teams frem for lederskab, og manglende vægt på teknisk disciplin i nogle implementeringer.

Ved at belyse disse svagheder giver bogen et mere realistisk og pragmatisk syn på Agile i moderne organisationer.

2. Balance mellem fleksibilitet og struktur

Agile 2 adresserer en af de mest omdiskuterede aspekter ved Agile: Hvordan balancerer man autonomi med nødvendige strukturer? Bogen argumenterer for, at agilitet ikke bør være et dogme, men en fleksibel tilgang, der tilpasses konteksten – noget mange organisationer har kæmpet med.

Den giver værdifuld indsigt i, hvordan teams kan opnå agilitet, uden at det går ud over nødvendige ledelsesstrukturer, governance eller kvalitetssikring.

3. Fokus på ledelse og organisation

Mens mange Agile-bøger fokuserer på teams og deres processer, går Agile 2 et skridt videre ved at inddrage organisatoriske og ledelsesmæssige perspektiver. Den fremhæver, hvordan ledelse spiller en central rolle i at skabe et agilt miljø, der både understøtter teamautonomi og sikrer overordnet strategisk sammenhæng.

For testmanagers, udviklingsledere og forretningsstrateger giver dette et stærkt fundament til at arbejde med Agile uden at miste overblik eller retning.

4. Nuanceret syn på teknologi og DevOps

En anden stærk side ved bogen er dens erkendelse af teknologiens rolle i Agile. Hvor det oprindelige Agile-manifest primært var orienteret mod softwareudvikling, tager Agile 2 også højde for, hvordan DevOps, cloud computing og automatisering har ændret måden, Agile fungerer på.

Dette gør bogen relevant for både testere, udviklere og operationsfolk, der arbejder i et moderne teknologilandskab.

5. Klar struktur og praktiske anbefalinger

Bogen er skrevet i et letlæseligt og struktureret format, hvor koncepter introduceres med konkrete eksempler og anbefalinger. Dette gør den anvendelig ikke blot som en teoretisk refleksion, men også som en praktisk guide til at implementere Agile 2-principper i organisationer.

Forbedringsområder

1. Manglende detaljer om implementeringsstrategier

Selvom bogen præsenterer stærke koncepter, kunne den have givet mere dybdegående vejledning i, hvordan organisationer kan implementere Agile 2 i praksis. Mange virksomheder kæmper med transformationer, og mere konkrete roadmaps eller trin-for-trin-metoder ville have været en værdifuld tilføjelse.

2. Mere dybde i konkrete case studies

Bogen inkluderer nogle eksempler, men kunne have draget større nytte af flere konkrete case studies fra virksomheder, der har anvendt Agile 2-principperne. Dette ville gøre det lettere for læsere at relatere til de foreslåede ændringer i deres egen kontekst.

Samlet vurdering

Agile 2 – The Next Iteration of Agile er en fremragende og nødvendig videreudvikling af Agile-konceptet. Den tilbyder en mere afbalanceret, fleksibel og realistisk tilgang, der tager højde for både ledelse, teknologi og organisatoriske behov.

Bogen er særligt værdifuld for ledere, testmanagers, produktteams og udviklere, der har oplevet udfordringer med klassiske Agile-implementeringer og søger en mere nuanceret tilgang.

Selvom bogen kunne have givet mere konkret vejledning om implementering, er dens strategiske perspektiver og refleksioner uundværlige for enhver, der arbejder med agil transformation.

Den anbefales til alle, der ønsker en moderne, pragmatisk og mere helhedsorienteret forståelse af Agile.

 

Forelæsningsrække om kunstig intelligens på CBS

Kunstig intelligens (AI) har på rekordtid forandret måden, vi lever og arbejder på. Forelæsningsrækken på Copenhagen Business School gav deltagerne en dybere forståelse af AI's indflydelse på erhvervslivet, uddannelsessektoren og den offentlige sektor. Med tre skarpe foredrag af førende eksperter fik vi en bred indsigt i AI's revolutionerende potentiale samt de udfordringer, teknologien bringer med sig.

AI – Den store revolution (27. januar 2025)

v. Jan Damsgaard, professor, Institut for Digitalisering, CBS

Første forelæsning tog os med på en rejse gennem AI's eksplosive udvikling og de konsekvenser, den har for virksomheder, samfund og vores dagligdag. Jan Damsgaard præsenterede, hvordan AI allerede nu skaber værdi ved at automatisere processer, optimere beslutningstagning og åbne for nye forretningsmodeller. Han berørte åbne spørgsmål om regulering, dataetik og risikoen for AI-baserede monopoler, som kan forme fremtidens digitale landskab.

Et centralt tema var behovet for en balanceret tilgang til regulering: AI skal styres, men ikke kvæles af for restriktive love, så Europa kan forblive konkurrencedygtig. Afslutningsvis blev der reflekteret over, hvordan AI vil forme fremtidens arbejdsmarked og kravene til vores digitale kompetencer.

AI, læring og uddannelse (3. februar 2025)

v. Sine Zambach, adjunkt, Institut for Digitalisering, CBS

Den anden forelæsning fokuserede på AI's rolle i uddannelsessektoren og læring. Sine Zambach belyste, hvordan AI allerede nu transformerer undervisning gennem personaliseret læring, automatiserede feedbacksystemer og intelligent tutoring. Hun præsenterede eksempler på, hvordan AI understøtter lærere i at skræddersy undervisning og identificere elever, der har brug for ekstra støtte.

Men med teknologien følger også dilemmaer: Hvordan sikrer vi, at AI ikke skaber etisk problematiske situationer, hvor elever bliver overvåget eller ensrettet i deres læring? Hvordan kan vi forberede elever og studerende på en fremtid, hvor AI er en naturlig del af deres arbejds- og studieliv? Forelæsningen understregede behovet for kritisk tænkning i brugen af AI i undervisningen og en åben debat om teknologiens etiske aspekter.

AI, healthcare, and the public sector (10. februar 2025)

v. Rony Medaglia, professor MSO, Institut for Digitalisering, CBS

Den tredje og sidste forelæsning, afholdt på engelsk, dykkede ned i AI's betydning for sundhedssektoren og den offentlige forvaltning. Rony Medaglia præsenterede eksempler på, hvordan AI bruges til at forbedre patientdiagnostik, effektivisere sagsbehandling og optimere offentlige ydelser. AI's evne til at analysere store datamængder betyder, at sundhedspersonale kan tage hurtigere og mere præcise beslutninger, hvilket kan redde liv og reducere omkostninger.

Forelæsningen behandlede dog også de udfordringer, som AI medfører i den offentlige sektor: Hvordan sikrer vi transparens i beslutninger truffet af algoritmer? Hvordan beskytter vi borgernes privatliv i en tid, hvor AI anvender enorme datamængder? Diskussionen kredsede om balancen mellem teknologisk innovation og borgernes retssikkerhed.

Konklusion

Forelæsningsrækken gav et nuanceret billede af AI's indflydelse på samfundet. Fra erhvervslivet til uddannelse og sundhed blev det klart, at AI byder på store muligheder, men også udfordringer, der kræver opmærksomhed. Reguleringsspørgsmålet stod centralt i alle tre foredrag: Vi skal finde en vej, hvor vi udnytter AI's potentiale uden at overse de etiske og juridiske risici.

Med anbefalede læsninger som 'AI – Mellem fornuft og følelse' og 'AI i gymnasiet' er der rig mulighed for at dykke endnu dybere ned i emnet og reflektere over AI's rolle i vores hverdag. Forelæsningsrækken på CBS har uden tvivl været en værdifuld oplevelse for mig, der ønsker at forstå AI's betydning i et moderne samfund.

 

Test i sekventielle vs agile udviklingsprojekter - En komparativ analyse

Forskellen mellem test i sekventielle (traditionelle) udviklingsprojekter og agilt baserede udviklingsprojekter er markant både i tilgangen, timing, roller og værktøjer. Nedenfor gives en detaljeret sammenligning af test i de to tilgange.

1. Overordnet tilgang

Sekventielle udviklingsprojekter (fx Vandfaldsmodellen, V-Model)

• Test følger en lineær, faseopdelt tilgang, hvor test først påbegyndes efter udvikling er afsluttet.
• Krav defineres i starten af projektet, hvilket gør det svært at ændre dem senere.
• Test foregår i en separat testfase (ofte Unittest → Integrationstest → Systemtest → Accepttest).
• Formålet er at bekræfte, at produktet lever op til de fastlagte krav.

Agilt baserede udviklingsprojekter (fx Scrum, SAFe, Kanban)

• Test er en iterativ og kontinuerlig proces, hvor test sker parallelt med udviklingen.
• Krav kan ændres dynamisk i takt med nye forretningsbehov og brugerfeedback.
• Test udføres løbende i hver sprint og integreres i udviklingsprocessen.
• Formålet er at sikre kvalitet og hurtig feedback for at understøtte en inkrementel levering af funktionalitet.

2. Timing og testfaser

Sekventiel udvikling

• Test kommer sent i udviklingsforløbet (ofte efter implementering er færdig).
• Ofte store testsessioner mod slutningen, hvilket kan føre til tidspres og flaskehalse.
• Regressionstest foretages primært i den afsluttende fase.
• Brugere inddrages typisk kun i slutningen (UAT – User Acceptance Testing).

Agil udvikling

• Test er en integreret del af hver sprint (typisk 1-4 uger lange).
• Kontinuerlig test gennem testautomatisering, unittests, integrationstest og funktionelle tests.
• Regressionstest er en fast del af hver sprint og sikres via automatisering.
• Brugerne kan være involveret løbende (f.eks. gennem demoer og feedback).

3. Testroller og ansvarsfordeling

Sekventiel udvikling

• Testansvaret ligger ofte hos en dedikeret testafdeling eller QA-team.
• Udviklere er sjældent involveret i testningen.
• Testere skriver detaljerede testcases og testplaner i starten af testfasen.
• Fejlrapporter sendes tilbage til udviklingsteamet, hvilket kan føre til lange cyklusser for fejlrettelser.

Agil udvikling

• Testansvaret er distribueret, og hele teamet har ansvar for kvalitet.
• Udviklere, testere og forretningsanalytikere samarbejder tæt om test.
• Testere arbejder tæt sammen med udviklere om testautomatisering og tidlig validering.
• "Shift-left"-tilgangen anvendes, hvor testning påbegyndes så tidligt som muligt.

4. Test og testværktøjer

Sekventiel udvikling

• Primært manuelle testcases, struktureret systemtest og accepttest.
• Større fokus på end-to-end test i en adskilt testfase.
• Testautomatisering anvendes typisk kun i regressionstest, men kan være begrænset.
• Almindelige værktøjer: (HP) ALM, TestRail, Xray, Selenium (hvis automatisering anvendes).

Agil udvikling

• Fokus på automatisering af unit test, API test og GUI test.
• Test udføres kontinuerligt via CI/CD-pipelines.
• Brug af eksplorativ test og adfærdsdrevet test (BDD) for hurtigere feedback.
• Almindelige værktøjer: JIRA, Xray, Selenium, Cypress, Postman, Cucumber, Jenkins.

5. Håndtering af fejl og kvalitetssikring

Sekventiel udvikling

• Fejl identificeres sent i udviklingsprocessen, hvilket gør dem dyrere at rette.
• Testere skriver detaljerede fejlrapporter, som udviklerne løser separat.
• Fokus er på at dokumentere defekter og fejlsporing.

Agil udvikling

• Fejl identificeres og rettes hurtigt, ofte i samme sprint.
• Kontinuerlig integration gør det muligt at fange fejl tidligt.
• Testere arbejder tæt sammen med udviklere for hurtig fejlfinding (f.eks. via par-testning).

6. Risici og faldgruber

Sekventiel udvikling

• Risiko for, at test kommer for sent, og kritiske fejl først opdages sent.
• Store og tunge testcyklusser kan forsinke levering.
• Mindre fleksibilitet i forhold til ændrede krav.

Agil udvikling

• Risiko for utilstrækkelig testdækning, hvis der ikke er en struktureret teststrategi.
• Testautomatisering kræver investering og vedligeholdelse.
• Hurtigt tempo kan føre til kompromiser i testkvaliteten, hvis teamet ikke er disciplineret.

Konklusion

Sekventiel test er velegnet til stabile, langsigtede projekter med fastlagte krav, hvorimod agil test er ideel til projekter med hurtigt skiftende krav og behov for hurtig feedback.

En hybrid tilgang, hvor testautomatisering, tidlig testinvolvering og strukturerede teststrategier kombineres, kan ofte give de bedste resultater – især i organisationer, der er i en overgang fra sekventiel til agil udvikling.

 

Boganmeldelse: Holistic Testing – Weave Quality into Your Product

Forfattere: Janet Gregory & Lisa Crispin
Forlag: Agile Testing Fellowship Press
Udgivelsesår: 2022

 

En helhedsorienteret tilgang til kvalitet i agile teams

Janet Gregory og Lisa Crispin er velkendte autoriteter inden for agile testmetoder, og deres bog Holistic Testing – Weave Quality into Your Product er endnu en stærk ressource til testere, udviklere og produktteams, der ønsker at forbedre softwarekvaliteten på en integreret måde.

I stedet for at se test som en separat fase i udviklingsprocessen, argumenterer forfatterne for, at kvalitet bør være en fælles opgave på tværs af hele teamet – fra idéfase til levering. Bogen er både inspirerende og praktisk, med klare strategier til, hvordan test og kvalitetssikring kan blive en naturlig del af agile arbejdsprocesser.

Styrker ved bogen

1. Klar og tilgængelig formidling

Bogen er skrevet i et letforståeligt sprog med en logisk opbygning, der gør det nemt for læseren at følge med. Gregory og Crispin er kendt for deres evne til at forklare komplekse emner på en jordnær måde, og denne bog er ingen undtagelse.

2. Holistisk perspektiv på test og kvalitet

En af de stærkeste sider ved bogen er dens helhedsorienterede tilgang til testning. Den dækker både tekniske og ikke-tekniske aspekter af kvalitetssikring, herunder:

• Hvordan teams kan samarbejde for at forebygge fejl tidligt
• Hvordan kvalitet kan indarbejdes i udviklingsprocessen frem for kun at blive kontrolleret bagefter
• Hvordan en testdrevet kultur kan styrke hele organisationen

3. Praktiske værktøjer og teknikker

Bogen er ikke kun teoretisk – den indeholder også en række konkrete værktøjer og teknikker, som teams kan anvende for at forbedre deres testpraksis. Der er eksempler på:

• Hvordan testere kan samarbejde tættere med udviklere
• Hvordan test og kvalitetssikring kan integreres i CI/CD-processer
• Hvordan man måler testeffektivitet i agile teams

4. Relevante eksempler og cases

Forfatterne bruger en række cases og eksempler fra den virkelige verden til at illustrere deres pointer. Dette gør det lettere for læseren at relatere bogens koncepter til deres egen praksis.

5. Fokus på teamsamarbejde og kvalitet som et fælles ansvar

I mange organisationer er test stadig en siloaktivitet, men Holistic Testing udfordrer denne tilgang og viser, hvordan kvalitet bliver stærkere, når hele teamet tager ansvar. Dette perspektiv gør bogen særligt værdifuld for agile teams, der ønsker at forbedre deres samarbejde omkring test og kvalitetssikring.

Forbedringsområder

1. Flere tekniske eksempler

Mens bogen dækker mange aspekter af teststrategi og samarbejde, kunne den have inkluderet flere eksempler på tekniske implementeringer, f.eks. testautomatisering, performance-test og sikkerhedstest. For testere med en mere teknisk baggrund kunne dette have givet yderligere værdi.

2. Dybdegående analyse af måling af kvalitet

Bogen berører, hvordan teams kan måle kvalitet, men en mere struktureret tilgang til testmetrikker og KPI’er ville have gjort denne del stærkere. For mange teams er det en udfordring at finde de rette målepunkter for test og kvalitet, og en mere detaljeret vejledning kunne have hjulpet her.

Samlet vurdering

Holistic Testing – Weave Quality into Your Product er en fremragende bog for testere, udviklere, Scrum Masters og produktledere, der ønsker at gøre test og kvalitet til en integreret del af deres agile processer. Gregory og Crispin leverer en inspirerende guide til, hvordan teams kan samarbejde om at skabe software af høj kvalitet.

Selvom bogen kunne have haft flere tekniske eksempler og en dybere analyse af kvalitetsmåling, er den stadig en værdifuld ressource, især for teams, der ønsker at bevæge sig væk fra en silo-baseret tilgang til test.

Den anbefales varmt til alle, der arbejder med test og kvalitet i agile miljøer, og som ønsker en stærkere forståelse af, hvordan test kan være en drivkraft for bedre softwareudvikling.

 

Boganmeldelse: Test Automation Engineering Handbook

Forfatter: Manikandan Sambamurthy
Forlag: Packt
Udgivelsesår: 2023

 

En omfattende guide til testautomatisering for moderne softwareteams

Testautomatisering er blevet en afgørende disciplin i softwareudvikling, hvor agilitet og DevOps stiller stadigt højere krav til hurtigere og mere stabile leverancer. Test Automation Engineering Handbook af Manikandan Sambamurthy er en stærk ressource for testingeniører, udviklere og testledere, der ønsker at opbygge eller forbedre deres automatiseringskompetencer.

Bogen leverer en balanceret blanding af teori og praktiske eksempler, hvilket gør den velegnet til både begyndere og erfarne testautomatiseringsspecialister.

Styrker ved bogen

1. Klar struktur og progression

Bogen er velstruktureret, idet den fører læseren fra grundlæggende principper i testautomatisering til avancerede emner såsom CI/CD-integration, strategisk testautomatisering og skalerbare frameworks. Denne progression gør det nemt at følge med, uanset erfaringsniveau.

2. Hands-on tilgang med eksempler

En af bogens store fordele er dens praktiske eksempler og kodeuddrag. Læseren får konkrete demonstrationer af testautomatiseringsværktøjer som Selenium, Cypress, Playwright og Appium. Bogen forklarer ikke blot, hvordan man skriver automatiserede tests, men også hvordan man organiserer dem for maksimal genanvendelighed og vedligeholdelse.

3. Fokus på bedste praksis og strategi

Ud over tekniske detaljer diskuterer bogen vigtige strategiske aspekter af testautomatisering, såsom:

• Hvordan man vælger den rigtige testautomatiseringsstrategi
• Hvornår automatisering giver mest værdi
• Hvordan man strukturerer tests, så de er robuste og nemme at vedligeholde

Dette gør bogen til mere end blot en guide til værktøjer – den hjælper testteams med at træffe informerede beslutninger.

4. Moderne teknologier og tendenser

Bogen er opdateret med moderne trends inden for testautomatisering, herunder AI-baseret testning, skalerbarhed i cloud-miljøer og integration med DevOps-pipelines. Dette sikrer, at læseren får indsigt i de nyeste udviklinger på området.

Forbedringsområder

1. Mere dybde i performance- og sikkerhedstest

Mens bogen dækker funktionel testautomatisering i detaljer, kunne den have givet mere dybdegående indsigt i automatisering af performance- og sikkerhedstest. Disse områder bliver stadig vigtigere i moderne softwareudvikling, og en udvidelse her ville have gjort bogen endnu mere komplet.

2. Flere cases fra virkelige virksomheder

Selvom bogen indeholder praktiske eksempler, kunne den have draget fordel af flere konkrete cases fra virksomheder, der har implementeret testautomatisering – herunder hvilke udfordringer de stod overfor, og hvordan de blev løst.

Samlet vurdering

Test Automation Engineering Handbook er en fremragende bog for alle, der ønsker at forstå eller forbedre deres testautomatiseringspraksis. Den kombinerer teori med praktiske eksempler og dækker moderne teknologier, hvilket gør den relevant for testautomatiseringsspecialister i dag.

Bogen fungerer både som en introduktion for nybegyndere og en værdifuld reference for erfarne fagfolk. Med nogle flere cases og dybdegående dækning af performance- og sikkerhedstest ville den være endnu stærkere.

Den anbefales til testingeniører, udviklere, testmanagers og DevOps-professionelle, der ønsker en solid og moderne tilgang til testautomatisering.

 

Webinar om Testteknikkerne Ækvivalenspartitionering og Grænseværdianalyse og lidt mere

Den 30/1 2025 afholdt jeg et webinar om testteknikkerne Ækvivalenspartitionering og Grænseværdianalyse i vor Q Topics regi @ Q Nation. Hvis ikke du deltog eller gerne vil gense webinaret findes optagelsen på dette link. På linket finde både mine og mine dygtige kollegaers webinarer. Du er naturligvis også velkommen til at dele det med dine kollegaer. God fornøjelse.

LINK: 

https://www.qnation.dk/oversigt-over-tidligere-events

Test af User Stories: En Guide til Effektiv Test i Agile Projekter

 1. Introduktion

Test af user stories er en kritisk aktivitet i agile udviklingsmetoder. Det sikrer, at kravene til systemet er forståelige, entydige og testbare. I modsætning til traditionelle kravspecificeringer er user stories ofte mere uformelle, hvilket kræver en struktureret tilgang til test for at minimere misforståelser og sikre funktionalitet.

Agile teams arbejder iterativt og inkrementelt, hvilket betyder, at test af user stories sker kontinuerligt gennem udviklingsprocessen. Testerne spiller en aktiv rolle i at analysere user stories, definere testcases og samarbejde tæt med udviklere og produktejere for at forbedre kvaliteten.

2. Formål med at teste user stories

Formålet med at teste user stories er:

• At validere forståelsen af kravet – Sikre, at alle teammedlemmer har en fælles forståelse af, hvad der skal udvikles.
• At identificere manglende eller uklare acceptancekriterier – Testning afslører huller i kravene og mulige edge cases.
• At verificere funktionalitet – Sikre, at implementeringen stemmer overens med kravene.
• At understøtte automatisering – Tidlig testdesign gør det nemmere at implementere automatiserede tests.
• At reducere fejl senere i udviklingsforløbet – Jo tidligere fejl opdages, jo billigere er de at rette.

3. Forudsætninger for test af user stories

For at kunne teste user stories effektivt skal følgende forudsætninger være opfyldt:

a) Kvaliteten af user stories

En god user story bør følge INVEST-kriterierne:

• Independent (Uafhængig): Skal kunne udvikles og testes isoleret.
• Negotiable (Forhandlingsbar): Ikke en kontrakt, men et udgangspunkt for dialog.
• Valuable (Værdiskabende): Skal give værdi for brugeren.
• Estimable (Estimerbar): Skal kunne vurderes ift. udvikling og test.
• Small (Lille): Skal kunne implementeres i én iteration.
• Testable (Testbar): Skal have klare acceptancekriterier.

b) Acceptancekriterier

Acceptancekriterier er afgørende for test af user stories, da de definerer de betingelser, der skal være opfyldt, for at en user story kan betragtes som færdig. De bør være:

• Specifikke: Tydelige og præcise.
• Målbare: Kan verificeres via test.
• Forståelige: Letforståelige for både forretning og teknik.

c) Samarbejde mellem roller

Effektiv test af user stories kræver tæt samarbejde mellem udviklere, testere og produktejere. En fælles forståelse skabes ofte gennem Three Amigos-møder, hvor disse tre roller gennemgår og diskuterer user stories.

4. Fremgangsmåde

a) Gennemgang af user story

• Gennemlæs user story og acceptancekriterier.
• Identificér manglende informationer eller uklare krav.
• Identificér edge cases og risikoområder.

b) Definering af testcases

• Funktionelle tests: Sikrer, at funktionaliteten virker som forventet.
• Negative tests: Tester uventede input og fejlscenarier.
• Non-funktionelle tests: Test af ydeevne, brugervenlighed og sikkerhed.
• Testteknikker:
  • Ekvivalenspartitionering: Opdeling af input i grupper med samme adfærd.
  • Grænseværdianalyse: Test af værdier tæt på grænserne.
  • Beslutningstabeller: Test af komplekse logiske sammenhænge.
  • Exploratory testing: Ad hoc test for at opdage uventede fejl.

c) Testafvikling

• Testcases udføres manuelt eller automatiseres.
• Fejlrapportering sker med detaljerede beskrivelser af fundne problemer.
• Regressionstests sikrer, at ændringer ikke bryder eksisterende funktionalitet.

d) Automatisering

• Automatiserede tests kan dække regressionstest af user stories.
• Testframeworks som Selenium, Cypress eller Playwright kan bruges til UI-test.
• Unit tests i udviklerens kodebase kan hjælpe med at validere logik.

e) Feedback og iteration

• Testresultater deles med udviklingsteamet.
• User stories opdateres efter behov for at afspejle nye læringer.

5. Stærke og svage sider

Stærke sider:

• Tidlig validering: Tester krav, før de udvikles.
• Forbedret samarbejde: Styrker dialogen mellem udvikling, test og forretning.
• Mere præcise krav: Acceptancekriterier bliver mere skarpe.
• Automatiseringsvenlig tilgang: Strukturerede tests kan let automatiseres.

Svage sider:

• Afhængig af gode acceptancekriterier: Dårligt definerede user stories giver uklare tests.
• Kan være tidskrævende: Test af user stories kræver grundig analyse.
• For mange små stories kan skabe overhead: Hvis user stories opdeles for meget, kan det give mere testarbejde end nødvendigt.

6. Eksempler på test af user stories

Eksempel 1: Test af login user story

User Story:

Som bruger vil jeg kunne logge ind med mit brugernavn og password, så jeg kan få adgang til mine personlige data.

Acceptancekriterier:

1. Brugeren skal kunne logge ind med et gyldigt brugernavn og password.
2. Brugeren skal få en fejlmeddelelse ved forkert brugernavn eller password.
3. Efter 5 fejlede loginforsøg skal kontoen låses i 5 minutter.

Testcases:

• Log ind med gyldige credentials (positiv test).
• Log ind med ugyldigt brugernavn eller password (negativ test).
• Forsøg at logge ind 5 gange med forkerte credentials og verificér låsning.

Eksempel 2: Test af en søgefunktion

User Story:

Som bruger vil jeg kunne søge efter produkter i en webshop, så jeg kan finde det, jeg leder efter.

Acceptancekriterier:

1. Brugeren kan søge ved at indtaste søgeord i søgefeltet.
2. Systemet viser produkter, der matcher søgeordet.
3. Systemet viser en besked, hvis ingen produkter findes.
4. Systemet skal kunne håndtere store datamængder effektivt.

Testcases:

• Søgning med et gyldigt søgeord.
• Søgning med et ugyldigt søgeord (ingen resultater).
• Søgning med specialtegn.
• Søgning med store datamængder for at teste performance.

7. Afslutning

Test af user stories er afgørende for at sikre software af høj kvalitet i agile projekter. Ved at bruge strukturerede testteknikker og tæt samarbejde med udviklingsteamet kan testere hjælpe med at identificere fejl tidligt og forbedre kravspecificeringen.

For at få mest muligt ud af test af user stories bør teams fokusere på klare acceptancekriterier, automatisering og løbende feedback. Dette fører til mere præcise krav, færre fejl og et bedre slutprodukt.