fbpx Skip to content

Krav och test är inte samma sak!

Något jag som kravanalytiker ofta reagerar på, och nästan lika ofta hamnar i argumentation kring, är att krav och test hör ihop. Många företag jag har varit i kontakt med klumpar ihop dessa två områden i samma grupp och ser dem som olika smaker av samma sak. För mig som bara intresserar mig för kravsidan så känns detta väldigt konstigt. Problemet detta ger är att inget av områdena får det utrymme de behöver för att lyckas, fokus riskerar att antingen hamna på det ena eller det andra.

-Men det går inte att testa utan krav, för oss testare hänger krav och test ihop supertight.
Tolka mig rätt, jag förstår att det är omöjligt att göra ett bra jobb som testare om inte det finns krav i projektet, men mitt motargument mot detta är: det är lika svårt för utvecklare att utveckla utan krav eller för projektledare att leverera utan att veta vad som ska levereras. Det finns inget som säger att krav hänger ihop mer med test än övriga roller.

Att skriva krav handlar om att beskriva något man inte vet vad det är än och sedan tillsammans med arkitekter, UX-folk, designers med fler, beskriva vad som ska byggas och validera att lösningen lever upp till kraven. Det går utmärkt att skriva krav utan att ha med test.

Efter ett par år som kravanalytiker har jag sett att kravområdet innefattar mycket mer än att sitta som en del av ett utvecklingsteam och skriva krav för utvecklare och testare som sitter längre ner i korridoren. Kravarbetet skiljer sig väldigt mycket när man sitter som beställare och endast skriver behoven, vilket blir ännu mer tydligt när man skriver krav för upphandlingar. I dessa kontexter så är faktiskt test bland det sista jag brukar bry mig om, just för att man inte beskriver ett system, utan vad det tänkta systemet ska åstadkomma. Det ska dock sägas att i andra kontexter är testperspektivet betydligt mer närvarande för mig som kravanalytiker.

I de projekt som kravarbetet fungerar som det ska kommer testerna inte ens att utföras mot det kravanalytikerna skriver. Testerna utförs då mot en systembeskrivning eller ett lösningsförslag skrivet av arkitekter eller någon designer och inte behovskraven. Acceptanstesten görs fortfarande mot behovskrav, men den utförs oftast inte av systemtestare i alla fall.

En filmrecensent är inte nödvändigtvis bra på att göra film, en tävlingsförare kan säkert berätta vad som är fel på en tävlingsbil utan att för den delen kunna bygga en bättre själv, en pilot är inte nödvändigtvis bra på att bygga flygplan men kan ändå bedöma hur bra ett plan är. Testare är ofta duktiga på att bedöma krav och kunna återkoppla vad som är bra respektive dåligt med de skrivna kraven men att se dessa roller som samma sak är dock långt ifrån sanningen.

Jag vill med detta inte reducera testområdets betydelse eller kunskap, utan tvärt om att se det som det eget område med sina egna mål, precis som jag ser på kravanalys. Det är dags att andra ser detta på liknande sätt, som två områden med helt olika fokus. Att skriva krav är att beskriva vad ett system ska åstadkomma, inte att skriva testunderlag.