Vem ska man tro på?
Hur vet man vad ett it-system gör? Ett sätt är att läsa kravspecifikationen. Ett annat sätt är att leta i systemkoden.
Kravspecifikationen
- Specificerar vad systemet borde göra
- Är skriven med ett språk som de flesta kan läsa, både personer i verksamheten och utvecklare
Systemkoden
- Talar om vad systemet faktiskt gör
- Är i princip omöjlig att läsa för verksamheten
Problemet med krav
Ett problem är ofta att kravspecifikationen, av olika anledningar, inte uppdateras i takt med att systemet utvecklas. Med tiden kommer därför kravspecifikationen inte längre att stämma överns med vad systemet faktiskt gör. Mycket av det som står stämmer, men det finns inget sätt att avgöra vad man kan lita på.
Så vi kommer till ett läge där den lättlästa kravspecifikationen har divergerat från den faktiska, men svårlästa systemkoden. Och det är koden som är sanningen, för det är den som är installerad.
Det bästa ur två världar
Men, tänk om det fanns ett sätt att plocka de bästa ur de två världarna? Tänk om det gick att både ha kakan och äta den? Tänk om det gick att ha en levande dokumentation, på riktigt?
Det är faktiskt möjligt att uppnå! Genom att jobba med exempelbaserade krav och BDD, så kan man skriva ”körbara” kravspecifikationer som fungerar både som krav och som automatiska testfall.
Dessa exempel är skrivna med verksamhetens termer, på ett sätt som verksamheten förstår. De är tillräckligt konkreta och detaljerade för att användas som specifikation för utvecklarna (vilka dessutom varit delaktiga i att ta fram exemplen, vilket ökar kravförståelsen).
Exemplen är också så pass konkreta att de kan användas som testfall för automatiserade tester. Genom att skriva ”klisterkod”, som läser exemplen och anropar systemets kod, kopplar man ihop specifikationen med systemkoden. Om systemet inte gör det som exemplen specificerar, går det inte att bygga systemet, därför att automatiska tester fallerar. Varje gång en funktion tillkommer eller ändras kommer bygget att misslyckas tills dess koden är uppdaterad till att matcha specifikationen.
(I ett blogginlägg längre fram kommer jag visa på hur sådana här konkreta exempel skulle kunna se ut.)
Levande dokumentation!
När man jobbar på detta sätt, så får man kravspecifikationer som både är läsbara och som stämmer överens med och utvecklas tillsammans med systemkoden. Man får en levande dokumentation!
Sammanfattning
Genom att använda konkreta exempel och BDD uppnår man att kraven och systemkoden alltid speglar varandra.
