Systemtesting

En feil som oppdages tidlig i utviklingen koster kanskje en time å rette. Den samme feilen, funnet etter at systemet er i produksjon, kan ifølge IBM Systems Sciences Institute koste ti ganger så mye. Det er ikke et argument for å teste mer. Det er et argument for å teste på riktig tidspunkt.

Systemtesting er testleddet der alt settes sammen: ikke enkeltkomponenter, ikke isolerte integrasjoner, men hele systemet slik det faktisk skal brukes. Det er her feil i samspill, dataflyt og brukerreiser blir synlige for første gang.

Hva er systemtesting?

Systemtesting er testing av et ferdig integrert IT-system for å verifisere at det fungerer som en helhet. I motsetning til tidligere testfaser ser man ikke på enkeltkomponenter isolert, men på hvordan systemets ulike deler fungerer sammen på tvers av funksjoner, moduler, roller og integrasjoner.

Integrasjonstesting verifiserer at komponenter kommuniserer riktig. Funksjonell testing sjekker at enkeltfunksjoner gir korrekt resultat. Systemtesting går videre enn begge: her settes det hele sammen i komplette brukerreiser, og feil som ikke er synlige isolert blir kritiske når hele flyten kjøres.

Vi ser dette særlig i prosjekter innen bank og offentlig forvaltning, der systemet integrerer mot mange eksterne registre. En enkelt integrasjon kan fungere perfekt i isolasjon, men skape uventede feil i kombinasjon med en annen.

Systemtesting vs. akseptansetesting

De to blandes ofte, men har ulike formål. Systemtesting har et teknisk formål: avdekke feil og sikre at systemet er stabilt nok til å presenteres for brukerne. Akseptansetesting er forretningsmessig: virksomheten vurderer om løsningen dekker behovene og kan godkjennes.

God systemtesting er en forutsetning for en effektiv akseptansefase. Hvis systemet fortsatt inneholder grunnleggende feil når virksomheten skal godkjenne det, brukes dyrebar tid på feilsøking i stedet for kvalitetsvurdering.

Når gjennomføres systemtesting, og hva skjer når det er for sent?

Systemtesting gjennomføres etter integrasjonstesting og før akseptansetesting. I tradisjonelle prosjekter er det en tydelig avgrenset fase. I smidige prosjekter skjer det mer iterativt, gjerne per sprint eller ved større releaser.

Det vanlige problemet i smidige prosjekter er at systemtestingen nedprioriteres til fordel for sprint-tempo. Ny funksjonalitet legges til, og ingen sjekker om de samlede endringene fungerer som et system. Risikoen akkumulerer seg stille.

Vi kjenner mønsteret godt. Prosjektet er forsinket. Systemtestingen skvises inn på slutten. Ingen har full oversikt over hva som faktisk er testet. Systemet går i produksjon med kjente svakheter og ukjente risikoer. Det er ikke et testproblem. Det er et planleggingsproblem, og det løses i starten av prosjektet, ikke på slutten. En god teststrategi planlegger inn systemtestingen fra dag én.

Hva testes i systemtesting?

Systemtesting dekker hele systemet slik det faktisk skal brukes. Det viktigste er at brukeren kan gjennomføre komplette prosesser fra start til slutt uten brudd. At data lagres og videreføres riktig mellom moduler og integrasjoner. At samspillet med tredjepartsløsninger fungerer stabilt under realistiske forhold. At systemet reagerer kontrollert på feil, manglende data og avbrutte prosesser. Og at ulike brukerroller får riktig tilgang.

Testene bør basere seg på realistiske scenarier og realistiske testdata, ikke konstruerte løp der alt går perfekt. Det er i de vanskelige scenariene at systemets faktiske robusthet viser seg.

De vanligste feilene i systemtesting

Urealistiske testscenarier

Det er fristende å teste det som er enkelt å teste. Men produksjon er ikke en glad sti. Vi ser dette særlig i systemer som håndterer brukerinput: skjemaer valideres ikke riktig, feilmeldinger er uforståelige, og avbrutte prosesser håndteres ikke. Alle disse feilene kunne vært fanget, hvis scenariene hadde reflektert faktisk bruk. Se gjerne feilene som gjøres igjen og igjen i testfasen for en mer detaljert gjennomgang.

Uklare roller og ansvar

Når det ikke er tydelig hvem som eier systemtestingen, skjer det gjerne at noen antar at andre har dekket et område, og ingen gjør det. Vi har sett dette i prosjekter i telekom og finans, der mange leverandører er involvert og ingen har et helhetlig bilde av hva som faktisk er testet. Tydelig eierskap og en samlet testplan er ikke byråkrati. Det er det som hindrer at kritiske feil slipper gjennom.

Slik planlegger du en god systemtest

En god systemtest starter lenge før selve testingen. Du trenger et stabilt testmiljø som ligner produksjon, realistiske testdata og testscenarier som dekker brukerreiser, grensesituasjoner og feilsituasjoner, ikke bare det som fungerer greit. Avklar også hva som er utenfor scope: hva hører til systemtesting, og hva overlates til akseptansetestingen?

Under testingen, loggfør funn strukturert: hva skjedde, i hvilket scenario, og hva var forventet resultat. Skill mellom blokkerende feil og feil som kan håndteres etter go-live. Ikke alt må være perfekt. Men du må ha kontroll på hva som ikke er det.

Systemtesting gir trygghet, når det gjøres riktig

Med nesten 30 år i IT-prosjekter innen bank, offentlig forvaltning og telekom vet vi at systemtesting sjelden feiler på grunn av manglende ressurser. Det feiler på grunn av for lite tid, for urealistiske scenarier og for uklare roller. Alle tre er planleggingsproblemer, og alle tre kan løses tidlig nok.

Trenger du støtte til planlegging eller gjennomføring av systemtesting? Ta kontakt med våre testledere for en uforpliktende prat.

Ofte stilte spørsmål om systemtesting