Jag hade för en tid sedan en mycket intressant diskussion om test överhuvudtaget. Ibland när man är i en speciell värld (där test är etablerat) så tror man att hela världen är i fas med sin egen värld. I detta fall skickades jag bryskt tillbaka till 90-talet, innan testmetoder, processer och själva testrollen till stora delar var känd.
Samtalet började med ”Varför test?! Varför ska vi ha testare i detta projekt och om vi ska ha det varför räcker inte t.ex. max en testare per tio utvecklare?!”.
Pang! Back to the nineties.
När jag är ute och pratar test med personer generellt så brukar mitt huvudargument vara ”hur stor risk vill du ha?”. Svaret på den frågan är mer eller mindre generellt – så liten som möjligt. Då är följdfrågan, hur närmar vi oss ett sådant mål?
I just denna diskussion så bet inte argumentet risk utan personen hade hakat upp sig kostnaden. Personen ansåg att riskminimering med hjälp av testspecialister inte behövdes, det var något som projektet själva klarade av och om man skulle ”lyxa” till det så var det max ration 1:10 som skulle krävas (en testare per tio utvecklare)
Mina argument, både dåliga och bra, fick dock in diskussionen på ett annat spår. Istället för att se på kostnaden så ställde jag följande frågor:
- Vilka var de stora felen som hittades i produktion i de senaste projekten?
- Vad var kostnaden för att ordna till de felen och vilka anser du att ni borde ha tagit innan release?
- De som du tycker att borde upptäcks, varför togs de inte?
- Finns det ett problem med att den som har utvecklat en sak inte tänker från ett tredjemansperspektiv?
- Hur mäter ni kvalitet?
Svaren var ganska vaga och ett ljus tror jag tändes. Går vi sedan in på kostnaden så är det hur mycket värde som tänkbara felaktigheter kan kosta som bestämmer hur mycket man skall testa. Allt enligt den mycket enkla formuleringen:
Liten risk – lite test.
Hög risk – mycket test.
Det går alltså inte att ha ett universellt mätetal avseende antalet resurser kontra testpersonal. Utan det är vad som man vill uppnå som sätter gränsen. Felfritt blir det aldrig, men värdet att veta vad man har verifierat innan release innebär kontroll.
Så för mig personligen blev det en väckarklocka hur man säljer in test hos en person som bara ser det som en kostnad som denne bara skulle vilja bli av med. Argumenten kan filas och behöver alltid filas. Dessutom måste vi inom detta ämnesområde alltid berätta vad vi kan hjälpa till med. Lyckas vi inte med det så vi har vi egentligen inget självberättigande. Ingen annan kommer att göra det jobbet för oss!
Till sist, personen hade rätt från sitt perspektiv, det är upp till oss att förändra det genom att visa på nyttan och att argumentera på ett sådant sätt som går hem.
Berätta gärna om Era historier, hur ni hanterar liknande situationer eller hur tankegången går!
Jag brukar använda två olika argument med samma bakomliggande budskap, ett kort och ett lite längre:
* Om du tror på tur, så behöver du inte testning.
* För att minska osäkerheten kring vad produkten kan och inte kan, så behöver du information (Information = reducerad osäkerhet). För att minska osäkerheten kring vilka eventuella problem som finns, så behöver du information.
Enligt den definition som jag utgår ifrån (Cem Kaner) så är “testning en teknisk undersökning i syfte att ta fram kvalitetsrelaterad information som projektets intressenter är intresserad av”, vilket alltså innebär att jag som testare hjälper projektets intressenter att ta fram information som de är intresserade av. Eftersom intressenter kan ha diametralt olika intressen så kan man på detta sätt täcka av stora delar av informationsbilden, och glöm inte de dolda intressenterna http://thetesteye.com/blog/2009/03/the-hidden-project-stakeholders/
Jag tycker inte att frågan “hur stor risk vill du ha?” hjälper så mycket eftersom, som du säger, det är ju ingen som vill ha någon risk alls.
Och testningen minskar ju inte risk, men däremot så bidrar ju testningen med att hjälpa projektledaren att minska risken i och med att denne kan fatta beslut baserat på den information som har tagits fram.
Jag gillade förr att prata om allvarliga buggar och kostnaden för dem, men detta kan vara ganska abstrakt både för mig och för den jag pratar med. Och om något är abstrakt så är det en stor chans att man chansar, eftersom man inte ser konsekvenserna och de påtagliga följder det skulle ha. (Dessutom är det många IT-projekt där det inte alls spelar så stor roll att man hittar allvarliga buggar efter release, så chansen är att den man pratar med tycker att det är en baggis…)
Cheers,
Henrik
Tack för kommentaren.
Jag gillar speciellt ditt andra angreppsätt som är ett som jag brukar också använda mig av (fast med andra ord). Riskbegreppet går oftast hem som tagline när man pratar med personer som har någon koll på kvalitet och riskbaserade approacher, vilket tack och lov många har numera.
Det är informationen som man tar fram via verifiering och granskningar som minskar risken.
Kostnad kan vara ett annat bra exempel som många förstår. Fungerar inte vanliga argument så kan alltid ett skräckexempel vara värt att dra! 🙂
Henrik och Bengt, Jag tycker ”Hur mycket risk är du bered att ta” fungerar utmärkt, för test minskar ju faktiskt risken, eftersom en risk per definition är osäkerhet om någonting skall inträffa eller ej. Vet man att något är fel så är det ju ett faktum, vet vi att någonting är ok så finns det ingen risk. Vi i test kan ju efter att ha testat säga att under dessa omständigheter så slår risken in eller ej. Därför tycker jag att man med fog kan säga att test minskar risken.