Hvorfor teste når vi er feilfrie?

I vår teknologiske hverdag tar vi for gitt at digitale løsninger og tjenester skal fungere problemfritt. Det er ingen selvfølge når kompleksiteten øker, og ulike system og teknologier skal samarbeide på tvers av standarder og arkitekturprinsipper. Seriøse aktører investerer derfor i feilsøking og problemløsing lenge før produktet tas i bruk. Det kan vi lære av.

Av: Torbjørn Laukvik, seniorkonsulent i Webstep

Det vanligste er nettopp at de fleste bedrifter ikke tenker så mye på hvordan test kan introduseres i egen produksjonslinje. Ofte får man inntrykk av at IT jobber med å utvikle hva man trenger, og har en generell forventning om at alle involverte jobber godt og effektivt sammen.

Og det er i utgangspunktet riktig. På de aller fleste arbeidsplasser jobber man mot å levere et kvalitetsprodukt uten mangler, som gjør det man har planlagt og bestilt.

Det er også fullt mulig at utviklerne har et godt utviklet system for å lage enhetstester i deres leveranse. Men holder ikke dette?

Det korte svaret er kanskje. Det lange svaret er nei.

Måle – sjekke – prøve

Jeg foretrekker alltid å komme med noen allegorier når jeg skal forklare hvorfor man tester. Og ofte tyr jeg til en snekker-sammenligning. Så hva er test?

For de av verdens befolkning som har kjøpt en ny leilighet eller fått bygd et nytt hus vet at ting kan gå galt. Man overtar sitt nye hjem eller hus og oppdager at døra ikke kan lukkes, vannet samler seg i hjørnet lengst borte fra sluket og det trekker fra vinduene. Dette er hva som kan komme fra å kun bruke enhetstest. Døra er sikkert fin den, men den er kanskje for bred for åpningen, veggen kan være skjev eller låsen fungerer ikke.

Kvalitet og testledelse for ditt hjem vil da bestå i å ettergå installering av forskjellige arbeidsoppgaver og måle, sjekke og prøve at alt fungerer. Heldigvis så er jo byggebransjen sterkt regulert slik man ikke skal flytte inn i et hus som raser sammen.

Eksterne øyne ser mer

Dette finnes ikke i IT, der man er i stor grad overlatt til seg selv for å verifisere at det man har brukt kanskje to år på å utvikle faktisk løser hva man ønsket.

Det er altså en fordel om andre enn utviklere ser på sluttproduktet fordi det er lett å se seg blind på eget prosjekt. Hvis man skal slipe et bordbein for å at det skal se bra ut, så er det viktig at man ikke sliper så mye at det ikke passer inn i bordet lenger, og utviklere kan gå i samme fellen hvis de blir for fokusert på å løse et problem og ikke ser på helheten.

Hvordan vet vi om vi trenger test?

Ethvert IT-miljø har leveranser. Målet med en leveranse er å levere en endring. Dette er ofte for å kunne tilby noe nytt og spennende til kunden og deres brukere. Det kan være en app, et nytt internsystem eller ny måte å selge over internett.

Men hvor mange planlagte endringer kommer fra feil? Hvis man ikke sporer feil, men registrerer rettelser fra tidligere leveranser likt med hva man utvikler, så er vet man ikke hvor mye tid og penger som brukes på feilretting.

Sporing av arbeid

Målet med test er aldri å legge skylden på en utvikler eller en kravstiller. Det handler i stedet om mulighet til å spore arbeidet med feilretting, og kunne jobbe med å forbedre leveranseprosessen.

Uten registrering av feil er dette umulig. Det er essensielt at man logger feil som oppstår og kategoriserer dem. Feil har vanligvis to kategorier: Alvorlighetsgrad og Prioritet. Det er vanlig å bruke følgende grader: Blokkerende, Kritisk, Alvorlig, Mindre alvorlig og til sist Triviell.

En alvorlig feil som stopper en prosess, kræsjer et system eller forhindrer bruk av programmet har gjerne alvorlighetsgraden Blokkerende. En mindre feil som har liten betydning på sluttproduktet uten større påvirkning på kunden kan gjerne få graden Triviell. Og siden man kan ha to feil med samme alvorlighetsgrad, så legger man også på en prioritet.

Dette er ikke alltid like lett, og blir ofte et forsømt område. Verdien ligger i å samle «big little data», som kan brukes til å gjennomføre forbedringer – gjerne i tett samspill mellom kravstiller og utvikler.

Nå registrerer vi feil i stor fart, hva nå?

Det neste steget er å legge en testplan. Dette kan man lage så komplisert eller enkelt man vil. Og det er også tema for neste artikkel – «Planlegg for feil!»

Ledende på test

Hvis du har et behov for å verifisere en leveranse eller et prosjekt, så nøl ikke med å ta kontakt med oss! Vi dekker hele test- og kvalitetsløpet, fra kvalitets- og teststrategi, til gjennomføring, oppsummering og rapportering.

Webstep har lang erfaring fra testing av ulike plattformer og teknologier, og er sertifiserte innen standarder som ISO, ISEB/ISTQB Test Manager, Advanced og Agile Test. Ta kontakt for en prat om mulighetene!