Fra klassisk til moderne – testteknikker der gør en forskel i 2025 – Del 2

Af: Ole Chr. Hansen, Q Nation A/S

Del 1

Den artikel er en fortsættelse af tidligere artikel også publiceret på Q Nations LinkedIn side ultimo maj 2025. Den første del omfattede blackbox-testteknikkerne grupperet i databaserede, adfærdsbaserede og regelbaserede testteknikker. Herefter kommer de resterende testteknikker som er valgt medtaget.

Erfaringsbaserede testteknikker

Erfaringsbaserede teknikker bygger på testerens viden, intuition og tidligere erfaringer med lignende systemer eller domæner. I modsætning til de formelle teknikker, der baserer sig på specifikationer eller modeller, så drives disse teknikker af menneskelig ekspertise – eksempelvis kendskab til typiske fejl, brugeradfærd eller produktets historik. ISTQB ATA 4.0 fokuserer især på at strukturere disse aktiviteter gennem metoder som session-baseret test (eksplorativ test), tjekliste-baseret test samt nævner fænomenet crowdtesting. Disse tilgange supplerer de systematiske tests ved at finde fejl, man ikke nødvendigvis ville opdage gennem systematisk dækning.

Udforskende test (session-baseret)

Beskrivelse: Udforskende test (exploratory testing) er en dynamisk, læringsorienteret tilgang hvor testdesign og testafvikling sker parallelt – testeren tilpasser løbende sine test baseret på indsigt og resultater undervejs. ATA 4.0 fokuserer på en struktureret variant kaldet session-baseret test management (SBTM). Her planlægger man tests i tidsbokse (“sessions”) med et defineret charter eller mission for hver session (hvad man vil undersøge), og fører notater over fundne defekter og dækket funktionalitet. Hver testsession varer typisk 60-120 minutter og afsluttes med en opsummering (session report). Formålet er at bevare fleksibiliteten og kreativiteten fra explorativ test, men samtidig måle og styre indsatsen (f.eks. at sikre at kritiske områder faktisk er blevet udforsket).

Styrker: Udforskende test er meget effektiv til at opdage skjulte, komplekse problemer – især usability issues, kontekstafhængige fejl, eller unikke kombinationer af handlinger som foruddefinerede cases ikke dækker. Testeren kan reagere på systemets adfærd i real-time, hvilket ofte leder til dybere test af områder der viser tegn på svaghed. Denne teknik udnytter erfarne testerers intuition og domænekendskab optimalt, og kan give høj bug-finding rate på kort tid. Den er også nyttig når dokumentation er mangelfuld; testeren kan lære systemet ved at bruge det og designe tests undervejs. Session-baseret formatet tilføjer ansvarlighed – man kan spore hvad der er testet i hver session og hvilke områder der mangler, hvilket forbedrer transparens i en ellers fri tilgang.

Svagheder: Resultaterne afhænger stærkt af testerens kompetencer – en mindre erfaren tester kan overse kritiske problemer. Der er en risiko for manglende reproducérbarhed, hvis testeren ikke grundigt dokumenterer hvad de gjorde for at fremprovokere en fejl (explorative noter kan afhjælpe dette). Dækningen kan være svær at kvantificere sammenlignet med formelle teknikker; man kan ikke let sige “100% af krav testet” selvom man har brugt 5 sessions, fordi explorativ test ikke garanterer bestemt dækning. Derfor skal testlederen ofte supplere med checklister eller charters for at få rimelig spredning. Endelig kan stakeholderes opfattelse være, at explorativ test er ustruktureret – hvorfor klare charters og rapporter er vigtige for at demonstrere værdien.

Anvendelse: Explorativ test anvendes ofte i agile projekter, hvor der er kort tid til test, krav ændrer sig løbende, og man ønsker løbende feedback på produktet. Også mod slutningen af testforløb (f.eks. efter formelle testcases er kørt) giver det mening at “gøre noget uventet” med systemet for at se, om der gemmer sig flere fejl. Session-baseret test bruges også til produkttests (tidlige builds), beta-test internt osv., hvor fokus er på at finde flest mulige problemer hurtigst muligt snarere end at bevise opfyldelse af hvert krav. Forberedelsen af exploratory test opdeles typisk i to mere konkrete aktiviteter: at udarbejde testcharters og at udarbejde tjeklisterfor experience-based test, hvilket understreger behovet for planlægning selv i explorativ test.

Eksempel: En tester får til opgave at udforske den nye “rapportgenerator” i et BI-system. Charteret lyder: “Undersøg funktionaliteten for at generere, eksportere og slette rapporter, med fokus på fejlmeddelelser og data-integritet.” Testeren starter sessionen og prøver forskellige ting: opretter rapporter med korrekte og forkerte parametre, eksporterer til forskellige filformater, forsøger at slette rapporter der er i brug, osv. Undervejs noteres observationer. Under eksport opdager testeren f.eks., at hvis filnavnet indeholder et specielt tegn, får man en uforståelig fejlmeddelelse – dette noteres som en defekt (mulig encoding bug). Testeren bemærker måske også at slette-funktionen er tilladt selv for rapporter der er åbne, men der sker ingen advarsel (en potentiel usability issue). Ved sessionens afslutning dokumenteres fundne fejl, samt hvilke områder af rapportgeneratoren der blev dækket (og at f.eks. diagram-eksport ikke nåede at blive testet, så det må tages i en anden session). Denne ene session har med stor sandsynlighed afdækket flere problemer på én time – nogle måske ikke beskrevet i kravene – ved at bruge testerens erfaring og interaktion med systemet.

Tjekliste-baseret test

Beskrivelse: Tjekliste-baseret test involverer brug af foruddefinerede lister af punkter, som en erfaren tester gennemgår for at sikre, at visse aspekter bliver vurderet. Tjeklisten kan indeholde alt fra generelle kvalitetskriterier til specifikke tidligere fejltyper, der skal gen-testes. Det er en erfaringsbaseret teknik, fordi indholdet af tjeklisten typisk stammer fra viden om systemet eller domænet – f.eks. kendte risikoområder, branchespecifikke retningslinjer eller “lessons learned” fra tidligere projekter. Testeren bruger listen som guide under test: for hvert punkt på listen designes og udføres en eller flere tests. Eksempler på checklister: en web-checkliste (“Har alle formularfelter klient- OG servervalidering? Er alle links HTTPS?”), en sikkerhedstjekliste (“Prøv SQL injection på alle inputfelter”), eller en simpel release-regression tjekliste (“Installer app – virker login? Kan data fra forrige version stadig ses?”). Det forventes typisk, at testanalytikeren kan udarbejde sådanne tjeklister til at støtte reviews og tests.

Styrker: Checklister sikrer systematik i erfaringsbaseret test – man mindsker risikoen for at glemme vigtige ting. De kan nemt genbruges og forbedres over tid, således at testorganisationens samlede erfaring akkumuleres i listerne. For nye teammedlemmer giver tjeklister en guide til hvilke slags fejl man skal lede efter, selv hvis de ikke har al erfaringen selv. Checkliste-test er også fleksibel: testeren kan følge listen men stadig udføre tests kreativt omkring hvert punkt. Desuden er det en hurtig måde at få dækket mange “små” verifikationer, som måske ikke fremgår af krav (fx “CTRL+Z fortryder i tekstfelt? – check” kunne være på en usability-checkliste).

Svagheder: Hvis checklister bliver for generelle eller statiske, kan testeren komme til at følge dem mekanisk uden at tænke innovativt, hvilket underminerer formålet. Lister skal vedligeholdes og opdateres, ellers tester man måske efter forældede standarder eller kendte bugs der ikke længere er relevante. Over-afhængighed af checklister kan også betyde, at man kun finder det, man på forhånd vidste at lede efter – ikke nytilkomne slags fejl. Altså skal checkliste-test stadig kombineres med åben udforskning. Dokumentation kan være sparsom: typisk markeres blot "done" per punkt, men det siger ikke præcist hvilke testtrin der blev udført – så sporbarhed til specifikke krav kan mangle.

Anvendelse: Mange organisationer har standard-checklister for fx webapplikationer, mobilapps, sikkerhedskontrol, performance sanity checks, etc. Også indenfor regulerede brancher kan man have checklister for lovkrav (f.eks. “opfylder systemet GDPR-artikel X?”). Testanalytikere kan udarbejde specifikke checklister som supplementsdokumentation – fx efter gentagne fejl i et system kan man lave en “regression checklist” for kommende releases, som sikrer at disse fejltyper tjekkes.

Eksempel: I en finansiel applikation vil man måske lave en checkliste for rapporteringsfunktionen med punkter: 1) “Kontroller at afrunding sker korrekt ved 2 decimaler”, 2) “Kontroller at rapportdato kan vælges indenfor gyldigt interval”, 3) “Kontroller at eksport til PDF bevarer alle kolonner”, 4) “Prøv en uautoriseret bruger – skal nægtes adgang”, osv. En tester kan følge denne liste og for hvert punkt afvikle en eller flere hurtige tests. Punkt 1 kunne testes ved at generere en rapport med værdier der kræver afrunding og se resultatet, punkt 4 ved at logge ind som en bruger med lavere rettigheder og forsøge at åbne rapportmodulet. Når listen er gennemgået, har testeren rimelig sikkerhed for at de mest kritiske kendte fejlområder er tjekket. Hvis en ny type fejl opdages undervejs (fx eksport til Excel giver korrupt fil), kan teamet vælge at tilføje et nyt punkt til fremtidige checklister, således at den kollektive viden øges.

Fejlgætning (Error Guessing)

Beskrivelse: Fejlgætning er en uformel teknik, hvor testerens erfaring med typiske fejl bruges til at udlede testtilfælde, der sandsynligvis kan afsløre defekter. Der er ikke en fast procedure; det handler om at spørge “hvor kunne der tænkes at være fejl?” baseret på kendskab til fx tidligere fejlrapporter, udviklerens svagheder, kompleks kode, eller generelle “fejlmønstre” (f.eks. “off-by-one” ved loops, nulstillingsfejl ved reset-funktion, osv.). Fejlgætning var fremhævet på Foundation-niveau og indgår implicit stadig i Advanced (som en del af erfaringstilgangen). Teknikken supplerer typisk de mere strukturerede metoder.

Styrker: Kan være hurtig og produktiv, især i hænderne på en meget erfaren tester. Hvis man ved at et bestemt modul historisk har været fejlbehæftet, kan man målrette tests derhen uden først at lave dyb analyse. Det favner de “skæve” testideer, som formelle teknikker ikke dækker – f.eks. input af ’null’ i alle felter, bruge maksimum filstørrelse, gentagne hurtige klik på en knap (race condition), etc., fordi testeren gætter at disse yderpunkter kan være problematiske.

Svagheder: Meget personafhængig og ikke systematisk – to forskellige testere vil ofte gætte vidt forskelligt. Ikke komplet: man kan ikke måle eller vide hvor meget der er testet, da det hele var ad hoc. Hvis man har begrænsede ressourcer, risikerer man at fokusere på forkerte gæt og misse banale ting som en struktureret test ville have fanget. Derfor bruges fejl-gætning bedst som supplement, ikke primær metode.

Anvendelse: Fejl-gætning sker ofte spontant under test – en tester prøver lige “et alternativt input” eller “gentager den handling 10 gange hurtigt” for at se om noget brister. I planlagt form kan man ved testplanlægning brainstorme en liste af potentielle fejlscenarioer (gerne teamøvelse), som man så eksplicit tester. Mange agile teams gør dette ved sprint-planning eller før test af en user story: “hvad kunne gå galt her?” og så sikrer at mindst én test pr. gæt udføres.

Eksempel: Efter at have testet et nyt filupload-modul ifølge specifikationen (korrekte filformater, størrelser osv.), beslutter testeren at prøve fejlgætning: Hvad hvis to filer uploades samtidig med samme navn? Hvad hvis en fil uploades og slettes meget hurtigt derefter? Hvad hvis filnavnet er 300 tegn langt? Disse scenarier er måske ikke beskrevet i krav, men testeren gætter, at de kunne volde problemer – og ganske rigtigt: ved 300 tegns filnavn crasher modulet. Denne defekt var fanget udelukkende via testerens intuition og erfaring (tidligere har et andet modul haft problemer med lange navne). Fejlgætning gav pote i dette tilfælde.

Crowdtesting (crowdsourcet test)

Beskrivelse: Crowdtesting indebærer at få en større gruppe eksterne personer – typisk end-users eller freelance testere fra hele verden – til at teste applikationen på forskellige enheder, lokationer og brugssituationer. Det er en form for beta-test i stor skala, ofte organiseret via platforme, hvor man udstiller en app og definerer nogle testcharters eller områder, og så rapporterer crowdtesterne tilbage med fundne bugs, usability feedback osv. ATA 4.0 omtaler crowdtesting som en del af erfaringsbaseret test, hvilket afspejler at det ikke er en teknisk teknik men en tilgang til at udnytte mange menneskers erfaring og variation.

Styrker: Crowdtesting kan give bred dækning under realistiske forhold – fx mange forskellige smartphone-modeller, operativsystem-versioner, netværksforhold, sprogindstillinger, som internt testteam ikke kunne dække økonomisk. Det bringer friske øjne: crowdtestere kan opdage problemer, som interne folk overser pga. blindhed for egne fejl. Det er skalerbart; hvis man har brug for at teste hurtigt på kort tid, kan man hyre 50 crowdtestere i en uge i stedet for at ansætte og træne folk. For usability og lokaliseringsaspekter er crowd særlig værdifuld, da man får feedback fra målgruppen selv.

Svagheder: Kontrol og kvalitet kan være udfordring. Crowdtestere har varierende kompetenceniveau, og deres bug-rapporter kan være af svingende kvalitet (dårligt beskrevet, duplicates etc.). Man skal typisk bruge tid på ’triage’ og validere deres fund. Sikkerhed og fortrolighed er et issue – man kan ikke crowdteste med hemmelige projekter eller data uden risiko for læk. Koordinering kan være svær: man må udstikke klare instrukser, ellers tester de måske overfladisk eller misforstår fokus. Derudover motiveres mange crowdtestere af betaling pr. bug, hvilket kan skævvride til at rapportere mange småting for belønningens skyld. Så crowdtesting egner sig ikke til alle projekter, men mest som supplement i de rigtige tilfælde.

Anvendelse: Ofte brugt til B2C mobilapps, websider op mod en release, for at få sidste øjebliks feedback på tværs af platforme. Også populært til spiltest, hvor mange gamere kan deltage i en beta-test. Nogle domæner (fx offentlig sektor, enterprise) bruger det sjældent pga. datahensyn. Fra testanalytikerens synspunkt kan crowdtesting ses som en måde at udføre erfaringsbaseret eksplorativ test i stor skala: man definérer måske et testcharter til crowden (“Prøv at finde så mange funktionsfejl i modul X som muligt indenfor 48 timer”) og lader mængden gøre arbejdet – hvorefter man samler op og integrerer fundene.

Eksempel: En startup har udviklet en ny rejseplanlægnings-app og vil gerne teste den på mange forskellige telefoner og i forskellige lande for at se om der opstår problemer med lokationstjenester, lokale sprog osv. De engagerer 100 crowdtestere gennem en platform. Testerne får at vide at de skal prøve at oprette rejser, søge efter hoteller, købe billetter gennem app’en etc., og rapportere alt mærkeligt de ser. Resultatet: indenfor få dage modtager de 200 bug-rapporter. Blandt disse finder de kritiske fejl som at app’en crasher ved dårlig internetforbindelse (noget intern test ikke opdagede, da de altid brugte WiFi), og at japanske tegn i bynavne vises som spørgsmålstegn (et lokaliseringissue). Denne bredt funderede test via crowd afslørede altså nogle reelle problemer lige inden lancering, som teamet kunne nå at rette. Ulempen er, at mange duplikate eller irrelevante rapporter også kom ind, men det håndterede de ved  ’triage’ – en lille pris at betale for den værdifulde feedback fra det virkelige liv.

Nye og moderne testteknikker udover ATA-pensum

Udover de klassiske teknikker i ISTQB-pensum er der de seneste år kommet nyere metoder og værktøjer, som enten bygger videre på disse teknikker eller supplerer dem for at imødekomme moderne udviklingsmetoder og systemtyper. Nedenfor analyseres nogle fremtrædende eksempler: modelbaseret test, AI-baseret risikotestoptimering, automatiseret test case-generering, kontinuerlig test (DevOps) samt testtilgange for low-code/no-code platforme. Der fokuseres på, hvordan de adskiller sig fra eller udvider de traditionelle teknikker, samt deres styrker, svagheder og anvendelse.

Modelbaseret test (MBT)

Modelbaseret test indebærer, at man bygger abstrakte modeller af systemets forventede opførsel eller logik, og derefter automatisk genererer testcases ud fra disse modeller. En model kan f.eks. være en tilstandsmodel, en UML-aktivitet/sekvensdiagram, en matematisk maskine eller en beslutningsmodel. Softwaren til MBT traverserer modellen for at udlede testscenarier, ofte ud fra definerede dækningskriterier (f.eks. alle tilstandsovergange, alle kombinationer af beslutningsveje, osv.). Disse genererede testcases er først “abstrakte” – de ligger på samme niveau som modellen – men man kan dernæst mappes til konkrete testscript der kan afvikles mod SUT (System Under Test). MBT er altså en systematisk fremgangsmåde, der kan automatisere meget af testdesignprocessen, hvilket er en stor fordel især for regressionstest og komplekse systemer.

Sammenhæng med ISTQB-teknikker: MBT kan ses som en overbygning på flere af de kendte teknikker. Fx er Tilstandsovergangstest ofte en manuel udgave af MBT: man laver en tilstandsmodel og laver tests. Med MBT fodrer man modellen til et værktøj, der så genererer testcases for en. Beslutningstabeller eller regelmodeller kan på samme måde bruges: i MBT-værktøjer (som f.eks. GraphWalker, Spec Explorer) kan man modellere betingelser og få genereret test flows. Modelbaseret test automatiserer også kombinationsdækning; fx hvis man har en tilstandsmodel med parametre, kan MBT generere scenarier der kombinerer disse parametre systematisk. Så MBT supplerer ISTQB-pensum ved at øge graden af automatisering i testdesign og håndtere større kompleksitet end man let kan manuelt.

Styrker: Modelbaseret test reducerer den menneskelige arbejdsbyrde ved at generere testscripter og data automatisk. Det kan drastisk forbedre testdækningen – modeller kan afdække grænsetilfælde, som en testdesigner måske glemmer. MBT fremmer også en tæt kobling mellem krav/design og tests: hvis modellen laves ud fra krav, sikrer genererede tests en form for krav-baseret dækning. Ved ændringer kan man opdatere modellen og regenere tests, hvilket øger vedligeholdelseseffektiviteten. Studier og industri-rapporter fremhæver fordele som hurtigere testdesign, mindre redundans i tests og bedre alignment med forretningen. Desuden kan MBT værktøjer integrere med testautomatisering frameworks, så hele kæden fra kravmodel til eksekveret testcase er automatiseret – dette understøtter Continuous Testing/DevOps, hvor hurtig tilpasning af tests er nødvendig.

Svagheder: Udfordringen ligger i at opbygge og vedligeholde de påkrævede modeller. Det kræver nye færdigheder af testanalytikere (modelleringsteknik, f.eks. at kunne lave et præcist UML statechart). Hvis kravene er uklare, kan modellen blive ukorrekt, og så genererer man blot forkerte tests hurtigere. MBT-implementering kan have en betydelig opstartsomkostning: man skal vælge værktøj, modellere måske hele applikationen eller kritiske dele, og integrere med pipelines. For små projekter kan det være overkill. Der er også en fare for “blindt punkt”: værktøjet genererer tests i flæng, men hvis modellen mangler en forretningsregel, vil ingen test fange det – derfor skal modeller valideres. Endelig, genererede tests kan være svære for mennesker at læse, hvilket kan gøre fejlanalyse mere kompleks (“Hvad prøvede denne auto-test egentlig at gøre?”).

Anvendelse: MBT er anvendt succesfuldt i domæner som telecom, banking, indlejrede systemer, hvor man har formelle specifikationer og langvarige produkter, der kan drage nytte af automatikken. Der findes også ISTQB-Foundation i Model-Based Tester, hvilket viser stigende industriinteresse. I agile sammenhænge kan MBT bruges ved at udlede modeller fra krav (f.eks. BDD-scenarier kan tolkes som modeller). Overordnet giver MBT størst værdi, når kompleksiteten er høj og testene ofte skal gentages(regression), eller når man ønsker tidlig testdesign (modeller kan laves før koden er klar, endda til at generere “stub-tests” for TDD).

Eksempel: Et togstyringssystem har komplekse signal- og togtilstandslogikker for sikkerhed. I stedet for at skrive hundredevis af manuelle testcases, udvikler testteamet en tilstandsmodel af togkontrollen (med statusser: Kør, Bremse, Nødstilstand, mv., og events: sensor input, førerhandlinger etc.). De angiver i MBT-værktøjet at alle overgange i modellen skal dækkes af test. Værktøjet genererer automatisk en række testsekvenser: f.eks. “Start i Kør, modtag nødbremsesignal → system skal til Nødstilstand; derefter nulstil alarm → system tilbage til Kør”, og så videre for alle mulige sekvenser. Disse sekvenser oversættes til testscript, som køres mod et simuleret togsoftware. På kort tid er et meget stort kombinationsrum afprøvet. Under en af disse genererede sekvenser finder man en fejl: Hvis nødbremse aktiveres præcis samtidig med et hastighedsskiftsignal, går systemet i uventet tilstand. Denne niche-situation var fanget af MBT’s grundige dækning – noget man let kunne have overset med manuelle tests. Dette eksempel illustrerer, hvordan MBT bygger videre på tilstandstest-teknikken, men løfter den op med automation og dermed finder subtile fejl mere effektivt.

AI-baseret risiko-baseret testoptimering

Risikobaseret test er velkendt i ISTQB: man prioriterer tests mod de funktioner med højest risiko (fejl-påvirkning * sandsynlighed). AI-baseret testoptimering bruger nu kunstig intelligens og maskinlæring til at gøre denne prioritering og optimering mere dynamisk og datadrevet. I stedet for udelukkende at stole på menneskelig vurdering af risiko, kan AI analysere fx historiske defekter, kodeændringer, testdækning, brugertrafikmønstre m.m., og forudsige hvor nye fejl mest sandsynligt vil opstå. På baggrund af dette kan testværktøjer automatisk vælge eller generere de vigtigste tests for en given release. Dette er særligt relevant i kontinuerlig integration/deployment miljøer, hvor man ønsker at køre et mindre testsubset, der alligevel giver maksimal risikodækning.

Hvordan supplerer det ISTQB?: Traditionelt risikobaseret test er manuelt: testmanager opstiller risikomatrice, testcases tagges og prioriteres. Med AI kan dette gøres adaptivt: hver gang ny kode commit'es, evaluerer AI-modellen impact og risk for testsuite, og vælger de tests der skal køre først (eller eneste i et hurtigt run). Dette forlænger idéen om risikobaseret test ved at automatisere risikovurderingen og gøre den kontinuert. ATA-pensum lægger vægt på at testanalytikeren analyserer påvirkningen af ændringer for at beslutte regressionstestens omfang. Her kan AI hjælpe ved at analysere ændringsfiler og tidligere fejl for at spotte risikoområder. Med andre ord, AI bringer hastighed og mønstergenkendelse ind i risikoanalysen.

Styrker: AI kan håndtere store datamængder og komplekse mønstre, som mennesker ikke nemt overskuer. For eksempel kan en ML-model (Machine Learning) finde korrelation mellem modul X og historisk høj fejlrate ved visse ændringstyper, og således advare om at risiko er høj ved en given commit. Dette gør testfokus skarpere og kan reducere testtid med op til ~30% ifølge Gartner, fordi man ikke tester alt unødvendigt. AI-drevet prioritering sikrer også, at når tiden er knap, bliver de vigtigste tests kørt først – det mindsker sandsynligheden for at alvorlige defekter slipper igennem (man tester de mest risikable ting tidligt). Derudover kan AI generere nye testcases ud fra risikomønstre – f.eks. auto-skrive tests for områder med meget brugeraktivitet eller kendte svagheder. Over tid kan sådan et system lære af hvert testforløb og blive mere præcis (f.eks. “sidste version gav fejl i modul A efter en bestemt kodeændringstype, så nu hvor lignende ændring sker i modul B, skruer vi risiko op”).

Svagheder: Data er brændstoffet – ikke alle projekter har nok historik eller metrikker til at træne en meningsfuld AI-model. Hvis inputdata om fejl og ændringer er af dårlig kvalitet (fx mangelfuld bug tagging), kan AI’en give forkerte anbefalinger. Der kan også være modstand mod at stole på en “sort boks” anbefaling – testteams vil have indflydelse og forståelse af hvorfor noget anses risikabelt. Implementering kan kræve integration med mange værktøjer (version control, bugtracker, test management) for at samle data. Endvidere adresserer AI-optimering primært hvad der skal testes hvornår – men ikke nødvendigvis hvordan man designer en helt ny test til en ny feature (her skal testanalytikeren stadig på banen, omend AI begynder at dukke op også for testdesign). Som med al ML (Machine Learning) er der risiko for bias: hvis fortidens tests overså en type fejl, vil AI ikke anse det område som risikabelt (false sense of security). Derfor bør AI-resultater vurderes kritisk af testansvarlige.

Anvendelse: Flere testværktøjsleverandører og DevOps-platforme har indført “AI-driven testing” moduler. Eksempelvis kan Appsurify eller Tricentis qTest med AI analysere code diffs og foreslå impacted tests. Større organisationer med hyppige releases (daglige/ugentlige) har taget det i brug for at spare tid på regression. Også i meget komplekse systemer (som store e-handelssites med tusindvis af tests) er AI blevet brugt til testprioritering og -selektiv kørsel. Testanalytikeren kunne fremover få rollen at trænedisse AI-modeller ved at give feedback (markere falske prioriteringer) og finjustere risikokriterier.

Eksempel: Forestil dig en CI/CD pipeline for en webbank, hvor et fuldt testsuite tager 8 timer at køre – ikke muligt for hver lille ændring. En AI-løsning er trænet på de sidste 2 års commits, modulændringer og defekter fundet. En udvikler laver en commit der ændrer filerne omkring login og transaktionsbekræftelse. AI-modellen analyserer: disse filer er forbundet med højrisikofunktioner (login-sikkerhed, transaktion), og historisk har ændringer i autentificeringsmodulet ofte introduceret fejl. Derfor markerer AI, at risikoen er høj i områder X, Y, Z. Pipeline vælger automatisk et subset på f.eks. 200 testcases relateret til login og transaktioner (ud af 2000 mulige) og kører dem først. Inden for 15 min får teamet feedback: to testcases fejlede – en transaktionsbekræftelse lykkes ikke under visse betingelser. Pipeline stoppes for at fejlen kan rettes, fremfor at man havde kørt måske et halvt døgn af tests hvor denne kritiske fejl først blev opdaget til sidst. Her har AI-optimeringen både sparet tid og sikret hurtigere fejlfindings-loop. Uden AI måtte testmanager manuelt vurdere påvirkningen – i en stor applikation er det svært at være så præcis og hurtig, som maskinen var her.

Automatiseret testdesign og test case generators

Automatiseret testdesign dækker værktøjer og tilgange, der automatisk skaber testcases (inklusive inputdata og forventet resultat) ud fra nogle former for input som krav, modeller eller koden selv. Modelbaseret test (beskrevet ovenfor) er én variant, men der findes også andre typer: f.eks. søgebaseret testgenerering hvor algoritmer (genetiske algoritmer, constraint solvers) forsøger at finde testdata der opfylder visse dækningsmål; eller specifikations-baseret generering hvor formelle krav bruges til at generere tests (fx fra kontrakter). Desuden er der nyere forsøg med at bruge Large Language Models (LLMs) til at autogenerere testcases fra kravtekst eller kode (f.eks. GitHub Copilot der foreslår unit tests).

Relation til ISTQB-teknikker: Mange af de klassiske teknikker kan automatiseres: kombinatorisk test har længe haft værktøjsstøtte (f.eks. Hexawise, Pairwise generators, TestPairs) til at spytte testsæt ud baseret på parameterværdier. Domænetest kan assisteres af værktøjer der beregner grænsepunkter. Beslutningstabeller kan omdannes til kode, der genererer testcases pr. regel. Så test case generators bygger videre på disse teknikker og gør dem mere tilgængelige i stor skala. ATA 4.0 omtaler kort “fordele og risici ved at automatisere testdesign” – hvilket indikerer at testanalytikere skal forstå, at automatisering kan accelerere designfasen, men også har begrænsninger (f.eks. genererede tests kan mangle menneskelig vurdering).

Styrker: Primært, hastighed og omfang – en generator kan skabe tusinder af tests på få sekunder, fx alle par-kombinationer af 10 parametre, hvilket et menneske næppe kunne gøre uden fejl. Det sikrer også konsistens: hvis regler opdateres, kan man regenere hele testsuiten, så alle tests følger den nyeste logik, i stedet for manuel patchwork. Avancerede generatorer kan finde usædvanlige casesvia heuristik – f.eks. en søgebaseret testgenerator kan forsøge at maximere branch-dækning i koden og derved producere inputs der rammer sjældne branches. Dette adresserer det evige testdesign-problem: “har vi tænkt på alt?” – værktøjet tænker måske på ting, vi ikke gjorde. Overordnet sparer det testanalytikerens tid, så man kan fokusere på teststrategi og vurdering af resultater i stedet for rutinearbejde.

Svagheder: En testgenerator er kun så god som dens input. Hvis kravspecifikationen ikke er formel eller komplet, kan du ikke bare trykke på en knap og få testcases – ofte kræver det opsætning af modeller eller parametre (der igen er manuelt arbejde). Genererede tests kan have mange false positives eller upræcise orakler: f.eks. hvis man genererer tests ud fra kode (fuzzing), kan det være svært at vide om et output er rigtigt eller ej uden et testorakel – man kan kun fange crash eller specielle antagelser. Mængden af testcases kan blive enorm; nok kan de genereres hurtigt, men at vedligeholde dem eller analysere fejl fra hundredvis af auto-tests kan belaste teamet. Der er også risiko for overlappende tests – generatorer kan lave lignende testcases, der ikke tilføjer værdi, hvis ikke de er intelligent designet. For mere kreative testtyper (usability, negative test med ulogiske sekvenser) er automatiseret design ikke moden – det er bedst til logisk funktionel test.

Anvendelse: Mange organisationer bruger allerede partial automation: f.eks. bruger de pairwise generation tools til inputkombinationer, eller frameworks som EvoSuite (for unit test generation baseret på kodeanalyse). Der forskes i at integrere test generation i pipelines – fx en commit triggerer generering af nye testdata til at øge dækningen hvis den faldt. I domæner med formelle specifikationer (railway, luftfart) har man brugt værktøjer til at generere testcases fra de formelle krav (model checking teknikker). Selv AI er begyndt at spille ind, hvor LLM’er kan tolke engelske kravbeskrivelser og foreslå testcases i Gherkin-format. Testanalytikerens rolle skifter her mod at validere og vurdere de genererede testcases – filtrere de meningsfulde, tune generatorens input, og sikre at de vigtigste scenarier stadig er dækket.

Eksempel: En webformular har 10 felter med forskellige valideringsregler og afhængigheder. At manuelt skrive testcases for alle kombinationer og hjørner er tungt. Teamet beslutter at bruge et parvis test design værktøj: de opretter parametre for hvert felt med relevante værdimængder (inkl. grænseværdier, gyldig/ugyldig osv.). Værktøjet genererer et sæt på fx 50 testlinjer, hvor hver linje er en unik kombination af værdier, optimeret så alle par af feltværdier er dækket. Disse linjer importeres til test management som testcases, og testerene udfører dem (eller de automatiseres). Under eksekvering finder man en defekt ved en kombination, ingen havde overvejet: Felt A = maksimal længde, Felt F = tom, sammen med Felt J = specifik værdi udløser en fejlmeddelelse der ikke burde komme. Denne kombination var automatisk sammensat af værktøjet som en mulighed – uden det, ville man nok kun have testet felter en ad gangen. Dette viser værdien: generatoren kombinerede faktorer på nye måder som bragte fejlen for dagens lys. Samtidig undgik man at teste hundredvis af trivielle gentagelser, fordi parvis test udvalgte et minimalt men effektivt sæt. Testanalytikeren skulle blot definere parametrene og gennemgå output, i stedet for selv at skrive hver testcase.

Kontinuerlig test og automatisk testdataanalyse

Kontinuerlig test refererer til praksissen at udføre tests løbende i hele softwareudviklingscyklussen – det er en nøglekomponent i DevOps. I stedet for at teste i slutningen af en release integreres testaktiviteter ved hver kodeændring og på tværs af miljøer (unit, integration, system, pre-produktion). Automatisk testdata-analyse er en beslægtet idé, hvor man anvender værktøjer til løbende at analysere resultaterne fra tests (og evt. produktionsdata) for at forbedre testprocessen – fx identifikation af mønstre i hvilke tests der fejler oftest, hvor dækningshuller er, eller analyser af logfiler for potentielle uopdagede problemer.

Sammenhæng med ATA: ATA 4.0 omfatter testprocessen og værktøjsunderstøttelse, men kontinuerlig test er nyere terminologi, ofte knyttet til agile/DevOps. En Advanced Test Analyst med moderne praksis skal forstå at test ikke længere er en fase, men en kontinuerlig aktivitet. Kontinuerlig test understøtter risikobaseret tilgang ved at give hurtig feedback på risici efter hver ændring. Automatisk analyse af testdata kan hjælpe testanalytikere med at prioritere (fx via flaskehalse opdaget i pipeline) og med defect prevention, som ATA også berører (f.eks. trende defektmønstre for at forebygge gentagelser).

Styrker: Den primære fordel ved kontinuerlig test er hurtig feedback: Man opdager defekter tæt på der, hvor de introduceres, hvilket gør dem billigere at fixe og mindre tilbøjelige til at propagere. Det skaber en “sikkerhedsnet” i en hurtig udviklingspipeline – man får hele tiden at vide om en given build er for risikabel at gå videre med. Fra et forretningssynspunkt øger det leverancehastigheden uden at ofre kvalitet, da problemer fanges tidligere. Automatisk testdataanalyse kan f.eks. finde ud af, at visse tests altid fejler ved første kørsel mandag morgen (måske et miljøproblem) – den slags indsigter kunne forblive skjult uden automatiseret log-/resultat-mining. Ved at overvåge testresultater over tid kan AI/analytics også forudsige områder af koden som bliver “hot spots” for fejl, så man kan justere testindsatsen proaktivt. Samlet set understøtter disse teknikker en kvalitetskultur hvor test er integreret og data-drevet forbedring er kontinuerlig.

Svagheder: Kontinuerlig test stiller store krav til automatisering – man skal have et robust set af automatiserede tests (unit, API, UI) for at kunne køre dem hele tiden uden menneskelig indgriben. Ikke alle tests egner sig til at køre kontinuerligt (f.eks. meget lange manuelle tests, eller tests der kræver isoleret miljø). Man risikerer “alert fatigue” hvis pipeline konstant melder om fejl pga. ustabil tests – det kræver vedligeholdelse at holde det grønne barometer troværdigt. Testdata-analyse kræver ligeledes at man samler de rigtige metrics; hvis man ikke logger detaljeret, er der intet at analysere. Der kan også være en læringskurve: udviklere og testere skal måske tilpasse sig at tests kører på hvert commit (f.eks. skrive tests, tænke mere på testbarhed ved design). I nogle tilfælde kan kontinuerlig test-pipelines være dyre at køre (massere af cloud-tid), så man skal optimere hvad der køres hvornår – her kommer testoptimering med risikoprofil (foregående punkt) ofte ind. Endelig, hvis organisationen ikke har en DevOps-kultur, kan indførelsen af kontinuerlig test fejle pga. siloer eller modstand mod forandring.

Anvendelse: Kontinuerlig test er kendetegnende for DevOps top-performers. Brancher som finans og tech, der releaser meget ofte, har adopteret det. F.eks. praktiseres “Shift left” hvor testautomatisering (unit/integration) bygges samtidig med koden, og “Shift right” hvor man i produktion monitorerer brugeroplevelse (A/B tests, real user monitoring). ISO 29119 har også tilpasset sig – f.eks. ISO 29119-2 processerne kan kombineres med agile. Testdata-analyse er set i store projekter hvor test management værktøjer leverer dashboards: defekttendenser, kravdækning i realtid, etc. Nogle bruger også produktionsdata til at drive test (f.eks. telemetri-driven testing, hvor man ser hvilke features brugerne oftest benytter og så prioriterer test deraf).

Eksempel: Et e-commerce firma har sat deres CI/CD op således: Hver gang en udvikler laver en pull request, trigges en kontinuerlig test pipeline. Først kører lyntest: alle unit tests og API-tests (ca. 5 min). Så bygges og deployes automatisk til et testmiljø og der kører et selekteret sæt af UI-selenium tests (ca. 15 min). Resultaterne analyseres automatisk: Hvis X% af tests fejler, markeres build som “failed” og kan ikke merges – udvikleren får med det samme besked hvilke tests der slog fejl. Samtidig har de et dashboard der opsamler alle testkørsler: de bemærker via automatisk dataanalyse, at modul “Checkout” har haft hyppige testfejl de sidste 3 releases. Dykker de ned, ser de at det ofte er rabatkoden der giver issues – en indsigt der kan føde ind i risikoanalysen for næste sprint (måske skal den del refaktoreres eller have endnu mere testfokus). Derudover kører de i produktion syntetiske kontinuerlige tests – fx hvert 5. minut køres et script der laver et dummy-køb, og et overvågningssystem analyserer responstider og sunde svar. Hvis noget afviger (fx betaling går pludselig langsomt), alarmeres teamet om mulig incident. Dette eksempel demonstrerer, at test ikke længere er en engangshandling før go-live, men en uafbrudt proces med automatiseret feedback, og at analyser af testdata bliver brugt aktivt til at forbedre både systemet og test selv.

Standarder og kilder som understøtter ATA 4.0 og videreudvikling

Flere international standarder og akademiske såvel som industrielle kilder giver rammer eller udvider forståelsen af testteknikker i forhold til ISTQB ATA 4.0:

• ISO/IEC/IEEE 29119: Denne serie er den internationale standard for softwaretest. Især del 4: Test Techniques indeholder formelle beskrivelser af testdesignteknikker og tilhørende dækningsgrader. ISTQB's klassifikation af teknikker (databaseret, adfærdsbaseret, regelbaseret osv.) er på linje med ISO 29119-4. Standardens terminologi er også optaget i ISTQB-glossaret, hvilket sikrer en fælles begrebsforståelse. Testanalytikere kan bruge ISO 29119-4 som opslagsværk for definitioner og anvendelsesbetingelser for teknikker. Standardens del 3 (Test Documentation) og del 2 (Test Processes) supplerer ATA ved at give skabeloner for testdesign-specifikationer og integrere teknikkerne i en formel testproces.

• Branche-specifikke standarder (f.eks. ISO 26262 i automotive, DO-178C i luftfart): Disse stiller ofte krav om visse testmetoder for at opnå sikkerhed eller kvalitetsniveauer. For eksempel i ISO 26262 (bilindustrien) afhænger krævet testdækning af ASIL (risk level) – ved høj ASIL skal man typisk anvende systematiske teknikker som partitions- og grænsetest og opnå vis dækningsgrad. Dette fremhæver vigtigheden af at beherske teknikker som EP/BVA og beslutningstabeller i højrisiko domæner. ATA 4.0's fokus på risikobaseret test harmonerer med disse standarders princip om at intensivere testindsatsen efter risiko. For testanalytikere i regulerede miljøer er det således nødvendigt både at kunne dokumentere testdesign iht. standard (fx MIL-standard eller FDA guidance) og at udvælge teknikker, der lever op til branchens krav om fejlafsløring.

• Akademisk forskning: Nye teknikker som metamorfisk test er et resultat af forskning. Artiklen “Metamorphic Testing: Testing the Untestable” (Segura et al., IEEE Software 2020) er et eksempel på akademisk arbejde, som nu er optaget i ISTQB ATA pensum, netop fordi AI-systemer gør oracle-problemet aktuelt. Ligeledes underbygger forskning effektiviteten af kombinationstest – NIST’s empiriske studier, som viste at ~97% af fejl involverer op til 2 parametre, giver et kvantitativt fundament for at pairwise testing er “praktisk talt udtømmende” i mange tilfælde. Testanalytikere kan trække på sådanne kilder for at argumentere for en given teknik i teststrategien (fx “vi vælger pairwise fordi undersøgelser viser det fanger de fleste fejl, hvilket er en god cost-benefit afvejning”).

• Industrielle erfaringer og værktøjer: Mange blogs, whitepapers og case-studies fra industrien belyser de moderne teknikker. Fx Tricentis og CapGemini udgiver årlige “State of Testing” rapporter som ofte nævner adoption af MBT, AI i test, m.m. Der findes også kilder på best practices: f.eks. Forbes/TechBeacon artikler om intelligent testautomation, som citeret før, fremhæver hvordan AI kan fokusere test hvor det giver mest værdi. Disse kilder er værdifulde for testanalytikere, der skal overbevise stakeholders om at investere i nye tiltag (“Eks. Gartner forudsiger at virksomheder der anvender AI-drevet test vil frigive 30% hurtigere end konkurrenter”). At referere til anerkendte kilder giver tyngde til strategivalg og hjælper med at holde sig ajour med hvad der rører sig i test-faget pr. 2025.

• ISTQB videregående syllabus og extensions: Udover Advanced Test Analyst kan testere hente viden i Advanced Technical Test Analyst (for white-box teknikker), Test Automation Engineer (for kontinuerlig test og værktøjer) og Agile Tester. Disse syllabi er også underbygget af litteratur og standarder – fx Adv. Technical TA refererer til code-based coverage og benytter begreber fra ISTQB og IEEE standarder for måling. En holistisk testanalytiker bør kende til disse for at samarbejde med tekniske kolleger; fx kombinere erfaring fra ATA (testdesign) med en Test Automation Engineer’s viden om hvordan man implementerer det i CI.

Afslutningsvis, ISTQB ATA 4.0 giver et solidt katalog af klassiske testteknikker, men verden omkring udvider konstant horisonten. Gode testanalytikere anvender de rette teknikker til rette situation – nogle gange er det en tabel og blyant (klassisk beslutningstabel), andre gange en AI-drevet algoritme, nogle gange en struktureret testcase, andre gange en eksplorativ session. Kombinationen af fundamentale metoder fra standarder og lærebøger med nytænkning og værktøjsbrug inspireret af moderne kilder er vejen til effektiv test i dag. Testanalytikere skal således både mestre de grundlæggende ATA 4.0 teknikker med deres styrker/svagheder og være åbne for at supplere dem med modelbaserede tilgange, intelligente optimeringer og kontinuerlige processer for at levere kvalitet hurtigt og sikkert.