– Disse feilene gjøres hele tiden i testfasen

– Hvis du ikke tester, hvordan vet du hva du betaler for?

Da et nytt, omfattende journalsystem skulle rulles ut samtidig på fire sykehus i Oslo, var det rutinerte Anne Christine Knudsen som fikk den viktige jobben som akseptansetestleder. Fem ulike systemer skulle bli til ett, som igjen skulle kommunisere med 57 andre systemer. Risikoen for tekniske feil var stor, og konsekvensene av feil kunne bli dramatiske.

– Det var ekstremt, medgir hun. – Det stod om liv og helse.

12 000 ansatte på sykehusene skulle begynne å benytte seg av det nye systemet på samme dag. For å få jobben gjort hadde hun syv-åtte koordinatorer og hele 125 testere med ulike kompetanser til rådighet. Prislappen på prosjektet lå på en halv milliard.

– Du må ha nerver av stål i så store prosjekter, sier Knudsen og legger til at resultatet ble bra.

Tre gylne regler

Ikke alle prosjekter er like store, men de aller fleste bedrifter må til tider installere nye IT-systemer. Det kan oppleves som en kronglete og frustrerende prosess, men det trenger ikke å være det, forklarer Knudsen.

– Det hjelper med strukturert testing, men mange har ikke engang testing med i budsjettet. Derfor går 70 prosent av IT-prosjekter ikke etter planlagt kost, tid og kvalitet.

– Vi er kanskje litt naive og tenker at dette bare ordner seg, sier Knudsen som til daglig jobber som avdelingsleder i Sogeti, et selskap som leverer teknologi- og programvaretesting.

Hun skisserer derfor opp tre råd som alle som tester systemer bør vite.

– På disse punktene gjøres det feil absolutt hele tiden, påpeker hun.

1) Test underveis

Ikke utsett alt til slutten, test heller underveis.

– Kjør tester på mindre leveranser underveis, ikke vent til alt er klart. Det er viktig at testerne kommer inn tidlig i prosessen. I standardavtaler står det åtte-ni milepæler, og halvparten handler om testing.

2) Vær nøye med kravspesifikasjonene

Kravspesifikasjonen står for over halvparten av alle feilene, forklarer Knudsen. Slurver vi med den, er det ikke sikkert at vi får det vi forventer.

– Standardkontrakter brukes ofte, og det er greit nok. Men du bør ha en klar forståelse om hva som skiller din bedrift fra standarden.

En god kravspesifikasjon gjør at du vet hvilke krav du kan stille til leverandør. Hvis du ikke har et forhold til dette, gjør du det vanskelig for deg selv på slutten av prosjektet.

3) Prioriter det med høyest risiko

Kjør en produktrisikoanalyse. Identifiser områdene som kan få alvorlige konsekvenser. Disse testes først og grundigst.

Feil kategoriseres gjerne som A-, B- og C-feil. En A-feil er den mest alvorlige, og kan gjøre et helt system utilgjengelig. Dersom hele nettbanken til DNB plutselig er nede, er dette typisk en A-feil. Dersom innføringen av et nytt system havner på forsiden av VG, er også sjansen stor for at det er begått en A-feil.

Et eksempel er da selvangivelsen til Kenneth (36) plutselig lå åpent tilgjengelig for tusenvis av personer gjennom Altinn.

Til sammenligning kan en C-feil være en skrivefeil, mens en B-feil ligger et sted mellom disse i alvorlighetsgrad.

Livsnerven i bedriften

IT har i mange selskaper gått fra å være en litt perifer avdeling til å bli selve livsnerven i bedriften, forklarer Knudsen.

– Det gjør at det er enda viktigere å sørge for at både IT-systemene og arbeidsprosessene er i orden. IT er en del av kjernen i mange bedrifter. Statoil klarer for eksempel ikke å få opp olje uten IT. Jo mer integrert systemet er, desto viktigere er det. Uten fungerende IT, slutter mange bedrifter å tjene penger.

Det er ikke barnemat å være testleder. Det er mye du må holde styr på. Tekna tilbyr derfor Testledelse i praksis, et todagers kurs som gir deg verdifulle råd for å lykkes med å lede et testteam. Kurset er utarbeidet av ekspertene i Sogeti.

– Her får du oversikt over hva du bør vite, og kunnskap om hvor du kan hente mer hjelp, sier Knudsen.