“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