De fleste IT-prosjekter havarerer ikke fordi teknologien svikter. De havarerer fordi risiko ikke ble oppdaget tidlig nok, og en uforholdsmessig stor del av den risikoen ligger i testfasen.
Uklare krav, testdata som mangler, integrasjoner som ikke spiller på lag og testmiljøer som krasjer på feil tidspunkt: dette er feilene som skaper forsinkelser, ekstra kostnader og dårlig kvalitet. Og de er ikke uunngåelige. Forskning viser at en feil som koster 100 kroner å rette tidlig i utviklingen, koster opptil 100 ganger mer å rette i produksjon. Det er ikke en liten forskjell. Det er forskjellen mellom et prosjekt som lykkes og ett som sprekker.
Denne artikkelen gir deg en praktisk, ledervennlig guide til testrelatert risiko: hva det er, hvordan du finner det, og hva du gjør med det.
Hva er testrelatert risiko?
Testrelatert risiko er alle forhold som kan føre til at systemet ikke fungerer som forventet, eller at dere ikke får testet godt nok før lansering. Det er ikke begrenset til feil i kode. Det omfatter alt som påvirker kvaliteten på leveransen og fremdriften i prosjektet.
En enkel definisjon: testrelatert risiko er sannsynligheten for at noe i testprosessen svikter, multiplisert med konsekvensen det vil ha for prosjektet. Svikten kan skyldes manglende testdata, ustabile miljøer, uklare krav eller dårlig koordinering. Risikoen er ikke alltid synlig. Den viser seg gjerne som forsinkelser, akutte feil i produksjon eller feil funksjonalitet som brukerne oppdager etter lansering.
Å håndtere testrelatert risiko handler om å ta kontroll over kvaliteten, fremdriften og hva som faktisk er klart for produksjon.
De vanligste typene testrelatert risiko i IT-prosjekter
Med nesten 30 år i bransjen har vi i Aspiria sett de samme mønstrene gjenta seg. Noen risikoer er mer ødeleggende enn andre, og nesten alle kan fanges tidlig hvis man vet hva man ser etter.
Uklare krav, det stille prosjektstopperen
Uklare krav er den vanligste enkeltårsaken til feil i produksjon. Når det ikke er enighet om hva systemet skal gjøre, blir både utvikling og testing et gjetteprosjekt. Testerne vet ikke hva de skal sjekke mot. Utviklerne vet ikke hva de skal levere.
Vi ser dette særlig i prosjekter der kravene har vokst frem gradvis, der det aldri ble satt av tid til å dokumentere og godkjenne dem skikkelig. Resultatet er en testfase full av diskusjoner om hva som er feil og hva som er riktig.
Kravene må være forstått, dokumentert og godkjent av alle parter før test starter. Det høres enkelt ut. Det er det ikke.
Testdata som ikke finnes, eller ikke er gode nok
Prosjekter stopper opp fordi testerne ikke får riktige testdata. Det er mer vanlig enn mange ledere tror. Enten mangler dataene helt, eller de er ufullstendige, ikke representative nok, eller de er låst bak GDPR-hensyn som ingen tok stilling til tidlig nok.
God praksis er å avklare databehov, eierskap og datakvalitet allerede i planleggingsfasen, ikke når testfasen er i gang.
Ustabile testmiljøer og falske feil
Et ustabilt testmiljø gir falske feil, usikkerhet og tap av tid. Testerne bruker timer på å avgjøre om problemet er i systemet eller i miljøet. Det er frustrerende og dyrt. Vi ser det særlig i prosjekter med mange parallelle utviklingsspor der miljøene ikke er tilstrekkelig isolert.
Løsningen er tydelig eierskap og faste rutiner for drift og overvåkning av testmiljøene, ikke en ansvarsfraskrivelse der alle antar at noen andre tar seg av det.
Integrasjoner som endrer alt
Integrasjoner er ofte den største risikofaktoren i moderne IT-prosjekter, og den som oftest undervurderes. I prosjekter vi har vært involvert i, som moderniseringen av saksbehandlingsløsninger i offentlig sektor, er det nettopp integrasjonene mot fagsystemer og felleskomponenter som krever mest oppmerksomhet i testfasen.
Selv en liten endring i ett system kan rive med seg fem andre. Integrasjonstesting må planlegges som et eget spor, ikke behandles som en del av «vanlig testing».
Hvordan avdekker du testrelatert risiko tidlig?
Det krever ikke teknisk kompetanse å avdekke risiko. Det krever gode spørsmål og en strukturert teststrategi som trekker risiko frem i lyset fra dag én.
Still disse spørsmålene før testfasen starter
Bruk disse spørsmålene i prosjektgjennomgangen. Hvert uklart svar er et faresignal:
- Er kravene fullstendige, dokumenterte og godkjent av alle parter?
- Har vi riktige testdata og tilgang til dem?
- Er testmiljøene stabile og tilgjengelige på de tidspunktene vi trenger dem?
- Vet vi hvilke integrasjoner som er kritiske, og hvem som eier dem?
- Har vi tydelige kriterier for hva «klar for test» betyr?
- Har vi nok ressurser og riktig kompetanse til å gjennomføre testen?
- Hvem eier risikoen, og hvordan rapporteres den oppover?
Hvis svaret er uklart på ett eller flere av disse punktene, har du risiko. Ikke potensiell risiko. Faktisk risiko.
Hva en erfaren testleder ser som andre overser
En god testleder stiller disse spørsmålene fra første dag. Ikke fordi det er prosedyre, men fordi erfaring har lært dem at det er her prosjektene rakner. De ser usikkerhet i planene, hullene i kravdokumentasjonen og integrasjonene som ikke er avklart, lenge før testfasen starter.
Det er verdien av å involvere testlederen tidlig. Ikke som en ressurs som skal «ta testen» til slutt, men som en kvalitetsvokter gjennom hele prosjektet.
Slik analyserer du testrelatert risiko, en enkel modell
Identifisering er bare det første steget. Neste steg er å vurdere hvilken risiko som faktisk fortjener oppmerksomheten din.
Testrelatert risiko vurderes langs to akser: sannsynlighet (hvor trolig er det at dette skjer?) og konsekvens (hva stopper, forsinkes eller feiler hvis det skjer?). Risiko med høy sannsynlighet og alvorlig konsekvens må håndteres umiddelbart. Risiko med lav sannsynlighet og liten konsekvens kan man leve med og følge med på.
Prioriter risiko som kan stoppe hele prosjektet eller testfasen, som påvirker funksjoner brukerne er avhengige av, eller som kan skape kostnader etter lansering. Følg med på risiko som er kjente og lave i konsekvens, men som kan eskalere dersom forholdene endrer seg.
Denne modellen gir deg et felles språk med styringsgruppen og gjør det lettere å kommunisere hva som faktisk er kritisk, uten å drukne i tekniske detaljer.
Tiltak som gjør en reell forskjell
Mange prosjekter har gode planer for risikohåndtering. Færre gjennomfører dem. Her er tiltakene vi ser gjør størst forskjell i praksis.
Bygg inn testing tidlig («shift-left»)
Shift-left testing betyr at test starter tidligere i prosjektløpet, ikke etter at alt er ferdig utviklet. Det høres selvsagt ut, men i praksis er det fortsatt vanlig at testing presses inn mot slutten. Da er det for sent til å gjøre noe med de virkelig grunnleggende problemene.
Jo tidligere dere tester, jo billigere er det å rette det dere finner. En feil som oppdages i produksjon koster gjennomsnittlig 30 ganger mer å rette enn om den var fanget tidlig i prosessen. Shift-left er ikke et teknisk valg. Det er et forretningsmessig valg.
Andre tiltak som virker i praksis: avklar testdata og GDPR-begrensninger tidlig, navngi en ansvarlig for testmiljøene, planlegg integrasjonstesting som et eget spor, og vurder en ekstern testleder eller QA-rolle i prosjekter med høy risiko.
Krev handlingsorientert rapportering
En god testleder gir deg status, avvik og risiko med konkrete anbefalinger. Ikke bare en liste over åpne feil. Du skal vite hva som er kritisk nok til å stoppes nå, hva som kan vente, og hva det vil koste å ikke handle.
Hvis rapporteringen du mottar ikke gir deg grunnlag til å ta beslutninger, er det et tegn på at noe mangler, enten i kompetansen, rollene eller strukturen rundt testarbeidet. Les mer om typiske feil i testfasen for å gjenkjenne mønstrene.
Hva koster det å ikke håndtere testrelatert risiko?
Det er fristende å se på testing som en kostnad. Det er en feil tankegang.
Testrelatert risiko som ikke håndteres, øker eksponentielt jo senere feilen oppdages. En feil som koster 100 kroner å rette i kravfasen, koster 1 000 kroner i systemtest og 100 000 kroner etter lansering. Ikke fordi selve rettingen er dyrere, men fordi konsekvensene er bredere: brukere er rammet, andre systemer er påvirket, omdømmet er svekket, og teamene må koordinere på tvers for å løse noe som aldri burde nådd produksjon.
God testing gir færre feil etter lansering, lavere prosjektkostnad og bedre kontroll på milepæler. Det er billigere å fange risikoen tidlig. Det vet alle som har vært gjennom et vanskelig prosjekt. Men det krever at noen eier risikoen, og at det faktisk er satt av tid og kompetanse til å håndtere den.
Vil du redusere testrelatert risiko i ditt neste prosjekt?
Testrelatert risiko er en av de vanligste årsakene til forsinkelser og kostnadsoverskridelser i IT-prosjekter. Og den kan reduseres betraktelig hvis man engasjerer riktig kompetanse tidlig og har en plan for hva man ser etter.
Aspirias testledere har gjort dette i nesten 30 år, i prosjekter hos virksomheter i bank, offentlig forvaltning og telekom. Ta kontakt hvis du vil snakke om hva som vil gi mest trygghet i deres situasjon.