3 værktøjer til at forstå dine kunder og skabe den gode accepttest

En af de rigtig store udfordringer i softwareudvikling er den allerførste, vi støder på; at forstå hvad vores bruger/kunde har brug for. Uanset udviklingsmodel så er det en af de største udfordringer i forhold til en succesfuld løsning. Alt for mange af de fejl, vi opdager under accepttest og i produktion, kommer af misforståede krav, eller krav vi slet ikke kendte til.

Måske kender du denne tegning? Den illustrerer det så godt:

Tanken med definitionen af værdisættet og principperne omkring det agile manifest (www.agilemanifesto.org)  var netop, at de forskellige grupper skulle komme tættere sammen, at vores største fokus skulle være på at skabe værdi for vores kunder (husk det første princip: ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.) Men vi kæmper med at gøre det i praksis. Har I f.eks styr på jeres user stories og acceptkriterier? Kender teamet til de arbejdsgange og processer, som jeres system skal supportere? Er forretningen en flittig gæst i jeres team/tog/squad?

Misforståede krav giver ubrugelige løsninger

Måske sidder du på kundesiden af et projekt med ekstern leverandør, og skal have styr på, hvad det egentlig er for nogle test-scenarier, I skal lave for at få valideret, at kravene fra jeres brugere er opfyldt, men har kun en laaaang liste af krav i et kravdokument eller regneark? Alt for ofte er det desværre det eneste grundlag, vi har, for at forstå vores brugeres behov, og alt for ofte overser vi noget eller også misforstår vi deres krav. Jeg tror ikke, jeg er den eneste, der har siddet til en accept test og har skullet finde op og ned i de observationer, kundens testere gjorde i forhold til, hvad der var kravsat, og har kunnet konstatere, at brugerne ikke mente, de kunne bruge løsningen i praksis – det ikke var ”fit for purpose” og understøttede deres arbejdsgange og behov.

Kontekst og behov skal være grundlag for test

For mig er det helt fundamentalt at forstå de arbejdsgange, vi skal understøtte. Vi skal bidrage til at få dem identificeret og dokumenteret, og  bruge dem som udgangspunkt, når vi gennemfører en test.. Det sidste er i allerhøjeste grad tilfældet i konteksten af formelle accepttests og afleveringsforretninger, men bestemt også i den løbende test i teamet – det er for sent at opdage at vi ikke er ”fit for purpose” når vi står til vores accepttest lige før vi går i produktion.

Tre konkrete redskaber til til dokumentation af behov, og grundlag for test

 

Flowdiagrammer

Hidtil har jeg brugt klassiske data flowdiagrammer som dokumentation og som udgangspunkt for testteknikken, procescyklustest (PCT). Samtidig kan flowdiagrammer være et godt udgangspunkt, når vi diskuterer selve løsningen af en konkret problemstilling. De hjælper os at afklare de valg, vores brugere har i et givent beslutningspunkt, og hvad output for deres handling bliver.

Business Process Model and Notation (BPMN)

Der er mange måder og metoder at gøre det på, men fælles for dem alle er, at det vigtigste til hver en tid er dialog og fælles forståelse for arbejdsgangene, vi skal understøtte–og hvad det betyder for den løsning, vi skal lave. I forbindelse med min akkreditering som underviser til ISTQB Foundation Acceptance Testing blev jeg introduceret til et par andre metoder, der har tilsvarende formål og giver rigtig god værdi. Den, der bedst kan sammenlignes med ovenstående, er Business Process Model and Notation (BPMN), som også er en del af uddannelsen som forretningsanalytiker. Denne metodik benyttes til grafisk at gengive forretningsprocesser og har et fast regelsæt for notation, der er nem at gå til, og som kan skabe en mere rig illustration end det traditionelle dataflow diagram som vi bruger det til PCT.

Decision Model and Notation

En anden testdesignteknik, der også har en søster ovre hos forretningsanalytikerne, er teknikken beslutningstabeller (Decision tables). I konteksten af forretningsanalyse er der en tilsvarende metode der hedder Decision Model and Notation (DMN). En beslutningstabel er et fantastisk værktøj til brug i både test og kravdefinition. Den hjælper med at formulere krav, når man beskæftiger sig med komplekse forretningsregler. Beslutningstabeller bruges til at modellere kompliceret logik, og gør det nemmere at se de forskellige kombinationer af betingelser, der skal overvejes.

Igen en metode der visualiserer krav og danner et godt fundament for at kunne diskutere behov og løsning. Og som efterfølgende danner grundlag for vores acceptest.

Men hvis du kigger i din værktøjskasse af testdesignteknikker, så vil du opdage, at flere af dem er rigtig gode til det indledende arbejde med at afklare brugerens behov. Det kræver bare lidt kreativ brug af dem. Jeg har også med godt resultat brugt f.eks. klassifikationstræer som illustrationsmetode når jeg diskuterer funktionalitet med en bruger, som en del af at forstå datakombinationer og deres output.

Deltag i Key2Quality kurset om ISTQB Foundation Acceptance Testing

Hvis du er nysgerrig efter at lære mere om, hvordan de to roller forretningsanalytiker og testanalytiker med fordel kan spille sammen, skabe mere værdi som team, og hvordan det påvirker kvaliteten af de accepttests,vi laver, så meld dig til vores kursus ISTQB Foundation Acceptance Testing. Kurset foregår online 24 – 26 marts.