Hver komponent er testet. Utviklerne har gjort jobben sin, og alle enhetstester er grønne. Så kobles systemene sammen, og ingenting virker. Betalingen når aldri frem til kjernesystemet. Saksbehandlingssystemet finner ikke oppslaget i folkeregisteret. Loggene sier lite, og tre leverandører peker på hverandre.
Dette er hverdagen i mange IT-prosjekter. Feilene bor sjelden inne i komponentene. De bor i grensesnittene mellom dem. Likevel er integrasjonstesting ofte det testnivået som får minst oppmerksomhet i planleggingen. Regningen kommer sent i prosjektet, når feil er som dyrest å rette.
I denne artikkelen får du en praktisk gjennomgang: hva integrasjonstesting er, hvorfor det så ofte svikter, og hvordan du gjennomfører det slik at feilene avdekkes før brukerne finner dem.
Hva er integrasjonstesting?
Integrasjonstesting er testnivået som verifiserer at to eller flere komponenter, systemer eller tjenester fungerer sammen. Der enhetstesting sjekker hver komponent isolert, sjekker integrasjonstesting grensesnittene mellom dem: at data flyter riktig, at feil håndteres, og at systemene forstår hverandres formater og regler. ISTQB definerer integrasjonstesting som testing utført for å avdekke feil i grensesnittene og i samspillet mellom integrerte komponenter eller systemer.
I praksis handler det om helt konkrete spørsmål. Kommer ordren frem til lagersystemet med riktige felter? Hva skjer når fakturasystemet ikke svarer? Blir transaksjonen rullet tilbake, eller blir kunden trukket to ganger?
Hvor i testløpet hører integrasjonstesting hjemme?
Integrasjonstesting ligger mellom enhetstesting og systemtesting. Først testes komponentene hver for seg. Deretter testes samspillet mellom dem. Til slutt testes hele løsningen samlet, før akseptansetestingen bekrefter at den dekker behovet.
Rekkefølgen bør være definert i teststrategien. Der bestemmer du også hvilke grensesnitt som er viktigst, hvem som eier dem, og hvilke miljøer testingen krever. Uten den avklaringen blir integrasjonstesting fort en aktivitet alle regner med at noen andre tar seg av.
Hvorfor svikter integrasjonstesting så ofte?
Aspiria har levert testledelse i snart 30 år, i bank, offentlig forvaltning og telekom. De samme fire mønstrene går igjen i de fleste prosjekter som sliter.
Integrasjonene er undervurdert i planleggingen
Moderne virksomheter har mange systemer som skal henge sammen. En kartlegging fra Integrate.io viser at store organisasjoner i snitt har 897 applikasjoner, men at bare 28 prosent av dem er integrert med formell styring. Hver kobling er et potensielt feilpunkt.
Likevel setter mange prosjektplaner av uker til utvikling og noen få dager til integrasjonstest. Det er å planlegge for at alt går bra på første forsøk. Det gjør det sjelden.
Ingen eier grensesnittene når flere leverandører er involvert
Leverandør A eier fagsystemet. Leverandør B eier integrasjonsplattformen. Kunden eier avtalene. Men hvem eier feilen når meldingen stopper et sted midt imellom?
I moderniseringsprosjekter i offentlig forvaltning har vi sett at grensesnittene mellom nytt og gammelt system er stedet der risikoen samler seg. Hver leverandør tester sitt eget ansvarsområde og melder grønt. Helheten er det ingen som tester. Da trengs en testleder med mandat til å teste på tvers, ikke bare innenfor hver kontrakt.
Testmiljøer og testdata kommer for sent på plass
Integrasjonstesting krever at begge sider av grensesnittet finnes i et miljø der de faktisk kan snakke sammen. Det høres selvsagt ut. I praksis er testmiljøer noe av det som oftest forsinker testarbeidet: miljøet til motparten er ikke klart, brannmuråpninger mangler, eller testdataene er så kunstige at de aldri treffer feilene som oppstår med ekte data.
Bestill miljøer og avklar testdata tidlig. En tommelfingerregel fra prosjektene våre: hvis testmiljøet ikke er avtalt før utviklingen starter, blir det forsinket.
Alt testes til slutt, i stedet for underveis
Når integrasjonstestingen legges som én stor aktivitet rett før lansering, kommer alle feilene samtidig. Da er det for sent å gjøre noe strukturert med dem. Utviklerne som skrev koden er kanskje videre til neste oppgave, og hver feilretting truer lanseringsdatoen.
Alternativet er å teste hvert grensesnitt etter hvert som det blir klart, og regresjonsteste de kritiske flytene ved hver større leveranse.
Slik gjennomfører du integrasjonstesting i praksis
Big bang eller inkrementelt?
Big bang-tilnærmingen kobler alle komponentene sammen og tester alt samtidig. Det kan fungere i små løsninger med få grensesnitt. I større prosjekter gjør det feilsøkingen nesten umulig, fordi du ikke vet hvilket ledd som feiler.
Inkrementell integrasjonstesting tar for seg ett grensesnitt om gangen og bygger ut helheten stegvis. Det krever mer planlegging og ofte stubber eller simulatorer for systemer som ikke er klare ennå. Til gjengjeld vet du til enhver tid hva som er testet og hva som gjenstår.
Hva bør testes i hvert grensesnitt?
Test mer enn solskinnshistorien. For hvert grensesnitt bør du dekke datastrømmen begge veier, formater og valideringsregler, og hva som skjer når noe går galt. Hva skjer når systemet ikke svarer, eller når samme melding sendes to ganger?
Feilhåndtering, timeouts og logging er like viktig som selve dataflyten. Og husk de ikke-funksjonelle kravene: et grensesnitt som svarer riktig, men bruker tolv sekunder, er også en feil. Forskjellen er forklart i artikkelen om funksjonell og ikke-funksjonell testing.
Automatiser der det gir mest igjen
Integrasjonstester egner seg godt for automatisering, særlig de kritiske flytene som må regresjonstestes ved hver leveranse. Automatiserte tester i byggeløpet fanger opp grensesnittfeil samme dag som de oppstår, ikke tre uker senere i en manuell testrunde.
Alt trenger ikke automatiseres. Start med flytene der en feil koster mest: betaling, innsending, oppslag mot eksterne registre.
Hva er forskjellen på integrasjonstesting, systemtesting og akseptansetesting?
Integrasjonstesting sjekker samspillet mellom komponenter og systemer. Systemtesting sjekker hele løsningen samlet mot kravene. Akseptansetesting bekrefter til slutt at løsningen fungerer for brukerne og virksomheten.
De tre nivåene svarer på hver sine spørsmål. Snakker delene sammen? Virker løsningen som helhet? Løser den behovet? Hopper du over det første, flytter du bare feilene til de to neste nivåene, der de er dyrere å finne og vanskeligere å spore tilbake.
Ofte stilte spørsmål om integrasjonstesting
Når bør integrasjonstestingen starte?
Så snart to komponenter kan snakke sammen. Venter du til alt er ferdig utviklet, får du alle integrasjonsfeilene samtidig, tett på lansering. Planlegg integrasjonstesting inn i hver leveranse, og bruk stubber eller simulatorer for systemer som ikke er klare.
Hvem har ansvaret for integrasjonstesting når flere leverandører er involvert?
Hver leverandør tester normalt sitt eget ansvarsområde. Helheten må kunden selv eie, i praksis gjennom en testleder med mandat til å teste på tvers av kontraktene. Aspiria tar ofte denne rollen i prosjekter med mange leverandører, og erfaringen er entydig: uten et tydelig eierskap til helheten blir grensesnittene ingens ansvar.
Hva er forskjellen på integrasjonstesting og systemintegrasjonstesting (SIT)?
Integrasjonstesting er samlebegrepet for testing av samspill mellom komponenter, på alle nivåer. Systemintegrasjonstesting, ofte forkortet SIT, er integrasjonstesting på systemnivå: hele systemer testes mot hverandre, for eksempel et fagsystem mot et lønnssystem eller et eksternt register. SIT er altså en form for integrasjonstesting, med større enheter.
Kan integrasjonstesting automatiseres?
Ja, og de kritiske flytene bør automatiseres. Automatiserte integrasjonstester i byggeløpet gir rask tilbakemelding når et grensesnitt endres, og gjør regresjonstesting mulig uten manuelle testrunder. Manuell testing brukes der utforsking gir mer verdi enn repetisjon.
Grensesnittene er prosjektets svakeste punkt
IT-prosjekter knekker sjelden inne i komponentene. De knekker i koblingene mellom dem. To grep utgjør størst forskjell: planlegg integrasjonstestingen like grundig som utviklingen, og gi én rolle mandat og ansvar for å teste på tvers av systemer og leverandører.
Trenger du en testleder som har gjort dette før, i prosjekter med mange systemer og strenge krav? Ta kontakt med oss for en uforpliktende prat.