Hvorfor gidder vi å lete etter feil når det er mer effektivt å forebygge feil?
Som tester har jeg alltid vært opptatt av kvalitet. Jeg har alltid gjort mitt beste for å finne mest mulig feil så effektivt som mulig. Som testleder har jeg laget testplaner og strategier, også de med tanke på å finne mest mulig feil. Målet har vært å finne så mange feil som mulig og få rettet disse før man går i produksjon.
Jeg er sertifisert innen ISTQB – den mest anerkjente sertifiseringen innen test. En sertifisering som årlig tas av tusenvis av testere og testledere. Testteknikker er en selvsagt og nyttig del av denne sertifiseringen. Man lærer om de forskjellige testfasene, man får tips om hvordan bør strukturere testen og hvordan man bør gå fram for å finne gode testcaser. Alt med fokus på å finne feil, det er tross alt det testere skal gjøre – finne feil. Men er det den mest effektive måten å lage programvare med god kvalitet? Man får til stadighet høre at jo tidligere man finner feilen jo billigere er det å rette den, ville ikke da det billigste være om man fant feilen før den ble innført?
Før jeg begynte å jobbe med IT og test jobbet jeg som sykepleier. En lærdom jeg har tatt med meg derfra er at det er vesentlig billigere og enklere å forebygge sykdom enn det er å behandle sykdom. Se bare på alle livsstilssykdommene vi har i dag. Mange av disse kunne vært forhindret med enkle forebyggende tiltak. Et godt eksempel er Dine30-kampanjen som Helsedirektoratet i Norge nå har startet. Her oppfordrer man alle til å komme seg opp av stolen og være i bevegelse i minst 30 minutter hver dag. Målet med kampanjen er å bedre folkehelsen gjennom et økt aktivitets nivå. Dette er et billig og enkelt tiltak som kan spare samfunnet for millioner av kroner. (Eller kanskje til og med milliarder)
Jeg tenker at mange av de samme prinsippene gjelder i IT-utviklingsprosjekter – det er billigere å forebygge feil enn å rette feil. Den kanskje mest effektive måten å forebygge feil på er å ha større fokus på krav og kravprosessen. Hvem har vel ikke opplevd å skrive tester på utdaterte krav, eller at når man får levert systemet dekker det ikke de behovene man egentlig har? Med en bedre kravprosess er det større sjanser for at man får akkurat det systemet man ønsker og at det i tillegg blir levert med få funksjonelle feil.
Når jeg snakker om å forebygge feil, mener jeg ikke revisjon av dokumenter med fokus på å finne skrivefeil (Ja, jeg vet det ikke er det eneste man ser etter). Men jeg mener at man må holde fokus på krav og det reelle behovet man har. Jeg snakker om at produkteier setter seg ned snakker med brukerne av systemet og finner ut hvilket behov man faktisk har og ikke hvilket behov man tror man har. At samme produkteier følger opp leverandør, gjerne representert med funksjonell arkitekt, og sikrer at de snakker samme språk og har samme oppfatning av hva det er man skal lage.
Dette krever langt større bruk av ressurser tidligere i utviklingsløpet, men det vil spare ressurser senere. Har man forstått kravene og behovet og lager det riktige systemet med en gang sparer man mange runder med avklaringer, feilsøk, feilrettinger og retest. Det er det jeg tenker på med å forebygge feil.
Behovet for «tradisjonelle» testere vil fortsatt være der, men vil kunne gjennomføres mye mer effektivt når man vet at systemet alt oppfyller alle de funksjonelle krav man har. Kanskje kan man fokusere testen mer på å gjøre systemet enda mer robust?
Mitt mål er fortsatt å levere programvare med høy kvalitet, men jeg vil jobbe proaktivt framfor reaktivt. Tør du ta steget og heller satse forebyggende?
Stretch er sterkt representert på Testdagen Odin 2015 – Norges største konferanse innen softwaretesting. Ønsker du vite mer?