Testdriven kravhantering

Under mina 25-30 år inom IT har stora förbättringar skett inom många områden. Jag har sett hur teknik, metoder och arbetssätt har utvecklats och hur fokus har förflyttats från programmering till metoder, vidare till teknik, sen till test, för att just nu vändas mot krav.

Det gamla talesättet säger att man kan prata om ett halvfullt eller ett halvtomt glas. Utifrån det halvtomma perspektivet kan man fråga sig om det med en vag och svag kravbild är genomförbart att planera test. Går det överhuvudtaget att testa under sådana förutsättningar?

Med ett halvfullt perspektiv ställer man istället frågorna:

• vad är möjligt att göra?
• hur utföra det som är möjligt att göra?

Vi testare befinner oss ofta i situationer där en lösning snabbt ska tas fram och produktionssättas, och självklart testas för att säkerställa kvaliteten. Ofta saknas i dessa sammanhang krav eller så är de i alla fall inte kompletta.

Det finns ett uttryck som säger att ingenting är omöjligt, men att vissa saker bara tar lite längre tid. Jag skulle vilja tillägga ”eller kräver mer av den som ska genomföra det”.

En grundläggande frågeställning är om det går att kartlägga de bakomliggande orsakerna till varför projektet startade. Vilka är effektmålen? När förväntas de vara infriade? Om ett eller om fem år? Och var kommer projektet in, vilken del av effektmålen förväntas att projektet ska lösa?

Tyvärr är det vanligt att projektets mål är att leverera mjukvara, inte en lösning. Dessutom följs projektet ofta upp enbart på tid och kostnad, inte på om de förväntade effektmålen nåddes eller inte…
För om du tänker efter, i hur många projekt har du själv haft kännedom om effektmålen? Och hur många projekt känner du till där beställaren följt upp effektmålen eller där det finns en plan som visar när, var, hur och av vem effektmålen ska mätas?

Oavsett om man genomfört en kartläggning av de bakomliggande orsakerna till projektet eller inte är nästa viktiga frågeställning tidpunkten för start av testarbetet. Vi vet alla att desto tidigare ett fel upptäcks, desto billigare blir det att korrigera det. Självklart ska vi då påbörja testplanering och framtagande av testfall så tidigt i projektet som möjligt, helst parallellt med framtagande av krav­specifikation och användningsfall. Om effektmål finns, så börjar vi givetvis redan där. Den uppen­bara konsekvensen och fördelen med detta är att det snabbt blir tydligt var svaga punkter finns och var krav och lösning behöver kompletteras. På så sätt drivs kravhanteringen framåt av test, sk ”Testdriven kravhantering”.

Under framtagandet av testfall kan man se om ett krav verkligen är mätbart enligt ”SMART” (Specific, Mesaurable, Attainable, Relevant, Timely). Om inte, behöver kravet för­tydligas. 
I användningsfall som omsätts till testfall visas VEM, som gör VAD NÄR, med vilken INPUT och OUPUT. Stöttar lösningen därmed verksamheten i det dagliga arbetet? Om inte, behöver kravet förtydligas.
Även brister i andra specifikationer kan påvisas, som t.ex. Rollbeskrivningar och Begrepps- och Informationsmodell.

I projekt med begränsad tid, görs även en prioritering av vilka krav som behöver förbättras och på vilket sätt, gärna förankrat i effektmålen. Detta gör att de viktiga delarna av kravbilden uppnår en tillräcklig kvalitet, medan mindre viktiga delar av kraven visserligen fortfarande kan vara vaga, men vi kan leva med det, eftersom de just är mindre viktiga.

Med testdriven kravhantering skapas ett angreppssätt som gör det möjligt att göra det omöjliga och hantera en vag och svag kravbild.