Krav och test är samma sak

Vad är krav? Krav är det område inom systemutvecklingsprocessen som ansvarar för att extrahera användarnas egentliga behov av systemet (jag skriver "egentliga behov" eftersom man som användare inte alltid vet vilket behov man har). Det traditionella tillvägagångssättet för att extrahera krav är att genom intervjuer och workshops fråga användarna, vända och vrida på svaren, omvandla informationen till det kravformat man tillämpar, låta användarna granska kraven, ändra utefter användarnas synpunkter, frysa kraven och sen lämna över dem till designers, programmerare och testare. Genom att göra det här steget noggrant (och därmed långdraget) tror man sig vara försäkrad om att man har hittat de korrekta kraven. Som kravanalytiker känner man sig nöjd och kan börja tugga i sig nästa portion krav (man jobbar väl iterativt!?)

Det är då problemen börjar hopa sig. När designers och programmerare börjar omvandla krav till faktisk exekverande programkod och när testare börjar formulera faktiska testfall så dyker frågor upp. Frågor som kravanalytikern inte tänkt på. Som kravanalytiker har man nämligen inget incitament att kommunicera med 100% logisk exakthet, eftersom man löser sin uppgift ändå. Som programmerare och testare har man däremot allt incitament i världen, eftersom man inte kan lösa sin uppgift utan 100% logisk exakthet.

Fundera på följande formuleringar:

  • Systemet ska uppfattas som snabbt
  • Användaren loggar in i systemet
  • Administratören väljer konto att editera

Det här är exempel på tre inexakta formuleringar hämtade från verkligheten. Vid en första genomläsning (t.ex. vid en granskning) så reflekterar man kanske inte över det här. Men om man ska realisera de här kraven så behöver de säkerligen detaljeras ytterligare.

  • Vad är snabbt i sammanhanget? Finns det tidsangivelser att luta sig mot? Gäller det responstider? Varierar kravet beroende på last? Gäller kravet överallt i systemet?
  • Hur ska användaren logga in? Användarnamn och lösenord? Hur ska användarenamnet se ut? Emailadress? Anställningsnummer? Hur ska lösenordet se ut? Hur många tecken? Måste det finnas siffror i lösenordet? Ska man behöva byta lösenord emellanåt?
  • Kan administratören editera alla konton? Även de som är låsta? Måste de i så fall låsas upp först?

Vad är då lösningen på dilemmat? Ska man lägga ännu mer tid och detaljera kraven ännu mer för att om möjligt täcka upp 100% och därmed förekomma alla tänkbara frågor. Knappast. Det kommer att vara omöjligt att göra i varje system som inte är trivialt. En lösning är att acceptera att det inte går att täcka upp 100% och förändra sitt kravarbete med detta som utgångspunkt.

Syftet med att skriva ner krav är att beskriva det system man avser att utveckla innan man har utvecklat det, ungefär som en arkitekt gör en ritning på ett hus som underlag för byggnationen. Men eftersom vi har sett att det inte går att göra det i detalj och att användarna dessutom ändrar sig hela tiden så behövs ett annat angreppssätt. Testare använder i regel testfall som utgångspunkt för att testa systemet. Syftet med testfall är att beskriva det system man avser att utveckla innan man har utvecklat det. Men vänta nu, är syftet med krav och testfall detsamma? Varför har man då två olika modeller som beskriver exakt samma sak?

Ett mycket bättre och långt effektivare sätt att arbeta med krav och test är att låta dem smälta samman. I stället för att lägga så mycket tid som möjligt på kravformulering, lägg så lite tid som möjligt. Kraven kommer ju ändå att ändras och detaljeras ytterligare. Försök gå vidare så fort som möjligt från ytligt beskrivna krav till att beskriva exakta testfall eller acceptanskriterier, och gör det tillsammans med beställare och programmerare. Genom att tvingas beskriva exakta testfall/acceptanskriterier så kommer mängder av frågor att få omedelbara svar tidigt. Mängden av testfall/acceptanskriterier kommer sen att utgöra kravdokumentationen på systemet. De ytliga kraven kan kastas. Så här skulle man kunna formulera en testdriven "process" i några enkla steg:

  1. Beställaren/användaren formulera enkla och ytliga krav i två tre meningar (t.ex. user stories).
  2. Beställaren/användaren tillsammans med testare och programmerare tar gemensamt fram testfall/acceptanskriterier för respektive krav.
  3. Kraven kastas efter det här steget.
  4. Programmerare användare testfallen/acceptanskriterierna som underlag för utvecklingen av systemet.
  5. Testaren använder testfallen/acceptanskriterierna som underlag för att testa systemet.
  6. Förändringar görs direkt i testfallen/acceptanskriterierna som också kommer utgöra systemets kravdokumentation.

Om författaren
Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.