Att testa när inga krav finns.

Det finns knappast något ämne som diskuteras flitigare i diskussionsgrupper och bloggar för testare. En jag har följt är på LinkedIn i diskussionsgruppen Software Testing & Quality Assurance med rubriken ”Testing moving target without requirements”.
Samtidigt är det den alltmer vanliga situationen inom IT branschen idag.

Teorin i testutbildningar säger ju att vi ska testa mot kraven men när verkligheten visar att kraven inte finns eller inte har uppdaterats då måste vi tänka till.

Att det blivit så här kan ha många förklaringar:

• Den agila metod utvecklarna arbetade med sa att vi dokumenterar ”Vad det blev” innan utvecklingsteamet splittrades. Men tid för detta fick man aldrig och ingen tydlig mottagare av leveransen fanns som kunde ställa krav på krav-, system- och testdokumentation.
• En QA funktion saknas som förser projekten med dokumentationsmallar och som dessutom granskar och följer upp leveransen.
• Den dokumentationsformalia som kännetecknade vattenfall och RUP projekt före 2004 kom att bli för tidsödande och dyr och passade inte ihop med det agila arbetssättet. Därför kom mycket av dokumentationen bli inaktuell. Vill man veta vad som gäller måste man läsa koden.
• IT projektledare har som huvudmål att leverera ett fungerande IT system enligt tidplan till beställaren. Leverans i tid är det viktiga och kvalitet kommer i andra hand liksom förvaltning av systemet som förutsätter bl.a. kravdokumentation. Leverans i tid är enkelt att mäta. Svårare är att mäta (bedöma) ”fungerande” som inte bara handlar om antal kända buggar klassificerade i skalan 1-5. Det handlar också om hur man upplever systemet, hur lätt det är att arbeta med, hur bra svarstider det är, hur enkelt och hur användbart det är.
• I många fall tror IT projektledare att man klarar sig utan en stark testledare utan låter utvecklarna testa sin egen kod för att sedan hoppas av felen hittas i acceptanstesten.

Så vad gör vi?

Som representant för alla med inriktning mot test och kvalitet och med långsiktigt bra IT systemlösningar som ska kunna förvaltas på ett effektivt sätt, kan vi inte bli handlingsförlamade eller ge upp.

Jag vet exempel där bra uppdaterade testfall blev betraktade som den gällande krav och test specen.

I andra fall har man i efterhand skapat användningsfall (Use case/User scenarios) . Det viktiga har varit att få upp en struktur på en grov nivå och undvika att få med för mycket detaljer.

Jag har också hos kunder sett att den bästa dokumentation (som också kan ses som krav) är att det finns en bra Användarhandbok (User Guide) som är snarlik en kravspecifikation.
Det är naturligtvis värdet att ha en kravspecifikation som ska vägas mot kostnaden att ta fram den och hålla den uppdaterad. Formatet kan vara ett Word eller Exceldokument men det kan också vara en kravmängd dokumenterad i ett kravverktyg eller test och kravverktyg.

Vi måste påminna och påtala risken som många företag lever med att man klarar sig ett tag till med odokumenterade krav genom att det finns personer som har dessa i huvudet.

Det är vanligare än man tror.

Det känns bra att vi är så många som sitter i samma båt, dvs. jobbar med test där det saknas krav. Samtidigt känns det som en stor utmaning att gilla läget (verkligheten) samtidigt som vi försöker göra den bättre genom att verka för effektiv krav och testhantering.

/Leif Bälter

Om Leif Bälter:

Leif Bälter har arbetat i olika systemutvecklingsroller under 70-80 talet men från 1989 och framåt har det handlat nästan enbart om test och kvalitetssäkring inom Telekom, Offentlig förvaltning samt Bank och Försäkring, varav de senaste 22 åren som konsult. Leif har under många år varit testledare, testkoordinator, lärare på testkurser och har gjort många strategiuppdrag om testprocessanalyser och förbättringsplaner.