Vi laver jo software til mennesker og ikke omvendt

Behavior Driven Development. Et koncept, en tankegang, en filosofi eller blot en metode. Der er sandsynligvis mange fortolkninger af bevægelsen, som opstod i de agile kredse i tidligere 00’erne (ifølge mine kilde, I må gerne rette mig). Så mens Britney Spears, N-Sync og Christina Aguilera toppede hitlisten på MTV, udsprang der en ide om at TDD (Test Driven Development) kunne gøres bedre ved at fokusere på adfærd. Test i sig selv giver mere værdi hvis udgangspunktet for den er kravene til software, og vi kan udtrykke beskrivelsen af test som krav til den adfærd som forventes af systemet og brugeren som benytter det.

Hvordan startede det? Til at begynde med, var det ideen at ens Unit Test navngives som sætninger der starter med ordet should:

void shouldCalculateAccountBalance()

Dernæst kom BDD frameworks som JBehave, Cucumber som gjorde det muligt at beskrive krav som læsbar tekst med bagvedliggende kode, som omsat skrevne ord til automatiserede handlinger der testede kravene:

Given I log on to the system as System User

When I open account management

Then I see a list of active accounts sorted by modification date, newest first

Vi kom tættere på samarbejdet mellem dem som beskriver behov og dem som realiserer disse ved at udvikle software. Historisk set har der været en opdeling i “forretning” og “IT afdeling” de steder som beskæftiger sig med softwareudvikling. Problemer i kommunikation imellem disse får tit skylden for fejlede IT projekter, men sådan skulle det jo ikke blive ved med at gå.

For det handler jo som sådan ikke om automatisering, når vi snakker BDD. Det handler om at forstå hvilke behov software brugere har under de givne betingelser, og hvordan vi kan understøtte disse ved at lave software som hjælper dem i at opnå deres mål. Det er altså ikke et sæt af features der i sig selv er vigtig. Det er om brugeren kommer i mål – ved at bruge vores software!

Dermed bør vi først og fremmest starte med historien bag scenarierne, vores user story (den famøse WHY)

6808f5b0-594d-0132-0b73-0eae5eefacd9

User Story Example:

In order to provide world class support to our users

As a system administrator

I need to be able to manage account list effectively

Lige præcis denne del af BDD er måske den sværeste del af BDD – langt ud over udfordringer som ustabil browser automatisering, test coverage etc. Definere, hvad prøver vi at opnå og hvorfor? Hvilket formål har aktøren, og hvordan kan dette understøttes med det software vi vil lave?

En masse automatisering uden et klart-defineret formål er som et skib uden en styrmand. For hvis ikke vi hjælper brugeren med at løse opgaven på den bedste måde vi kan, så kan det da være lige meget om testen er automatiseret!

Der er skrevet rigtigt meget om hvad BDD er. Måske kunne det også være relevant at sige noget om det hvad det ikke er:

  • IKKE et projekt der går ud på at automatisere de krav som forretning har stillet. BDD handler først og fremmest om at definere krav sammen med sin forretning og udvikle med udgangspunkt i disse.
  • IKKE en proces som udføres af en enkel person! BDD indebærer samarbejde omkring krav på tværs af roller; f.eks når treenigheden, i form af forretnings-, udviklings- og QA perspektiv, mødes for at beskrive og udvælge nøgle-eksempler på brug af den feature vi har tænkt os at lave. De eksempler hjælper os med at forstå hensigten, og viser hvad de 3 musketerer er enige om 🙂three-musketeers
  • IKKE: En metode til at udvikle software. BDD er en tankegang, der hjælper os med at fokusere på de behov og udfordringer som vores brugere har. Vi kan stadig køre Scrum-sprints eller have en Kanban-tavle. Vi kan stadig skrive test før vi udvikler applikationskode eller udøve pair-programming.
  • IKKE: Noget smart udviklere har fundet på for at få lov at bruge mere tid på teknologi. BDD handler også om overblik og kvalitetssikring; når tests automatiseres løbende giver dette os levende dokumentation af det som allerede er udviklet, indsigt i hvor langt er vi henne i processen med udvikling på de stories som er i vores scope. Dokumentationen giver testere mindre regressions-byrde og mere tid til udforskende test med udgangspunkt i de beskrevne scenarier.

Når det er sagt, så handler det jo først og fremmest om brug af eksempler til at opnå fælles forståelse af det vi ønsker at lave. Det handler om samarbejde.

Historien, og Monty Python har bevist at kommunikationen kan være svær:

/Poul

Reklamer