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ötta 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.

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.