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.

 

Boganmeldelse: Surfing the Waves of Agile af Derk-Jan de Grood

 

Introduktion og formål

"Surfing the Waves of Agile" (2022) er en hybrid mellem refleksion, casebaseret erfaring og praktisk vejledning. Bogen henvender sig til ledere og testansvarlige, som ønsker at forstå og navigere i den agile virkelighed – ikke blot som metode, men som en kultur og en rejse.

Derk-Jan de Grood trækker på egne erfaringer og kombinerer fortællinger med konkrete modeller og metaforer (særligt bølger og surfing) for at illustrere agile modningsrejser. For test managers er bogen både tankevækkende og konkret, men har også begrænsninger, som denne anmeldelse belyser.

Styrker og højdepunkter

1. Metafor som læringsværktøj

Bogens bærende metafor – at navigere agile "bølger" som surfer – er effektiv til at forstå agilitet som en iterativ og kontekstbunden proces. Bølgerne symboliserer agile modenhedsniveauer og forandringsbølger, der ikke nødvendigvis ankommer i sekventiel rækkefølge.

For test managers: Dette fremmer en mere realistisk forståelse af transformationens uforudsigelighed – noget som klassiske modenhedsmodeller (som TMMi) ikke altid favner.

2. Praktiske værktøjer og cases

Bogen inkluderer konkrete værktøjer som:

• Transformation Roadmaps

• Agile Maturity Models

• Change Heat Maps

• Team typologier (fx "Explorer vs. Settler")

Disse er især værdifulde for testledere, der arbejder med både agile transitionsprogrammer og organisatorisk modning.

Eksempel: Kapitel 5 beskriver, hvordan man som testleder kan identificere teamets agile profil og matche sin ledelsesstil derefter.

3. Rolleforståelse og kommunikation

De Grood fremhæver vigtigheden af, at test managers og QA-ansvarlige agerer som change enablers snarere end som kontrollerende gatekeepers. Bogen skubber læseren til at:

• forstå sine stakeholders bedre,

• opbygge relationel tillid,

• arbejde med value delivery, ikke kun conformance.

Dette understøtter moderne QA-roller og roller som Quality Coach eller Agile Test Strategist.

 Svagheder og kritikpunkter

1. Overfladisk behandling af testteknikker

Bogen indeholder relativt lidt om testdesign, testautomatisering eller teststrategiske valg i agile kontekster. For en testmanager med fokus på værktøjer og teknisk QA-praksis, kan dette virke som en manglende dimension.

Forvent derfor ikke en dybdegående behandling af f.eks. BDD, Exploratory Testing eller continuous testing frameworks.

2. Begrænset evidensbaseret fundament

Selvom de Groods erfaringer er værdifulde, mangler der til tider en systematisk kobling til gældende standarder (fx ISTQB Agile Tester Extension, ISO 29119-1/-2) og forskning. Det er primært en erfaringsbaseret bog.

En testleder, der skal argumentere strategisk over for ledelse eller compliance-fokuserede stakeholders, vil savne mere kvantitativt eller teoribaseret indhold.

3. Stil og læsevenlighed

Bogens narrative stil og metaforer tiltaler nogle læsere, men kan for andre virke langtrukne og lidt repetitive. Strukturen er tematisk frem for lineær, hvilket kan gøre den svær at anvende som referencebog i hverdagen.

Relevans for testmanagers

Fokusområde	Relevans	Noter
Teststrategi i agile kontekster	Middel	Indirekte behandlet gennem transformationsperspektiver
Ledelse og forandring	Høj	Giver konkrete værktøjer til at lede i transitioner
Kommunikation og stakeholder management	Høj	Cases og modeller er direkte anvendelige
Agile modenhed og coaching	Høj	Stærk i modenheds- og kulturrefleksioner
Teknisk QA og metrikker	Lav	Svag dækning af automation, CI/CD og test metrics

Samlet vurdering

"Surfing the Waves of Agile" er et relevant og inspirerende værk for test managers, der ønsker at styrke deres rolle i agile organisationer – særligt som forandringsledere og kulturformidlere. Bogen fungerer bedst som refleksionsværktøj og mindre som konkret testfaglig håndbog.

Testledere, der arbejder i organisationer med lav til middel agil modenhed, vil finde nyttig støtte i bogens modeller og mindset-skift. Mere teknisk orienterede QA-ansvarlige kan med fordel supplere med fx bogen Agile Testing Condensed af Lisa Crispin og Janet Gregory.

 

Boganmeldelse: The FIVE Dysfunctions of a Team – A Leadership Fable af Patrick Lencioni

 

1. Overblik og Formål

Lencioni’s bog kombinerer en fiktiv fortælling (’leadership fable’) med en struktureret gennemgang af fem grundlæggende dysfunktioner, der typisk underminerer teamperformance. Bogen søger at klargøre, hvorfor selv dygtige, erfarne mennesker ofte ikke lykkes som hold – og hvordan man som leder kan afhjælpe dette.

Dysfunktionerne er:

1. Fravær af tillid

2. Frygt for konflikt

3. Mangel på engagement

4. Undgåelse af ansvar

5. Mangel på resultatorientering

2. Relevans for Test Managers

Som testmanager arbejder man med teams, der ofte er tværfunktionelle, består af både fastansatte og konsulenter, og hvor afhængigheder og samarbejde er altafgørende – både for kvalitet og levering. I det lys er bogen særligt relevant på følgende områder:

a. Tillid og psykologisk sikkerhed

Lencioni fremhæver sårbarhed som fundament for tillid – en præmis, der også findes i Amy Edmondson’s forskning i psykologisk sikkerhed. I testteams er dette kritisk: fejl, misforståelser og risici skal kunne italesættes frit. Bogen giver her et konkret sprog og model, som kan bruges i retrospectives og teambuilding.

b. Konflikter som nødvendige

Testledelse indebærer ofte at udfordre udviklingsteams, interessenter og deadlines. Hvis man ikke har “konstruktiv konflikt”, bliver testmanagerens rolle udvandet. Bogen understreger værdien i at gøre uenighed produktiv, hvilket er et undervurderet område i mange testmiljøer.

c. Forpligtelse og beslutningskraft

Manglende engagement i teststrategier, risikodækning eller releasekriterier kan føre til inaktive teams. Bogen argumenterer for, at enighed ikke er nødvendigt – men derimod forpligtelse til en fælles beslutning. Dette er yderst anvendeligt i SAFe eller Scrum sammenhænge.

3. Konstruktiv evaluering

Styrker

• Let tilgængelig og pædagogisk: Historiefortællingen gør komplekse emner mere relaterbare.

• Modellen er intuitiv og logisk – kan anvendes direkte i retrospectives eller team health checks.

• Fokus på adfærd frem for struktur – passer til agile og værdidrevne miljøer.

Svagheder og begrænsninger

• Mangler kontekstualisering til komplekse organisationer: Bogen antager et enkeltstående team uden ekstern afhængighed eller organisatorisk kompleksitet (hvilket ikke matcher mange testprojekter).

• Fiktionselementet kan virke banalt eller overdrevet for erfarne fagpersoner.

• Ingen konkrete værktøjer/metoder: Modellen er stærk som dialogstarter, men kræver yderligere metoder (f.eks. team chartering, DISC-profiler, retrospectives, sociokrati) for operationel anvendelse.

4. Anvendelse i testledelse

Dysfunktion	Typisk testsituation	Tiltag med Lencioni som inspiration
Fravær af tillid	Ingen tør udfordre defekte krav eller fejlagtige antagelser	Teamøvelser om sårbarhed, retrospectives med psykologisk sikkerhed som tema
Frygt for konflikt	Tester undlader at eskalere kvalitetstrusler	Brug af “contrarian” roller i møder, faciliteret konflikt
Mangel på engagement	Uklare beslutninger om test scope eller dækning	Decision logs, afstemninger og visualisering af ejerskab
Undgåelse af ansvar	Fejl skubbes mellem udvikling og test	Peer reviews, teamets selvdefinerede forventninger
Mangel på resultatorientering	Fokus på individuelle mål, ikke produktkvalitet	Brug af fælles kvalitetskriterier, dashboards på teamniveau

5. Teoretisk og praktisk rammesætning

Bogen kan kobles med følgende frameworks:

• Tuckman’s model ("Forming–Storming–Norming–Performing") – Lencioni placerer sig som dybere analyse af “storming”-fasen.

• ISO 29119-3: understøtter behovet for klare roller, ansvar og kommunikationsplaner – her er Lencionis model et godt supplement.

• SAFe’s Team and Technical Agility – værdier som tillid og alignment er stærkt afspejlet.

6. Anbefaling og Konklusion

The Five Dysfunctions of a Team er et fremragende udgangspunkt for testmanagers, der ønsker at styrke teamkultur og samarbejde – især i agile og komplekse miljøer. Den bør dog suppleres med konkrete værktøjer og organisatorisk forståelse. Brug bogen til at skabe refleksion, dialog og fælles forståelse – ikke som one-size-fits-all-løsning.

Anbefalet brug: Workshops, team retrospectives, onboarding af nye testteams, ledelsesudvikling.

 

Brugervenlighedstest

Brugervenlighed er en afgørende egenskab i softwarekvalitet, særligt i løsninger med mange slutbrugere. ISO/IEC 25010:2011 definerer usability (brugervenlighed) som én af otte overordnede kvalitetskarakteristika, og opstiller tre underkarakteristika til at vurdere den. I praksis suppleres ISO 25010 ofte med ISO 9241-11, der tilbyder dybere definitioner og vejledning i evaluering af usability i kontekst.

Hvad er Usability ifølge ISO 25010?

ISO 25010 definerer usability som:

“The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

Underkarakteristika:

1. Effectiveness (Effektivitet) – I hvilken grad brugerne kan opnå deres mål korrekt og fuldstændigt.

2. Efficiency (Effektivitet i anvendelsen) – Ressourcer (tid, klik, mentale anstrengelser) brugt i forhold til mål opnået.

3. Satisfaction (Tilfredshed) – Brugernes subjektive oplevelse og accept af produktets anvendelighed.

ISO 25010 nævner også “usability compliance” og “accessibility” som additional quality measures, ofte integreret i udvidede testscenarier.

Fremgangsmåde: Hvordan tester man brugervenlighed?

1. Forberedelse: Fastlæggelse af testkontekst

• Definér målgruppen og deres baggrund.

• Identificér primære brugeropgaver (baseret på personaer og brugsscenarier).

• Fastlæg testens mål (måling af succesrate? Identifikation af hindringer? Forbedringsforslag?).

2. Valg af testmetode

Metode	Beskrivelse	Brugssituation
Modereret usability test	Brugeren udfører opgaver, mens testleder observerer og stiller opklarende spørgsmål	Dybdegående analyse og kontekstforståelse
Umodereret test	Brugere interagerer med systemet alene, typisk via online platforme	Større skala, mindre ressourcetung
Heuristisk evaluering	Eksperter vurderer grænsefladen ud fra kendte usability principper (eks. Nielsen)	Hurtig, tidlig vurdering
Think-Aloud protokol	Brugeren verbaliserer sine tanker undervejs	Indblik i mentale modeller
Remote testing	Brugen observeres via skærmdeling/videooptagelser	Geografisk uafhængighed

3. Valg af målepunkter (aligned med ISO 25010)

• Effectiveness: task completion rate, error rate, succesrate pr. opgave.

• Efficiency: tid pr. opgave, antal klik, antal hjælpekald.

• Satisfaction: System Usability Scale (SUS), Net Promoter Score (NPS), qualitative feedback.

4. Testafvikling

• Standardiseret instruktion og opgaver.

• Observationsark, videooptagelser og noter.

• Indsamling af både kvantitative og kvalitative data.

5. Analyse og rapportering

• Sammenlign resultater mod forhåndsdefinerede succeskriterier.

• Identificér barrierer og usability issues.

• Prioritér forbedringer baseret på impact + severity.

Overvejelser og faldgruber

Vigtige overvejelser

• Brug repræsentative brugere og realistiske opgaver.

• Kombinér kvantitative og kvalitative data for helhedsforståelse.

• Usability er kontekstafhængig – vær opmærksom på omgivelser og brugerroller.

Typiske faldgruber

• For få eller for homogene testpersoner.

• Fokus på grænsefladedetaljer uden forståelse for brugerens overordnede mål.

• Manglende dokumentation af testkontekst og målepunkter (afviger fra ISO-vejledning).

Praktisk eksempel (webapplikation)

Et dansk forsikringsselskab ønsker at teste brugervenligheden af et nyt skadeanmeldelsessystem. De vælger følgende opsætning:

• Målgruppe: Kunder 30-70 år, lav digital erfaring.

• Opgaver: "Anmeld en skade", "Tjek status på en anmeldelse".

• Målinger:

  • Task success rate ≥ 85%

  • Gennemsnitlig tid < 3 minutter/opgave

  • SUS ≥ 75

• Metode: Modereret usability test + SUS post-test survey.

• Konklusion: Brugerne fandt systemet “let at gå til”, men navigationsmenuen var uklar for ældre brugere → ændringer i IA foreslået.

Sammenhæng med øvrige kvalitetsområder i ISO 25010

Brugervenlighed påvirker og påvirkes af andre karakteristika:

• Functional Suitability: Brugervenlighed forudsætter, at funktionaliteten er relevant og korrekt.

• Performance Efficiency: Lave svartider kan forbedre både effektivitet og tilfredshed.

• Accessibility (ISO/IEC 30071-1): En forlængelse af usability mod inklusion.

Konklusion og anbefalinger

Brugervenlighedstest er en systematisk metode til at sikre, at software er anvendeligt, effektivt og tilfredsstillende for sine brugere. ISO 25010 tilbyder et stærkt rammeværk, der kan operationaliseres gennem en kombination af empiriske test, brugerfeedback og målbare indikatorer. For optimal effekt bør usability evalueres iterativt gennem hele udviklingscyklussen.

 

Use Case-baseret test – Et effektivt bindeled mellem krav og test

Introduktion: Hvad er en Use Case?

Use cases beskriver hvordan brugeren interagerer med systemet for at opnå et bestemt mål. En use case fokuserer på aktørers intentioner, systemets reaktioner og de variationer, der kan opstå undervejs. Formatet stammer fra UML (Unified Modeling Language) og er standardiseret i bl.a. ISO/IEC/IEEE 29148 og anvendt i kravspecifikationer og softwarearkitektur.

Eksempel: "En kunde ønsker at bestille en vare online." – dette dækker både hovedscenariet (happy path) og alternative flows (f.eks. udsolgte varer, forkert betalingsinformation).

For testmanagers fungerer use cases som en bro mellem kravspecifikation og testscenarier. De udgør et effektivt grundlag for både accepttest og systemtest og muliggør kommunikation på tværs af tekniske og forretningsmæssige domæner.

Use Case-baseret testdesign

Test baseret på use cases fokuserer på brugerens opgaver og systemets opførsel i kontekst. Det sker ofte med udgangspunkt i følgende struktur:

1. Identifikation af aktører og mål
   Hvem interagerer med systemet, og hvad forsøger de at opnå?

2. Scenarier og alternative flows
   Hvilke variationer i flowet kan opstå? Er der undtagelser, fejl eller grænsetilfælde?

3. Pre- og postbetingelser
   Hvilke tilstande skal gælde før og efter use case’en udføres?

4. Testscenarier og testcases
   Udledning af konkrete testcases for hver stibane (main flow, alternate flow, exceptions).

5. Data og miljø
   Specificering af testdata, aktørroller og systemets tilstand.

Dækning og dækningskriterier

Use case-baseret test muliggør flere dækningskriterier:

• Basic Flow Coverage: Dækker kun hovedscenariet.

• Alternative Flow Coverage: Dækker alle variationer og afvigelser.

• Full Path Coverage: Kombinatorisk dækning af alle mulige stibane-forløb (kræver ofte modellering).

Et af de centrale mål for testmanageren er at beslutte hvilken grad af dækning der er nødvendig – typisk afhængig af risikoniveau, forretningskritikalitet og omfanget af krav.

Eksempel på konvertering fra use case til testcase

Use Case: "Godkend betaling"
Hovedscenarie: Kunden angiver kortdata → validering → betaling godkendes.
Alternative flows: Ugyldigt kort, manglende dækning, teknisk fejl.
Testcases (uddrag):
TC1: Gennemfør betaling med gyldige kortdata (main flow).
TC2: Afvisning ved udløbet kort (alt flow).
TC3: Timeout ved kommunikationsfejl (exception flow).

Styrker og svagheder

Fordele:

• Brugervenligt og let at formidle til forretningen.

• Tydelig kobling mellem krav og testcases.

• Hjælper med tidlig validering og acceptkriterier.

• Giver struktureret testdækning på tværs af roller.

Udfordringer:

• Kræver velstrukturerede use cases – ikke altid til stede.

• Kan være ufuldstændige ift. lavniveau-funktionalitet.

• Alternative flows kan overses uden erfaring.

• Risiko for overlap med andre testdesignteknikker (f.eks. beslutningstabeller, tilstandstest).

Anbefalinger for testmanagers

1. Sørg for at use cases er testbare
   Inkluder pre-/postbetingelser og eksplicitte variationer.

2. Integrer med testværktøjer
   Mange værktøjer (Jira, TestRail, qTest) understøtter mapping mellem use cases og testcases.

3. Brug modellering
   Visualiser flows via activity diagrams eller state machines for bedre dækning.

4. Prioritér scenarier efter risiko og forretning
   Ikke alle flows har samme kritikalitet.

5. Auditér dækning løbende
   Brug traceability-matrix til at sikre, at alle kravscenarier testes.

Moderne trends og værktøjer

• Model-Based Testing (MBT) anvender formelle modeller (ofte baseret på use cases) til automatisk testcasegenerering.

• AI-assisteret testdesign (f.eks. med Copilot, Testim) kan analysere use case-tekster og foreslå testscenarier.

• BDD-integration (f.eks. Cucumber): Use case-scenarier kan omskrives som Gherkin-feature files og automatiseres.

Afslutning

Use case-baseret test er et stærkt værktøj for testmanagers, der ønsker at forbinde krav, test og forretningens forventninger på en struktureret måde. Teknikken er særligt egnet i domæner med komplekse brugerinteraktioner, hvor der kræves tydelig dækning og transparens. Forudsætningen for succes er gode input og en disciplineret tilgang til scenarieudvikling og dækning.

 

Sporbarhed i Test – Et Kritisk Element for Kvalitet, Overblik og Effektiv Forandring

Hvad er sporbarhed?

Sporbarhed (eng: traceability) betegner evnen til at forbinde og følge relationer mellem forskellige artefakter i softwareudvikling og test – typisk fra krav → testdesign → testcases → defekter → ændringer → releases. Det sikrer, at alle krav bliver testet, og at ændringer kan spores tilbage til deres oprindelse og konsekvenser.

ISO/IEC/IEEE 29119-1 definerer sporbarhed som “the degree to which a relationship can be established between two or more products of the development process.”

Hvorfor er sporbarhed vigtigt i test?

1. Sikring af dækningsgrad (coverage)

Med sporbarhed kan du sikre, at:

• Alle krav er testet (requirements coverage)

• Testcases svarer til forretningsmæssige og tekniske mål

• Funktionelle og ikke-funktionelle aspekter bliver dækket

Et praktisk eksempel: Et krav om “sikker login med 2FA” bør være forbundet til mindst én test case, der validerer netop dette flow.

2. Effektiv ændringshåndtering

Sporbarhed muliggør hurtig og præcis impact analysis (effektanalyse):

• Hvad skal testes igen ved en ændring?

• Hvilke testcases bliver ugyldige?

• Hvilke krav ændres indirekte?

Ved agile iterationer eller SAFe PI-planlægning kan dette være forskellen mellem målrettet regression og overfladisk test.

3. Kvalitetsstyring og revision

Audits og reviews kræver dokumentation for:

• At krav er opfyldt

• At testcases har dækning

• At fejl er håndteret med korrekt korrektion og verifikation

Det er centralt for compliance (ISO 9001, 27001, 25010) og ved samarbejde med eksterne regulatorer eller kunder.

4. Risikoreduktion

Mangler i sporbarhed kan føre til:

• Forretningskritiske krav der aldrig bliver testet

• Ukontrolleret testeffort og lav ROI

• Uforudsete bivirkninger ved kodeændringer

Sporbarhedens rolle i teststyring

Sporbarhed er et ledelsesværktøj:

• Under planlægning: Hvad skal testes, og hvorfor?

• Under estimering: Hvor mange testcases pr. krav?

• Under statusrapportering: Hvad er dækket, og hvad mangler?

Værktøjer som Jira, TestRail, Xray, Azure DevOps og qTest muliggør automatisk sporbarhed mellem krav, user stories, testcases og defects.

Hvordan etableres og vedligeholdes sporbarhed?

Step 1: Identificér artefakter og relationer

Typiske relationer:

• Forretningskrav → Brugerhistorier → Funktionelle krav

• Funktionelle krav → Testbetingelser → Testcases

• Testcases → Testresultater → Defekter → Ændringer

Step 2: Brug en sporbarhedsmatrix (RTM – Requirements Traceability Matrix)

Eksempel:

Krav ID	Kravbeskrivelse	Testcase ID	Status
REQ-001	Bruger login	TC-01, TC-02	Passed
REQ-002	2FA	TC-03	Failed

Step 3: Automatisér hvor muligt

• Brug værktøjer med indbygget linking

• Integrér med CI/CD for visning af teststatus

Step 4: Hold det opdateret!

Ved hver ændring i krav eller arkitektur skal sporbarheden revideres. Dette kræver disciplin og procedurer – fx ved hjælp af testdesign reviews eller TCM-processer (Test Case Management).

Sporbarhed og effektanalyse

Impact analysis er stærkt afhængig af etableret sporbarhed:

• Ændrer vi én funktion i backend, hvilke user stories, krav og test påvirkes?

• Hvis en API-endpoint ændres, hvilke automatiserede tests skal tilpasses?

Eksempel fra virkeligheden: Ved ændring af valideringslogik i et ERP-system blev 23 testcases, 4 integrationskrav og 1 databasemodel fundet relevante – kun fordi sporbarheden var komplet.

Pitfalls ved manglende eller forkert sporbarhed

• Manglende test af nye eller ændrede krav

• Dobbeltarbejde: samme funktion testet flere gange uden hensigt

• Svært at dokumentere compliance

• Usikkerhed ved release-go/no-go beslutninger

Anbefalinger for testmanagers

1. Inkludér sporbarhed i teststrategi og testplaner
   – jf. ISO/IEC/IEEE 29119-3.

2. Udpeg ansvarlige for vedligehold af sporbarhed
   – typisk testanalytikere eller testkoordinatorer.

3. Evaluer sporbarhed jævnligt
   – som del af retrospectives, audits eller kvalitetsreviews.

4. Træn teamet i vigtigheden af traceability
   – især i agile teams, hvor krav hurtigt ændres.

5. Anvend metrikker
   – fx "coverage ratio" mellem krav og testcases.

Fremtidige tendenser og innovation

• AI-understøttet sporbarhed: f.eks. NLP-drevne løsninger der foreslår links mellem krav og testcases (f.eks. i Copilot4Test, OpenReq).

• Visual traceability maps: interaktive grafer i værktøjer som Enterprise Architect, Helix RM og Polarian ALM.

• Shift-left & shift-right sporbarhed: ikke kun fra krav til test, men også fra telemetry og produktion tilbage til kravdesign.

Afrunding

Sporbarhed er ikke blot en formalitet – det er en nøglefaktor for kvalitet, risikostyring og testeffektivitet. Den bedste testdækning opnås, når alle testaktiviteter er koblet til relevante krav og ændringer, og når ændringer proaktivt bliver vurderet ud fra deres konsekvenser.

 

Kravudarbejdelse og test – Et uadskilleligt makkerpar for succesfuld kvalitet

Indledning

I softwareprojekter er kravene fundamentet for både udvikling og test. Alligevel oplever mange testmanagers, at kravene enten er mangelfulde, tvetydige eller ustabile – hvilket fører til ineffektiv test, forsinkelser og lav tillid til kvaliteten. Dette blogindlæg belyser, hvorfor krav er kritiske for test, hvordan testere og testmanagers kan bidrage til kravkvaliteten, og hvilke metoder og teknikker der kan sikre bedre krav og dermed bedre test.

1. Kravenes betydning for test

Testens effektivitet afhænger direkte af kravkvaliteten. Som det hedder i ISTQB: ”Testbasis must be clear, correct, and complete for high-quality test design.”

Krav har følgende roller for test:

• Testbasis/-grundlag: Testdesign og testcases baseres på krav (funktionelle og ikke-funktionelle).

• Sporbarhed: Krav danner grundlag for test coverage og gap-analyse.

• Kriterier for accept: Acceptance criteria (evt. i Gherkin-format) anvendes til at validere forretningsmål.

• Kommunikation: Krav formidler forventninger mellem forretning, udvikling og test.

Typiske konsekvenser af dårlig kravkvalitet:

• Manglende testbarhed → uklare testcases

• Scope creep og mange change requests

• Uoverensstemmelser i forståelse af, hvad der skal leveres

2. Testers og testmanagers rolle i kravudarbejdelse

I moderne udviklingsmodeller – særligt agile – er testere ikke kun forbrugere af krav, men aktive bidragydere i kravprocessen. Det kaldes ofte for "Shift Left QA involvement."

Roller og ansvar:

Rolle	Bidrag til krav
Testanalytiker	Identificerer mangler, modstridende formuleringer og ikke-testbare krav. Deltager i refinement.
Testmanager	Etablerer governance for kravvalidering og sikrer, at kravene opfylder testbehov. Skaber feedbackloop til kravejere.
Tester (Scrum team)	Omsætter user stories til konkrete testcases, identificerer edge cases og bidrager til eksemplificering.
QA Coach / Test Advisor	Uddanner teams i kravkvalitet og testbarhed. Bringer viden om teknikker som BDD, Specification by Example.

3. Sådan forbedres kravkvaliteten – testdrevet tilgang

A. Kvalitetskriterier for krav (jf. IEEE 830 og ISO/IEC/IEEE 29148)

Et krav bør være:

• Entydigt (kun én fortolkning)

• Nødvendigt (opfylder et forretningsbehov)

• Verificerbart/testbart

• Realiserbart

• Sporbart

• Komplet og konsistent

Testere kan evaluere disse egenskaber i kravgennemgange.

B. Praktiske teknikker

1. Kravgennemgang med testfokus
   – Tjeklistebaseret review af krav ud fra testbarhed
   – Findes krav med implicitte antagelser eller urealistiske acceptkriterier?

2. Brug af testdesignteknikker tidligt
   – Eksempel: Anvend grænseværdianalyse og ækvivalenspartitionering under refinement for at validere regler.

3. Specification by Example / BDD (Gherkin)
   – Formaliserer krav i Given-When-Then-format → forbedrer fælles forståelse og testbarhed.

4. Testbarhedsmatrix
   – Krav spores til testcases → viser dækningshuller

5. Test i Definition of Ready / Definition of Done
   – Inkludér kravkvalitetskriterier i DoR (f.eks. “har testbar acceptkriterium”).

4. Samarbejdsmodeller: QA og Product i samspil

Testmanagers bør facilitere modeller, hvor krav- og testarbejdet smelter sammen:

• Three Amigos (BA + Dev + QA): Fælles afklaringer og eksempelgennemgang

• Living documentation: Krav og tests i samme form (fx Gherkin med Cucumber)

• Kravworkshops med testinspiration: Brug eksempler på edge cases og fejlscenarier for at gøre kravene mere robuste

5. Metrikker og opfølgning

For at sikre kontinuerlig forbedring i kravkvalitet, kan man måle:

• Antal ændringer i krav efter teststart

• Antal krav uden testbarhed (målt i review)

• Antal fejl, som skyldes kravmisforståelser

• Krav coverage (% af krav med testcases)

Brug GQM (Goal-Question-Metric) til at formulere relevante metrikker med tydeligt formål.

Konklusion

Testens succes afhænger i høj grad af, hvor gode kravene er. Derfor bør testmanagers og testere involvere sig tidligt og systematisk i kravudarbejdelsen. Med teknikker som testbarhedsanalyse, kravreviews og Specification by Example kan testfunktionen bidrage direkte til bedre kvalitet – både i krav og i det færdige produkt.

Testledelse handler ikke kun om at sikre test, men om at sikre testbare krav. Det starter med samarbejde og slutter med kvalitet.

 

Hvordan ledelsen kan maksimere værdien af test i softwareudvikling

Test i softwareudvikling er ikke kun en teknisk disciplin – det er et ledelsesansvar. Forkerte testbeslutninger koster tid, penge og omdømme. Dette blogindlæg adresserer, hvordan ledelsen bedst integrerer test i udviklingsforløbet, undgår spild, rekrutterer testbevidste teams og genbruger testkode effektivt.

Hvordan og hvor test skal integreres i softwareudvikling

Effektiv testintegration kræver, at test ikke blot ses som en afsluttende fase (typisk “QA-fasen”), men som en kontinuerlig og iterativ aktivitet gennem hele Software Development Lifecycle (SDLC).

Centrale integrationspunkter:

Fase	Testaktiviteter
Krav/foranalyse	Gennemgang af krav, identificering af testbare acceptkriterier, risikoanalyse
Design	Testdesign parallelt med teknisk design (shift-left), modellering af testscenarier
Udvikling	Enhedstest, komponenttest, statisk analyse, CI/CD-integreret testautomatisering
Test/UAT	Funktionelle tests, brugeraccepttest, regressionssuite
Drift/vedligehold	Overvågning, driftstest, test af hotfixes, metrics for forbedring

Best practice: Følg principperne i ISO/IEC/IEEE 29119-2 og DevOps-teststrategier med fokus på løbende feedback og automatisering. Kombinér med V-modellen eller SAFe, hvor test optræder på alle niveauer.

Testbegreber og -terminologi for ledere

Ledelsen bør mestre et test-sprog, der sikrer, at teststrategier og investeringer forstås og evalueres korrekt.

Nøglebegreber:

• Testdækning: Hvor stor en del af kravene eller koden er dækket af test?

• Defekt-tæthed: Hvor mange fejl opstår per testet enhed?

• Cost of Quality (CoQ): Omkostninger ved fejl, opdelt i forebyggelse, inspektion og fejl i produktion.

• Risiko-baseret test: Testindsatsen prioriteres efter forretnings- og teknologirisici.

• Testautomatisering: Brug af kode til at afvikle og verificere tests kontinuerligt.

Brug testdashboards (f.eks. TestRail, Zephyr eller PowerBI-integrationer) til at formidle disse begreber visuelt til ledelsen.

Almindelige faldgruber i test – og hvordan man undgår dem

1. For sen testinddragelse (anti-pattern: “Testen starter efter udvikling”)
Løsning: Indfør “shift-left” med tidlig testanalyse og deltagelse i backlog-refinements og PI-planning.

2. Ingen genbrug af testartefakter (scripts, data, cases)
Løsning: Udnyt modularisering og versionsstyring (fx i Git) for at gøre testkode genanvendelig på tværs af projekter.

3. Overfokus på UI-tests
Løsning: Afbalancér testpyramiden (unit < integration < UI), og automatisér på de lavere niveauer.

4. Manglende klarhed om testansvar
Løsning: Brug RACI-modeller og definer roller og ansvar tidligt i testplanlægningen.

5. Uklar teststrategi
Løsning: Udarbejd en teststrategi med mål, succeskriterier, coverage-mål og exit-kriterier – helst i alignment med projektets risikoprofil.

Sådan hyrer du testbevidste teams

For at opnå testmodenhed kræver det, at teams har en grundlæggende testbevidsthed, selv blandt udviklere og product owners.

Kendetegn på test-aware teams:

• Reflekterer over acceptkriterier før implementering.

• Anvender TDD, BDD eller lignende metoder.

• Forstår værdien af testdata og miljøer.

• Indgår aktivt i estimering og planlægning af testaktiviteter.

Rekrutteringstips:

• Spørg til erfaring med testautomatisering og testdesign.

• Brug casebaserede interviews (fx "hvordan ville du teste en prisberegner?").

• Inkludér testopgaver i onboarding og kodegennemgangsforløb.

🔍 Værktøjstip: Brug DISC- eller Belbin-profiler til teamdynamikoptimering – testere har ofte analytiske eller detaljefokuserede præferencer.

Værdien af at genbruge testkode

Genbrug af testkode (og testdata) er en af de mest undervurderede værdidrivere i moderne DevOps-kontekster.

Fordele:

• Mindre vedligeholdelse af testsuites

• Øget testdækning via parametrisering

• Hurtigere feedback-loops i CI/CD-pipelines

• Konsistens i testlogik og forretningsvalidering

Eksempler på genbrug:

Område	Eksempel
API-tests	Reusable contracts/test clients
UI-tests	Page Objects og data-driven tests
Performance	Scripts med delte workloads/data
Data	Synthetic data generators med seed-mekanismer

Strategi: Opbyg en “Test Components Library” som shared ressource (eksempelvis i GitLab TestOps eller Azure DevOps Repos).

Konklusion: Ledelsens rolle i test er afgørende

En testmoden organisation kræver ledelsesinvolvering på strategisk niveau. Test er ikke et isoleret værktøj, men en integreret del af værdikæden. Ved at integrere test tidligt, forstå terminologien, undgå faldgruber, rekruttere testbevidste teams og genbruge testkode, opnår virksomheder ikke kun bedre kvalitet – men også en hurtigere time-to-market og lavere totalomkostninger.