søndag den 29. juni 2025

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ådeRelevansNoter
Teststrategi i agile konteksterMiddelIndirekte behandlet gennem transformationsperspektiver
Ledelse og forandringHøjGiver konkrete værktøjer til at lede i transitioner
Kommunikation og stakeholder managementHøjCases og modeller er direkte anvendelige
Agile modenhed og coachingHøjStærk i modenheds- og kulturrefleksioner
Teknisk QA og metrikkerLavSvag 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

DysfunktionTypisk testsituationTiltag med Lencioni som inspiration
Fravær af tillidIngen tør udfordre defekte krav eller fejlagtige antagelserTeamøvelser om sårbarhed, retrospectives med psykologisk sikkerhed som tema
Frygt for konfliktTester undlader at eskalere kvalitetstruslerBrug af “contrarian” roller i møder, faciliteret konflikt
Mangel på engagementUklare beslutninger om test scope eller dækningDecision logs, afstemninger og visualisering af ejerskab
Undgåelse af ansvarFejl skubbes mellem udvikling og testPeer reviews, teamets selvdefinerede forventninger
Mangel på resultatorienteringFokus på individuelle mål, ikke produktkvalitetBrug 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.

 

onsdag den 25. juni 2025

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

MetodeBeskrivelseBrugssituation
Modereret usability testBrugeren udfører opgaver, mens testleder observerer og stiller opklarende spørgsmålDybdegående analyse og kontekstforståelse
Umodereret testBrugere interagerer med systemet alene, typisk via online platformeStørre skala, mindre ressourcetung
Heuristisk evalueringEksperter vurderer grænsefladen ud fra kendte usability principper (eks. Nielsen)Hurtig, tidlig vurdering
Think-Aloud protokolBrugeren verbaliserer sine tanker undervejsIndblik i mentale modeller
Remote testingBrugen observeres via skærmdeling/videooptagelserGeografisk 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.

 

onsdag den 18. juni 2025

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.

 

tirsdag den 17. juni 2025

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 IDKravbeskrivelseTestcase IDStatus
REQ-001Bruger loginTC-01, TC-02Passed
REQ-0022FATC-03Failed

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:

RolleBidrag til krav
TestanalytikerIdentificerer mangler, modstridende formuleringer og ikke-testbare krav. Deltager i refinement.
TestmanagerEtablerer 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 AdvisorUddanner 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.

 

mandag den 16. juni 2025

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:

FaseTestaktiviteter
Krav/foranalyseGennemgang af krav, identificering af testbare acceptkriterier, risikoanalyse
DesignTestdesign parallelt med teknisk design (shift-left), modellering af testscenarier
UdviklingEnhedstest, komponenttest, statisk analyse, CI/CD-integreret testautomatisering
Test/UATFunktionelle tests, brugeraccepttest, regressionssuite
Drift/vedligeholdOvervå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ådeEksempel
API-testsReusable contracts/test clients
UI-testsPage Objects og data-driven tests
PerformanceScripts med delte workloads/data
DataSynthetic 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.

 

Double Half Time – En projektmetode med klare gevinster for testledelse

Hvad er Double Half Time?

Double Half Time (DHT) er en enkel, men effektiv projektstyringsmetode og baseret på princippet om konstant fremdrift og maksimal transparens. DHT opdeler projektet i fire faser baseret på to centrale milepæle:

  1. Halv tid – hvor halvdelen af tiden er gået.

  2. Halv omfang – hvor halvdelen af det forventede scope er leveret.

Ved hver milepæl foretages en vurdering: Hvad er realistisk at nå inden for den resterende tid og ressourcer? Fokus flyttes fra at følge en rigid plan til løbende replanlægning, scope-justering og prioritering.

DHT er et adaptivt og beslutningsorienteret framework, ikke et klassisk planlægningsværktøj. Det understøtter agil realisme.

Relevans for testledelse

1. Scope og testfokus

I DHT er det afgørende at identificere det vigtigste leverbare indhold først. For testledere betyder det:

  • Fokus på risikobaseret test fra start.

  • Prioritering af testområder baseret på de funktioner, der forventes leveret i første halvdel.

  • Mulighed for tidlig testdesign og testdataforberedelse, når scope bliver klarlagt løbende.

Eksempel: En digital selvbetjeningsløsning har 20 features. Ved halv tid er kun 10 estimeret leveret. Testlederen fokuserer ressourcerne på disse og tilpasser testplanen iterativt.

2. Tidligt feedback-loop

DHT tvinger projektet til at levere konkret output hurtigt. For testområdet betyder det:

  • Tidlig testinvolvering og review af krav/specifikationer.

  • Brug af test first/early testing-principper (jf. ISTQB og ISO 29119).

  • Lettere implementering af kontinuerlig test og regressionstest i CI/CD-miljøer.

3. Styrket dialog og governance

Ved hver milepæl i DHT skabes en fælles forståelse for status. Testlederen får:

  • Et klart mandat til at kommunikere teststatus i relation til forretningsmål.

  • Mulighed for at påvirke scope-justeringer med afsæt i testdækning og kvalitetsevidens.

  • Bedre forudsætninger for at anvende KPI’er og testmetrikker baseret på leveret værdi (ref. GQM-metoden).

Sammenhæng med kendte rammeværk

RammeværkHvordan DHT passer ind
Scrum/AgileKomplementær metode til release planlægning og sprintprioritering. Kan bruges som overordnet styring på epik-niveau.
SAFeRelevant i PI-planning og ved program-niveau prioritering. Testlederen kan synliggøre kvalitetsrisici ift. MVP-scope.
TMMiUnderstøtter procesområder som "Test Planning" og "Test Monitoring & Control". Fokuserer på værdibaseret test.
ISO 29119-3Tillader planændringer på baggrund af milestones. DHT integreres som beslutningspunkt i testplanen.

Faldgruber og anbefalinger for test managers

RisikoAnbefaling
Scope creep under 2. halvdelTestlederen skal insistere på impact-analyse og retest-omkostninger som konsekvens.
Mangel på klare kvalitetskriterierSæt tydelige "definition of done" og acceptkriterier op tidligt.
Manglende værktøjsunderstøttelseSørg for visualisering via dashboards eller test management tools (fx Xray, Zephyr).
Taktisk frem for strategisk tænkningBrug DHT som en leverancestyreform, men fasthold teststrategien som langsigtet kompas.

Konklusion

Double Half Time er ikke bare en projektstyringsmetode – det er en mindsetændring, som matcher nutidens krav om fleksibilitet, transparens og forretningsværdi. For test managers tilbyder det en struktureret tilgang til at planlægge, justere og synliggøre testindsats med maksimal effekt, især i hybride og agile miljøer.

 

onsdag den 11. juni 2025

Emotionel intelligens som en nøglekompetence for testmanagers

I en teknologidrevet og ofte presset virkelighed glemmer mange, at ledelse i testverdenen ikke kun handler om processer, teknikker og metrikker – men i høj grad om mennesker. Emotionel intelligens (EI) udgør derfor et vigtigt, men ofte undervurderet element i testmanagerens værktøjskasse.

Hvad er emotionel intelligens?

Daniel Goleman (1995) populariserede begrebet emotional intelligence og identificerede fem hovedkomponenter:

  1. Selvbevidsthed – evnen til at forstå egne følelser og deres indflydelse på adfærd.

  2. Selvregulering – evnen til at kontrollere impulser og bevare roen under pres.

  3. Motivation – indre drivkraft og vedholdenhed, også under modgang.

  4. Empati – evnen til at forstå og respondere på andres følelser.

  5. Sociale færdigheder – evnen til at opbygge relationer og navigere i komplekse sociale sammenhænge.

I konteksten af testledelse påvirker disse komponenter direkte testteamets præstation, trivsel og samarbejde.

Anvendelse i testledelse

1. Skab psykologisk tryghed

Ved at udvise empati og aktiv lytning kan testmanageren skabe et miljø, hvor testere tør sige deres mening, stille spørgsmål og indrømme fejl. Dette fremmer hurtigere læring og bedre risikohåndtering – fx under retrospectives eller defektanalyser.

Eksempel: I en UAT-fase opdager en tester sent en kritisk defekt. En testmanager med høj EI reagerer ikke med bebrejdelse, men fokuserer på løsning og læring – hvilket øger fremtidig åbenhed.

2. Forhandling og forventningsstyring

EI styrker evnen til at kommunikere klart med både tekniske og ikke-tekniske interessenter. Især i projekter med mange ændringer (fx agile/scrum eller SAFe) er det essentielt at kunne forklare testmæssige konsekvenser uden at fremstå defensiv.

3. Stresshåndtering og ledelse under pres

Testledere møder ofte deadlines, forsinkelser og pressede stakeholders. EI gør det muligt at bevare roen og træffe velovervejede beslutninger, frem for at handle reaktivt. Dette smitter af på teamet og bevarer produktiviteten.

4. Motivation og feedback

Ved at forstå hvad der driver den enkelte tester, kan testmanageren give mere meningsfuld feedback og opnå større engagement. For nogle handler det om teknisk udfordring, for andre om anerkendelse eller resultater.

Begrænsninger og faldgruber

Selvom EI er en vigtig kompetence, skal den ikke opfattes som en erstatning for faglighed, procesforståelse eller beslutningskraft. Her er nogle vigtige begrænsninger:

BegrænsningBeskrivelse
SubjektivitetEI kan føre til bias, fx hvis en testleder ubevidst prioriterer de personer, de bedst forstår eller sympatiserer med.
Over-empatiFor meget hensyn kan forsinke nødvendige, men upopulære beslutninger – fx nedskæring i testomfang.
Kulturel biasEI-udtryk varierer på tværs af kulturer; ikke alle teams responderer ens på følelsesmæssig åbenhed.
Begrænset målelighedDet er svært at måle EI’s effekt på testresultater kvantitativt, hvilket kan udfordre ROI-argumentation.

Best Practices for testmanagers

TiltagBeskrivelse
Reflekter dagligtBrug 5 minutter til at reflektere over hvordan dine følelser påvirkede dine beslutninger.
Aktiv lytningAfbryd ikke. Gentag det, du har hørt, og stil opklarende spørgsmål.
Følelsesmæssige journalerNotér reaktioner og mønstre over tid. Bruges fx i stressede projektsituationer.
Peer feedbackSpørg kollegaer hvordan dine reaktioner påvirker dem. Indarbejd i test team retrospectives.
KonfliktsimulationTræn svære samtaler (fx ved afvisning af testindsats) i rollespil med PM’er eller POs.

Afslutning

Emotionel intelligens er ikke en "blød" kompetence i modsætning til "hårde" testteknikker – den er et forstærkende lag, som gør en testmanager i stand til at få det bedste frem i sit team og navigere kompleks projektvirkelighed. Men det kræver bevidst træning og balance. EI er et værktøj – ikke en erstatning for beslutningsdygtighed.

 

Effektiv testautomatiseringsstrategi: En ledelsesguide baseret på ISTQB

Introduktion

Testautomatisering er ikke et mål i sig selv – det er et middel til at øge effektivitet, reducere time-to-market og forbedre testkvalitet. Men uden en strategi risikerer automatisering at blive dyr, ukoordineret og ineffektiv. Dette blogindlæg præsenterer en struktureret tilgang til at udvikle en testautomatiseringsstrategi, der tager udgangspunkt i ISTQB Test Automation syllabus og er målrettet ledere og testmanagers.

Hvorfor en testautomatiseringsstrategi?

En strategi sikrer:

  • At automatisering understøtter forretningsmål

  • Fokus på langsigtet vedligeholdelse og genbrug

  • Forventningsafstemning mellem ledelse, udvikling og QA

  • Validering af investeringens Return on Investment (ROI)

"Failing to plan is planning to fail" gælder i høj grad for automatisering.

Komponenter i en ISTQB-baseret testautomatiseringsstrategi

Nedenstående komponenter dækker ISTQB's anbefalede strategiopbygning og bør indgå i ethvert testautomatiseringsinitiativ.

1. Formål og mål

  • Beskriv, hvorfor automatisering ønskes (f.eks. regression, hyppige builds, CI/CD-understøttelse).

  • Knyt målene til forretningsværdier (eks. hurtigere releases, færre produktionsfejl).

2. Scope og begrænsninger

  • Hvilke testtyper skal automatiseres? (unit, API, UI, end-to-end, performance?)

  • Hvad skal ikke automatiseres – og hvorfor? (eks. adfærdstunge exploratory tests)

3. Arkitektur og design af testautomatisering

  • Testautomatiseringsarkitektur (modulært? keyword-driven? BDD?)

  • Integration med build pipelines (CI/CD), versionering og testdatahåndtering

Eksempel: Anvendelse af Page Object Model for UI-tests i Selenium-rammen.

4. Værktøjsvalg og værktøjsstrategi

  • Hvilke værktøjer understøtter strategien? (open source vs. enterprise)

  • Konsistens, integration og fremtidssikring

  • Udvælgelse baseret på en Proof of Concept (PoC)

5. Testdata og testmiljø

  • Strategi for syntetisk testdata, anonymisering og miljøsynkronisering

  • Infrastrukturkrav (Docker, Kubernetes, cloud-baserede testmiljøer)

6. Roller og ansvar

  • Hvem ejer automatiseringsplatformen?

  • Automatiseringsarkitekt, testdesignere, udviklere – og samspillet med QA

7. Kriterier for udvælgelse og prioritering

  • Hvordan udvælges scripts, der skal automatiseres?

  • Baseret på hyppighed, stabilitet, kritikalitet, kompleksitet

Eksempel: ISTQB anbefaler prioritering ud fra business risk and ROI estimation.

8. Måling og opfølgning

  • KPI’er som:

    • Automatiseringsdækning

    • Vedligeholdelsesindsats

    • Tid til fejlidentifikation

  • Evaluer mod mål (f.eks. “80 % af smoke tests skal være automatiserede om 6 måneder”)

9. Risikovurdering og faldgruber

  • Hyppige risici:

    • Forældet automatisering

    • Manglende kompetencer

    • Urealistiske forventninger

  • Forhold til teknisk gæld og testmodenhed (f.eks. TPI NEXT/TMMi)

Strategiens tilpasning til modenhed og organisation

ISTQB anbefaler, at strategien matcher organisationens test- og udviklingsmodenhed. Eksempler:

ModenhedAutomatiseringstilgang
Lav modenhedFokus på stabil regression, PoC'er, pilotprojekter
Høj modenhedCI/CD-integration, in-sprint automation, modellering

Desuden skal strategien tilpasses:

  • Udviklingsmodeller (Agile, DevOps, V-Model)

  • Testpolitik og testplaner (jf. ISO 29119-2/-3)

Konkrete faldgruber fra praksis

  1. Automatisering af alt – uden cost-benefit vurdering

  2. Manglende vedligeholdelse – scripts “rådner” over tid

  3. Fravær af strategi – værktøjer vælges ad hoc uden governance

  4. Manglende ejerskab – testautomatisering er alles og ingens ansvar

Afslutning og anbefalinger

En god testautomatiseringsstrategi:

  • Skaber retning og forretningsværdi

  • Understøtter skalerbar og vedligeholdelig automatisering

  • Involverer de rette interessenter og forankrer ejerskab

Brug ISTQB’s struktur som skabelon, og tilpas efter jeres modenhed, mål og kontekst.