Swedish article about using test missions as requirements to solve some of the problems we face today.

1. Test missions som krav
Kravhantering har genomgått stora förändringar under det senaste decenniet.
Sökandet efter den perfekta kravspecifikationen tidigt i projektet har
avstannat, och fokus har istället övergått till ett mer dynamiskt, föränderligt
arbetssätt med krav som tillräckligt väl beskriver kunders behov på ett sätt
som både kunden och utvecklaren kan förstå. Behovet av att kraven är
prioriterade och hålls uppdaterade finns dock fortfarande.
Problematiken med stora mängder detaljkrav, eller agila användarscenarion
som krav, är att det inte finns något värde i själva kravartefakten.
Informationen som artefakten innehåller är värdefull, men själva artefakten
används bara till att förmedla denna information och inget annat. Risken är
då stor att ingen orkar uppdatera artefakten när informationen i den ändras.
Eftersom ingen använder den så finns det ingen som egentligen känner
ägandeskap för den eller har något behov av att uppdatera den. Och sen står
man där när man plötsligt behöver förstå om kraven är möta eller om man
har samma förståelse för kraven, utan någon dokumenterad kravbild.
Problemet med att använda testfall eller komponenttester som krav är
annorlunda. Här finns det ett incitament att hålla dem uppdaterade eftersom
de hela tiden används. Kravartefakten är någonting som samtidigt används
under projektets gång för att utföra tester. Men när kunden tittar på dessa
testfall eller komponenttester så är det väldigt svårt att förstå om dessa
tester motsvarar kundens förväntningar och behov. Konsekvensen av detta är
att det är omöjligt att utifrån kravbilden veta om det som implementeras är
det som kunden verkligen vill ha. BDD och t.ex. given-when-then ramverket
gör komponenttester enklare att förstå, men är fortfarande för detaljerade
för att kunna använda i en diskussion med kunden om denne inte har en
relativt god teknisk detaljkunskap.
Så vad är lösningen till detta problem? Min tanke är att använda James Bachs
exploratory charters eller heuristics, James Whittakers testing tours, eller
helt enkelt användarscenarion som skrivits om till tester, som krav. Jag
sammanfattar alla dessa under begreppet ”test missions”. Tanken är alltså att
kravartefakten aktivt måste användas i projektet – därav testfall som krav.
Men samtidigt måste den vara sådan att den enkelt kan uttrycka kundens
behov på ett sätt som både kunden, utvecklaren och testaren förstår.
Förmodligen behövs det en kombination av användarscenariotester och
heuristics/charters/tours för att beskriva hela kravbilden.

2. Men ett av de stora problemen med krav måste fortfarande lösas – kunden
och utvecklaren/testaren måste kommunicera kontinuerligt genom hela
utvecklingscykeln.
Man kan bara hoppas att genom att ha kravartefakter som alla förstår, och
som används kontinuerligt under projektet, så gör det att tröskeln för att
börja kommunicera blir lägre, och intresset för att upprätthålla
kommunikationen blir större.
När felrapporter sen rapporteras mot de olika kravartefakterna så blir dessa
en del av artefakten. Detaljeringar av det övergripande kravet. Oavsett om
felrapporterna är korrekta eller felaktiga så beskriver de nu detaljer av
kravet. Men om många av felrapporterna som läggs förkastas av kunden så
bör man ifrågasätta om det övergripande kravet verkligen är rätt. Man bör
kanske revidera kravartefakten – skriva om charter/tour/heuristic.
Tyvärr så ställer detta arbetssätt högre krav på utvecklings- och
testorganisationen. Man måste sluta förlita sig helt på testfallsbaserad
testning och börja anamma mer utforskande testning. Test måste vara
delaktiga tidigt i utvecklingsprocessen. Testkompetensen hos både testare
och utvecklare måste vara större.
Det kräver ett nytt synsätt på både krav och test för många organisationer.
Detta var min övergripande tanke kring hur jag hade velat angripa
kravproblematiken. Förhoppningsvis gav det även dig några nya idéer.
/Johan Hoberg