Som tester er det sjelden jeg har fått anledning til å delta i kravspesifisering eller utarbeidelse av brukerhistorier i utviklingsprosjekter. Og dessverre virker det som dette er normalen, og ikke unntaket, for de fleste av mine testkolleger der ute.
Artikkel skrevet av Nina Ripmann, testleder i miles
Jeg har ikke fasiten på hvorfor dette er tilfellet. Inntrykket mitt er at det som regel bunner ut i at man ikke ser behovet. Man tenker ikke over at dette er en fase hvor testere har noe særlig å bidra med. Eller gjengangeren; man skal spare penger. Man tar seg ofte ikke råd til å involvere flere enn strengt tatt nødvendig i denne fasen. Funksjonaliteten testes jo før produksjonssetting, og da får man avdekket feilene i god tid før de treffer brukerne. Kanskje kjøres prosjektet i sprinter og da testes det fortløpende i tillegg. Tipp topp, tommel opp.
En testkollega av meg ble en gang satt på vent i et prosjekt frem til implementasjonsfasen var godt i gang før hun fikk bli med å bidra. Grunnen var nettopp at man skulle spare penger, selv om det i prosjektplanen stod svart på hvitt at man skulle teste tidlig og at kvaliteten på leveransene var viktig. Men er det egentlig tidlig når man allerede har startet med implementasjonen? Min mening er : nei, dette er ikke tidlig.
Jeg mener også at en med testfaglig bakgrunn har mye å bidra med inn i kravspesifiseringen og utarbeidelsen av brukerhistorier, og at man til og med kan spare penger på å få en erfaren tester med seg i denne fasen.
Hvordan kan en tester bidra inn i spesifiseringsfasen?
Testeren trenger ikke nødvendigvis være med på hele skrivearbeidet. Men det er lurt å la testeren gjøre en gjennomgang og kvalitetssikre før spesifikasjonen ferdigstilles. Fagsiden og produkteierne har som regel god peiling på hva som bør leveres, men det er jo allment kjent at man fort kan se seg blind på eget arbeid. Det ligger ofte mye tankearbeid bak uten at alt nødvendigvis gjenspeiles i produktet som er laget.
Så hvorfor burde en tester være involvert i denne revideringen? En erfaren tester har som regel et annet mindset som gjør at vi tenker litt annerledes enn mange andre roller. Mens produkteieren ofte er fokusert på hva som skal lages (løsningsorientert), vil testeren av vane ha på den kritiske hatten og ha en egen evne til å se hva som kan gå galt (problematiserende). Testerne har også en evne til å se ting fra sluttbrukerens perspektiv, og derfor se helheten i løsninger.
Her vil en tester typisk ha en god evne til å kunne identifisere krav som ikke er spesifisert, ikke spesifisert godt nok, krav som kan misforstås, som motsier seg selv, eller krav som er åpne for tolkning. Erfarne testere er gjerne også kjent med verktøy og teknikker som kan benyttes for å gjøre kvalitetssikring på alle stadier av et prosjektløp.
En ekstra bonus med å ha med testeren i denne fasen er også at testeren er bedre kjent med hva som skal leveres, og dermed får en bedre forutsetning for å planlegge og gjennomføre videre testing mer effektivt.
Men, spare penger sa du?
Mangler i kravspesifikasjonen tillater gjerne rom for ulike tolkninger og antagelser. I verste fall til og med mangel på gode vurderinger. Avdekker man slike mangler allerede i spesifikasjonsfasen vil det gi mindre sannsynlighet for følgefeil.
Omfattende prosess
Dersom en tester først involveres, tester og finner feil etter at funksjonaliteten er ferdig implementert, krever det at testeren melder feilen tilbake til utvikling. På dette tidspunktet har som regel utvikleren gått videre til en ny oppgave, og må bruke tid på å sette seg inn i problemstillingen igjen. Kanskje må det feilsøkes litt, kanskje var kravet utydelig og produkteier må involveres for avklaringer. Deretter må feilen rettes før testeren kan teste funksjonaliteten på nytt. Mange personer har vært involvert og timene gått. Og tid er jo som kjent penger. Enda verre vil regnestykket bli om feilene oppdages i produksjon og flere ledd ble involvert i å rapportere feil fra brukeren, via brukerstøtte og tilbake til utviklingsteamet.
Det er ingen hemmelighet at det er raskere for produkteier å rette feil og mangler i kravspesifikasjonen etter en gjennomgang med en tester. Færre personer involvert, og tid og penger spart.
Jeg har jobbet som tester i prosjekter hvor vi har vært involvert i spesifiseringsfasen, men også i prosjekter hvor jeg har fått levert et “ferdig” produkt i fanget og blitt bedt om å teste rett før produksjonssetting. Fellesnevneren er at vi alltid fant feil under testing, men betraktelig færre feil når vi hadde vært med i spesifiseringsfasen av prosjektet. Personlig anser jeg dette som involvering av test tidlig i prosjektet.
Så hvorfor gjør vi ikke mer av det?