BDD

Jeg har arbejdet med BDD i noget tid, og mener at dette koncept kan hjælpe mange virksomheder med at få større udbytte af deres udviklingsaktiviteter både i form af kvalitet og værdi. Begge kan siges at være klicheer, men oftest er det mangel på disse der ender med at koste os penge.

Jeg har skrevet denne Blog som handler om hvad BDD er (og for det meste) ikke er!

At komme i gang

Gode ressourcer til at forstå og komme i gang med BDD som jeg kender:

Kort introduktion

BDD er et koncept der sætter fokus på forretningsværdi gennem brugeradfærd. Det handler i høj grad om samarbejde, og dermed også om kommunikation – de forskellige aktører som beskæftiger sig med enten teknologi eller forretning skal kunne forstå hinanden

skaermbillede-2016-12-29-kl-15-25-31

 

Hvorfor BDD?

Der er mange måder at udvikle software. Fælles for dem alle er at det handler om at understøtte behov hos brugere, organisationer og fællesskaber. Udfordringen ligger i at forstå og omsætte disse behov til noget der fungerer som en løsning, noget som giver værdi i forhold til behovet.

Der er således også mange måder at formalisere krav, lige fra en uformel samtale mellem en der ved noget om behovet og den der kan skabe en løsning, til procestegninger med aktører og deres handlinger og skrevne kravspecifikationer i mere eller mindre struktureret format. Egentlig er der to store spørgsmål til alle former for kravspecifikationer:

  • Laver vi den rigtige løsning?
  • Laver vi løsningen rigtigt?

Der er flere begreber som figurerer i afklaringen af begge spørgsmål, hvor kommunikation og kvalitetssikringen synes af være de vigtigste:

Spørgsmål Begreber
Laver vi den rigtige løsning?
  • Indsigt i behov
  • Kommunikation af behov
  • Fastholdelse og/eller modellering af behov
  • Verifikation af konsistensen (sammenhæng)
  • Verifikation af fuldstændighed (detaljeringsgrad)
  • Hovedformål: lave et produkt som er til gavn som tilsigtet
Laver vi løsningen rigtigt?
  • Produktkvalitet (leveret uden kritiske fejl og mangler)
  • Teknisk (intern) kvalitet af løsningen (nemt at vedligeholde, videreudvikle nemt at sætte sig ind i)
  • Hovedformål: levere et pålideligt produkt af tilsigtet kvalitet som er nemt at vedligeholde og videreudvikle

The BDD-way

Ordet Behavior i akronymet BDD relaterer sig til den adfærd som vi agter at understøtte: hvordan skal brugeren agere for at opnå sine mål på bedste vis, og hvordan kan vores løsning understøtte brugeren. Fokus på adfærd hjælper os med at forstå og beskrive de behov vi vil arbejde med. Beskrivelsen kan vi efterfølgende bruge i kvalitetssikring af løsningen når vi skal tjekke om løsningen opfylder behovet.

Der findes som sagt flere måde at arbejde med krav, og BDD er ikke en universel løsning på begge problematikker. Dog indeholder metoden elementer som er med til at bl.a. forbedre kommunikation og kvalitetssikring: Gherkin sproget. I BDD kommunikerer man interaktionen mellem aktører og systemet ved hjælp af følgende notation:

  • Givet <kontekst>
  • Når <en aktør udfører en handling> 
  • Så <resultatet der ses som en tilstandsændring>

Dette er GWT – Given When Then notation. Eksemplet beskriver formen og strukturen som adfærd-scenarierne har, både når disse udvikles af forretning og automatiseres som tests. Det er ikke selve notationen som er vigtig – struktureret kommunikation faciliterer dialog, og hjælper at undgå misforståelser ved at illustrere forløbet omkring en handling: der var et udgangspunkt (context), brugeren gjorde noget (action) og der kom et resultat ud af det. F.eks for et login scenarie, kunne forløbet se sådan ud:

  • Givet jeg åbner login side på min website
  • Når jeg indtaster korrekte login informationer
  •  er jeg logget ind

Korte og læsbare scenarier som dette er nemme at beskrive og automatisere. Disse bliver også en levende dokumentation for systemets virke.

Strukturen og syntaks i sproget er ikke løsningen i sig selv. Disse er midlerne, som skal få os til at tænke på relevante aspekter i interaktionen mellem aktørerne og systemet: hvad er udgangspunktet før vi handler? Hvad er de forventede resultater og deres sideeffekter? Hvad præcis skal der til for at scenariet lykkedes, og hvordan kan scenariet fejle? Disse spørgsmål kan vi bruge, når vi skal videreudvikle på de krav som indeholder antagelser. Lad os se på følgende eksempel af et krav med antagelser:

Kunderne skal forhindres i at indtaste invalide kreditkortoplynsninger

Vi kan arbejde med at præcisere denne formulereing:

Hvis en kunde indtaster et kreditkort nummer som ikke er præcist 16 karakterer i længden, når kunden forsøger at sende formularen, skal denne vises igen med en fejlbeskrivelsen der forklarer hvad er det forventede kreditkortnummer-format.

Dette er bedre, men vi kan stadig arbejde med læsbarheden!

Feature

Håndtering af ikke valide kreditkort indtastninger for brugere i betalingsflowet.

Brugertesten har påvist at der opstår mange fejl af denne type.

Baggrund gælder for alle scenarier

Givet jeg bestiller et produkt A

Og jeg er ved at indtaste mine oplysninger til betaling

Scenarie − kreditkort nummer er for kort

Når jeg indtaster kreditkort nummeret som er mindre end 16 karakter

Og alle andre oplysninger er korrekte

Og afsender formularen til betaling

bliver betalingsformularen vist igen med de informationer jeg har udfyldt

Og jeg ser en fejlbesked som fortæller mig den korrekte længde på et kreditkort nummer

Når vi opnår bedre struktur og detaljegrad, vil vores scenarier være mere præcise og på den måde komme tættere på de konkrete behov, så vi undgår antagelser og tolkninger.

Reklamer

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

Connecting to %s