“I pity the fool who doesn’t put quality dead center”

Sådan kunne Mr. T have sagt, hvis han havde været DevOps-ekspert i stedet for 80’er actionhelt. Men så ville verden have været foruden B. A. Baracus og A-teamet, og det ville også have været en skam.

Nuvel, vi må hellere dykke ned i det, som det egentlig drejer sig om. Risikobaseret teststrategi i CI/CD.

Og hvad er risikoen, spørger du nok? Ja, det må vi finde ud af i fællesskab.

Hvad er kvalitetsrisiko?

Lad os starte med det grundlæggende.

Kvalitetsrisiko er en specifik chance for, at produktet fejler, kombineret med konsekvensen hvis det sker. To faktorer bestemmer chancen for fejl: Sandsynligheden for at fejlen overhovedet findes i produktet, og hvor tit den pågældende del af produktet bliver brugt. Konsekvensen handler om, hvad der sker i den virkelige verden når det går galt. For brugerne og måske for virksomhedens omdømme.

Forestil dig engang, at et finansielt system er bygget med en microservices-arkitektur. En bruger går i gang med en valutakonvertering i realtid. Undervejs crasher systemet, fordi der ikke er styr på afhængighederne mellem de services der kræves for at gennemføre konverteringen. Det er systemkompleksitet der påvirker chancen for fejl og en utilfreds bruger der ikke kan gennemføre sin transaktion, der illustrerer konsekvensen.

En betalingsbekræftelse som alle kunder bruger flere gange dagligt bærer en fundamental anden risiko end et administrativt skærmbillede med en kosmetisk fejl. Din testindsats bør afspejle den forskel. Det er lige præcis det risikobaseret test handler om.

Og det er ikke kun et spørgsmål om prioritering. Det handler om overlevelse. I DevOps er det teamet selv der mærker konsekvensen, når noget går galt i produktion. “You build it, you run it” er ikke bare et catchy motto, men en direkte incitamentstruktur der tvinger kvalitet ind i centrum af arbejdet. Når du er den person der bliver vækket klokken tre om natten fordi din kode fejler i produktion, tænker du anderledes over risiko næste gang du planlægger et sprint.

Og lige inden du tænker “funktionalitet, det har vi da styr på”, så stop lige et sekund. En user story handler typisk om hvad en feature skal gøre, men de relevante kvalitetskarakteristikker rækker langt videre end det. Sikkerhed, performance, vedligehold, brugervenlighed, pålidelighed. En betalingsfeature kan bære høj funktionel risiko og en ligeså høj sikkerhedsrisiko på samme tid. Et rapporteringsdashboard kan have lav sikkerhedsrisiko men til gengæld høj risiko i brugervenligheden. At identificere hvilke kvalitetskarakteristikker der rent faktisk er relevante for hvert item, er en forudsætning for at bygge en teststrategi der er noget værd.

Hele teamet med: Risk poker

Lad os tale om den mest oversete faldgrube i risikovurdering: At kun én person laver den.

En udvikler ser teknisk kompleksitet. En product owner ser forretningsmæssig konsekvens. En tester ser historiske fejlmønstre. En risikoanalyse der kun fanger ét af disse perspektiver er ufuldstændig og en ufuldstændig risikoanalyse giver en ufuldstændig teststrategi. Så lad os gøre det ordentligt.

Risk poker er svaret. Det er en udvidelse af planning poker som de fleste Scrum- og DevOps-teams allerede kender og bruger. Og ligesom planning poker afslører forskelle i, hvordan teammedlemmer forstår størrelsen af en user story, afslører risk poker forskelle i, hvordan de forstår dens risiko. De forskelle er ikke noget man skal komme hurtigt videre fra. De er faktisk den mest værdifulde del af hele sessionen.

Sådan fungerer det i praksis. For hver user story i det kommende sprint estimerer hvert teammedlem selvstændigt to ting: Chancen for fejl og konsekvensen af fejl. Det gøres med kort med værdierne 1 (lav), 2 (mellem) og 3 (høj). Kortene vendes samtidigt og så begynder den rigtige samtale. Når estimaterne afviger, diskuterer teamet årsagerne bag de afvigende værdier, indtil der er opnået konsensus. Resultatet er en item risk score: Chance ganget med konsekvens.

I praksis oversætter mange teams scoren til en risikoklasse. Score 9 bliver Risikoklasse A, score 4 eller 6 bliver Risikoklasse B, og score 1, 2 eller 3 bliver Risikoklasse C. Det holder samtalen fokuseret på relativ prioritet frem for falsk numerisk præcision. For ingen risikovurdering er mere præcis end de antagelser den bygger på.

En vigtig detalje som mange teams overser: Product owner deltager i risk poker, modsat planning poker. Product owner repræsenterer interessenterne og bidrager med det forretningsmæssige perspektiv som udviklere og testere kan undervurdere, særligt når det handler om at kalibrere konsekvensen af en fejl korrekt. Scrum Masteren faciliterer men spiller ikke selv.

Resultatet? En risikotabel. Et struktureret overblik over alle user stories i sprintet med en risikoklasse for hver relevant kvalitetskarakteristik.

Fra risikoklasse til testintensitet

Okay, vi har vores risikotabel. Hvad nu?

Nu bestemmer teamet hvor intensivt hver kombination af story og kvalitetskarakteristik skal testes. Testintensitet udtrykkes i tre niveauer: ••• (høj), •• (mellem) og • (lav).

Reglen er enkel. Risikoklasse A kræver mindst ét ••• . Risikoklasse B kræver mindst •• . Risikoklasse C får aldrig mere end • . Det er tilladt at gå ned i intensitet, men kun med en dokumenteret begrundelse som alle kan se.

Denne struktur forhindrer to klassiske fejl. Den første: At behandle alle stories ens uanset risiko. Den anden: At beslutte uformelt at teste noget “lidt mere” uden at gøre den beslutning synlig. I en CI/CD-pipeline der kører kontinuerligt, er usynlige beslutninger om testintensitet en direkte kilde til uforudsigelig kvalitet.

Kvalitetstiltag: Fra intensitet til konkret handling

Testintensitet fortæller hvor meget. Kvalitetstiltag fortæller hvordan.

For hver kombination af story, kvalitetskarakteristik og testintensitet vælger teamet de konkrete kvalitetstiltag de vil anvende. Og her er det vigtigt at forstå, at kvalitetstiltag ikke er begrænset til dynamisk test. Tværtimod. Det fulde spektrum inkluderer tre kategorier:

Forebyggende tiltag der bygger kvalitet ind fra starten

• Pair programming
• Test-Driven Development
• Behavior Driven Development
• Specification by example

Disse hører hjemme tidligt i leverancecyklussen, i Plan- og Code-stadierne af pipelinen.

Afslørende tiltag der demonstrerer kvalitetsniveauet

• Funktionel test
• Performancetest
• Sikkerhedstest
• Statisk analyse
• Eksplorativ test

Disse fordeles over pipeline-stadierne afhængigt af hvad der skal verificeres og hvornår.

Korrigerende tiltag der proaktivt forbedrer kvaliteten

• Refaktorering
• Feature toggles

Disse hører hjemme i Integrate-stadiet og i teamets løbende refleksion.

Og så er der en forbindelse som mange teams overser, nemlig risiciene og måden at dække dem på er direkte forbundet med acceptkriterierne på story-kortet. En velbeskrevet Confirmation indeholder ikke kun de glade scenarier. Den inkluderer fejlsituationer, edge cases og hints om hvilke testmetoder der er relevante. Det er den forbindelse der gør teststrategien konkret og handlingsorienteret frem for et dokument ingen læser.

Fra teststrategi til quality engineering strategi

En traditionel teststrategi fokuserer primært på de afslørende kvalitetstiltag. Altså det vi normalt forstår ved “test”. Men i DevOps er kvalitet et teamansvar fordelt over hele leverancecyklussen, og så er en traditionel teststrategi ikke nok.

Det fører os til begrebet quality engineering strategi: En udvidelse af teststrategien der giver lige vægt til forebyggende, afslørende og korrigerende tiltag, og eksplicit placerer hvert tiltag der, hvor det hører hjemme i leveranceprocessen.

Lad os tage et konkret eksempel. Et team bygger en ny funktion i deres app der viser brugere deres præcise ventetid i en kø. Teamet klassificerer dette som høj risiko (risikoklasse A). Hvis ventetiden vises forkert, bliver brugerne frustrerede og tilliden til appen falder. Som forebyggende tiltag vælger teamet pair programming under Code-stadiet. Som afslørende tiltag anvender de funktionel test og performancetest med fokus på svartid. Som korrigerende tiltag planlægger de refaktorering under Integrate-stadiet.

Det er ikke bare en testplan. Det er en bevidst, risikobaseret fordeling af kvalitetsaktiviteter over hele sprintcyklussen med hvert tiltag begrundet i den risiko det adresserer.

I en CI/CD-kontekst får dette en direkte operationel betydning. Teams der bruger Jira eller Azure DevOps kan registrere risikoklassen og de aftalte kvalitetstiltag direkte på hver user story. Pipeline-konfigurationen kan herefter referere til disse oplysninger og anvende de relevante testsæt på hvert stadie. Stories med høj risiko kræver den højeste testintensitet på tværs af pipeline-stadierne. Stories med lav risiko kører et målrettet subset. Quality gates, de definerede kriterier som en build skal opfylde inden den avancerer til næste pipeline-stadie, omsætter strategien til konkret pipeline-håndhævelse.

Strategien er levende, ikke et dokument der samler støv

Her kommer den del som mange glemmer.

En quality engineering strategi skabes ikke én gang og lægges i en skuffe. User stories ændrer sig. Nye stories tilføjes. Risikoopfattelsen skifter efterhånden som teamet lærer mere om produktet og dets brugere. Og når en hændelse opstår i produktion, giver den reel evidens for at risikovurderingen af det berørte komponent var sat for lavt.

Kapable DevOps-teams stiller spørgsmålet “skal vi opdatere vores quality engineering strategi?” ved hvert daily standup og i hvert retrospektiv. For teamet er strategien primært en to-do-liste: En klar og fælles aftale om hvilke kvalitetsaktiviteter der skal udføres, med hvilken intensitet og på hvilket tidspunkt i leverancen.

Når den liste er synlig, vedligeholdt og ejet af hele teamet, holder kvalitet op med at være en kontrolaktivitet forbeholdt testere til sidst i processen og bliver en del af måden teamet arbejder på. Hver dag. I hvert sprint.

Og det er egentlig det, som det hele drejer sig om.

Bliv bedre til at omsætte teststrategi til praksis
Risikobaseret teststrategi i CI/CD kræver fælles sprog, tydelige prioriteringer og konkrete kvalitetstiltag i teamet. På vores testkurser arbejder du praktisk med teorien, får eksempler fra virkelige IT-projekter og sparring fra undervisere med solid erfaring fra praksis. Se vores kommende kurser i ISTQB, TMAP og test — eller kontakt os om et skræddersyet forløb til jeres team

Her kommer der lige en lille disclaimer: Denne artikel er ikke nedfældet af en kunstig intelligens, men derimod et helt almindeligt menneske.

Ret vildt, synes du ikke?

Det der for ganske få år siden ville have været en selvfølge, bliver i dag gradvist en sjældenhed i forhold til AI-generet indhold.

Med nogle få instruktioner kunne jeg nemt have fået en AI til at generere enten et udkast eller en hel artikel om dette emne, alt afhængigt af hvilken grad af autonomi jeg ville tildele den.

For det går hurtigt med AI, meget hurtigt.

Særligt inden for softwareudvikling, hvor millionvis af AI-genererede linjer kode bliver spyttet ud dagligt på tværs af vores lille blå planet.

Og når udviklingshastigheden stiger, ja så må hastigheden på at kvalitetssikre dets output følge med.

Så lad os tage et kig på, hvad GenAI egentlig er og hvordan det passer ind i en test og QA-kontekst.

Hvis du allerede nu føler, at det der GenAI har du bare helt styr på, så kan du passende springe ned til overskriften: ‘Hvordan kan GenAI bruges i test kontekst?’.

Her vil jeg komme med eksempler på, hvordan GenAI kan anvendes i test og QA-opgaver.

Hvad er GenAI?

Lad os prøve at visualisere, hvad AI egentlig er.
Forestil dig, at langt ude i skoven lå et bjerg kaldet AI.

På det bjerg stod der så et lille træ, som vi vælger at kalde Generative AI eller blot GenAI.

Træets rødder kaldes neural networks. Rødderne løber op i stammen, language models (LM). På stammen sidder der en gren, pre-trained language models (PLM). På grenen er der tre kviste, en lille kvist, small language models (SLM), en mellem kvist, large language models (LLM) og en stor kvist, multimodal LLM. Og på den store multimodal LLM-kvist sidder der nogle blade, vision-language modeller.

Forvirrende? Lad os dykke ned i, hvad de forskellige elementer så egentlig betyder.

Neural networks

Neural networks eller på dansk kaldet neurale netværk, udgør selve fundamentet for den moderne kunstige intelligens, som vi kender til i dag. De neurale netværk fungerer ved at efterligne vores menneskelige hjerner ved at behandle information gennem bittesmå beregningsenheder, som vi ofte kalder neuroner. Neurale modeller, altså matematiske modeller opbygget gennem neurale netværk, har været igennem en massiv udvikling gennem flere generationer. Fra de tidlige neurale modeller som Recurrent Neural Networks (RNN), der behandler data sekventielt, til de nuværende modeller bygget på Transformer-arkitekturen, som behandler data parallelt.

Det gennemgående for de neurale modeller er deres evne til at processere konteksten af store tekstmængder. Men det er netop her, at Transformer-arkitekturen skiller sig ud fra de tidlige neurale modeller. Hvor RNN-baserede modeller læser tekst som vi læser en bog, ord for ord og fra venstre mod højre, så kan Transformer-baserede modeller læse hele sætningen på én gang og vurdere, hvilke ord der er vigtige ift. hinanden. Det er en uhyre egenskab, som vi kalder self-attention mekanismen.

Forestil dig lige en gang, at du er i gang med at læse en fejlrapport. I rapporten står der sætningen: “Log ind knappen virker ikke, når brugeren trykker på den”. En RNN-baseret model ville behandle hvert ord i rækkefølge, og dermed risikere at “glemme” den indledende del, inden den havde læst sætningen til ende. En transformer-baseret model forstår derimod med det samme at “knappen” og “trykker” hænger sammen, idet self-attention mekanismen beregner relationerne mellem alle ord i sætningen parallelt.

De to grundsten: Tokens og Embeddings

For at en GenAI kan forstå dine prompts, skal den først nedbryde teksten. Det sker gennem to koncepter, der er fundamentet for det hele:

• Tokenization: Her bliver dine prompts nedbrudt i mindre enheder, også kaldet tokens. Tokens kan være enkle tegn eller et helt ord.
• Embeddings: Hold fast, for nu bliver det lidt teknisk. De nedbrudte tokens bliver derefter oversat til tal i et kæmpe koordinatsystem. Tokens med lignende betydninger og anvendelse, placeres tæt på hinanden. På den måde “forstår” modellen de semantiske sammenhænge mellem de nedbrudte tokens.

Language models (LM) & pre-trained language models (PLM)

De neurale netværks rødder løber op i stammen, language models (LM). En language model er kort fortalt en model, der er trænet i at forstå og forudsige sprog ved at lære mønstre fra tekst. Som det tidligere er beskrevet i de to grundsten: tokens og embeddings, så er det her modellens forståelse opstår. Teksten nedbrydes, den oversættes til et tal og gennem talrepræsentationen lærer modellen at genkende mønstre og forudsige sprog.

Fra stammen vokser der sig en gren, pre-trained language models (PLM). En PLM er en videreudvikling af LM der, fremfor at være blevet trænet på en specifik opgave, først bliver trænet på massive mængder tekst – her taler vi alt fra klassiske romaner og videnskabelige artikler til madopskrifter. Denne proces kalder vi pre-training, som giver modellen en generel sprogforståelse, inden den bliver taget i brug med specifikke opgaver.

SLM & LLM: Sprogmodellerne der har læst (næsten) alt

Åh ja, så kom vi til de to mindste kviste; small language models (SLM) og large language models (LLM).

Den mindste kvist, Small Language Models (SLM), er kompakte modeller. Det vil sige, at modellerne har færre end 10 milliarder parametre, hvor parametre skal forstås som de talværdier, der udgør den specifikke og veldefinerede viden som modellen har opbygget under sin pre-training. Modellens specifikke viden og kompakte størrelse gør altså at den er væsentligt lettere at køre og i modsætning til bladet ved siden af, så kan den faktisk afvikles til veldefinerede opgaver lokalt på din computer eller smartphone – det er da ret sejt.

Den mellemste kvist, large language models (LLM), har du formentlig hørt om allerede. Det er dem vi i det daglige kender fra Claude, Gemini, Mistral og ChatGPT. Hvor SLM’er er nogle små kompakte specialister, er LLM’er derimod nogle store og brede generalister. Under dens pre-training har den fået en massiv mængde viden om alskens slags, og med netop den viden kan modellen forstå, når vi mennesker kommer med input til den gennem prompts.

Fra fundament til de helt svære opgaver

De brede generalist LLM’er kan derimod også blive videreudviklet. Udviklingen af en LLM minder lidt om en konsulents avancement i konsulenthuset. Den starter som en Foundation LLM, der er en generalist, som ved lidt om alting (juniorniveau). Derefter bliver den Instruction-tuned, altså trænet specifikt i at forstå og følge menneskelige instruktioner (mellemniveau). Og til sidst har vi Reasoning LLMs, som udbygger instruction-tuned modeller gennem kognitive evner som syllogisme, multi-trin problemløsning, og det vi kalder chain-of-thought reasoning.

For at holde dem på rette spor bruger man Reinforcement Learning from Human Feedback (RLHF). Her er det altså rigtige mennesker, der giver feedback til modellen for at sikre, at den opfører sig ordentligt og svarer sikkert.

Multimodal LLM’er og Vision-Language Modeller

Nå, men fra den fine pre-trained language models (PLM) gren sidder der også en stor kvist, Multimodale LLM. Den multimodale LLM udvider LLM’ernes evne til at behandle andre typer data end tekst, herunder billeder, video og lyd. Dette grundet deres træning på store og forskelligartede datasæt. For at modellen kan håndtere de forskelligartede modaliteter, bliver den iboende tokenization tilpasset de forskellige datatyper. Dette ses bl.a. ved konverteringen af billedtokens til embeddings, som vi tidligere har set med tekst.

På den store kvist sidder der flere blade, Vision-language-modeller, der specifikt integrerer visuel og tekstuel information for at udføre opgaver såsom billedtekstning (image captioning), visuel spørgsmålsbesvarelse (visual question answering) og analyse af overensstemmelsen mellem tekstuelt og visuelt input.

Og når vi så taler om GenAI i forbindelse med test og QA, så giver multimodale LLM’er, og særligt LLM’er suppleret med vision-language-modeller, betydelige muligheder. Eksempelvis ved at analysere visuelle elementer i applikationer, såsom screenshots og GUI-wireframes, sammen med tilhørende tekstbeskrivelser, herunder fejlrapporter eller user stories. Denne egenskab gør det muligt for testere at identificere uoverensstemmelser mellem forventede resultater og de faktiske visuelle elementer.

Hvordan kan GenAI bruges i test kontekst?

At bringe GenAI ind i softwaretest er ikke bare en lille opgradering – det er et regulært paradigmeskift. Vi bevæger os væk fra de tunge, regelbaserede metoder og over mod en mere intelligent og adaptiv automatisering, der dækker hele vejen fra de første krav til den endelige rapport.

Her er de fem områder, hvor GenAI for alvor kan gøre en forskel lige nu:

1. Analyse af krav og testdesign: AI som din “sparringspartner”

Vi kender det alle sammen: Kravspecifikationer, der er mere mudrede end en dansk efterårsdag. Her er LLM’er geniale:

• Oprydning i kravene: Smid dine dokumenter ind i en LLM’ers chat interface, og den vil lynhurtigt spotte eventuelle uklarheder eller manglende info. Modellen kan muligvis give dig de helt rigtige spørgsmål til dine stakeholders, som du måske først ville have opdaget halvvejs i testfasen.
• Automatisk generering af testcases: AI’en kan hurtigt læse dine BDD-user stories og derefter generere testcases, mål og forventede resultater på ingen tid.
• De skæve scenarier: AI’en er god til at finde de der “edge cases”, som vi mennesker overser, når vi har hovedet fuldt af de mest gængse brugerrejser.

2. Implementering og data: Slut med at vente på testdata

Det er her, vi for alvor mærker hastigheden:

• Syntetisk testdata: Har du også prøvet at kæmpe med GDPR-regler og anonymisering af kundedata? AI kan generere realistiske, men 100% kunstige datasæt, der ligner den ægte vare på en prik, uden at du kommer i klemme med lovgivningen.

3. Vedligeholdelse der klarer sig selv (næsten)

En af de største frustrationer i testautomatisering er skrøbelige scripts, der fejler ved selv de mindste UI ændringer.

• Self-healing: Moderne AI-frameworks kan selv opdatere dine scripts, når UI’en eller API’et ændrer sig.
• Intelligent prioritering: Ved at kigge på historiske data kan AI’en fortælle dig, hvilke testcases der er vigtigst at køre lige nu, baseret på hvor risikoen for fejl er størst.

4. Analyse af resultater: Hvad gik der egentlig galt?

Når testen fejler, starter detektivarbejdet. Men AI’en har allerede læst logfilerne for dig:

• Forklaring af fejl: I stedet for at kigge på en kryptisk sensor-log eller 500 linjer fejlmeddelelser, kan AI’en give dig en sammenhængende forklaring på, hvorfor det gik galt, og hvad du skal gøre for at fikse det.
• Automatisk dokumentation: Den kan endda skrive dine defekter og rapporter færdige, så de er klar til audit uden det store manuelle benarbejde.

5. Husk nu mennesket i maskinrummet

Selvom alt det her lyder som den rene QA-lykke, så kræver det en hybridmodel. Vi kan ikke bare læne os tilbage og lade AI’en styre showet alene:

• Tjek resultatet: Selvom GenAI og LLM’er er smarte, så kan modellerne ligesom du og jeg stadig lave fejl. De kan skrive testlogik, der ser rigtig ud, men som ikke stemmer overens med testobjektet. Derfor skal du altid have en ekspert (dig!) med i loopet.
• Styr på standarderne: Vi skal sikre os, at det AI’en genererer til os, rent faktisk lever op til vores kvalitetskrav og den gældende lovgivning.

Puha, det blev en lang omgang. Hvis du stadig læser med, så kommer der lige en kort opsummering:

• GenAI bygger på neurale netværk og transformer-arkitekturen, som gør modellerne i stand til at forstå tekst parallelt og dermed relationen mellem ord
• Sprogmodeller forstår tekst gennem tokens og embeddings – altså nedbrydning i enheder og nummerering.
• Pre-training giver sprogmodeller baggrundsviden – både til SLM specialisterne og LLM generalisterne
• Multimodale LLM’er kan kombinere tekst og billeder, eksempelvis screenshots af GUI-baserede fejl og user story.
• GenAI kan hjælpe med meget af det manuelle arbejde i test og QA, fra kravanalyse og testdesign til fejlforklaring, men det er stadig vigtigt med et human-in-the-loop.

Og som jeg skrev i det indledende, så går det meget hurtigt med AI. Men hvis vi lige vender den formulering på hovedet engang. Mens alle andre bekymrer sig om, hvorvidt GenAI kommer til at erstatte dem på arbejdspladsen, så sidder du nu med en bedre forståelse af, hvad det hele egentlig drejer sig om. Du ved hvad et neuralt netværk er, du ved hvorfor transformer-baserede modeller er klogere end RNN-baserede modeller, og du ved hvordan GenAI kan blive din nye buddy i testarbejdet. Det gør dig bestemt ikke overflødig, det gør dig snarere farlig. Altså på den gode måde. Så ja, det går hurtigt. Men det bliver også sjovere at være tester.