Prosjektet har testet mye. Utviklerne har kjørt sine tester, testteamet har jobbet i ukevis, og alle rapporter er grønne. Så går løsningen i produksjon, og innen første ettermiddag ligger det feilmeldinger i innboksen.
Det er sjelden for lite testing som er problemet. Det er feil testing på feil nivå.
Vi har levert testledelse i norske IT-prosjekter i snart 30 år, i bank, offentlig forvaltning og telekom. Mønsteret går igjen: prosjekter tester grundig der det er lett å teste, og hopper over der det er vanskelig. Enhetstestene er på plass fordi utviklerne eier dem. Integrasjonstestingen glipper fordi ingen eier grensesnittene mellom leverandørene.
Her er hele kartet på én side. Først skillet mellom testnivå og testtype, som er der de fleste planer slår sprekker. Så de fire nivåene, med hvem som eier hva. Deretter testtypene du må ta stilling til. Og til slutt tre spørsmål som avgjør hvor mye testing prosjektet ditt egentlig trenger.
Hva er forskjellen på testnivå og testtype?
Testnivå handler om når i utviklingsløpet du tester. Testtype handler om hva du tester for. Det er to uavhengige akser, og de fleste testtyper kan brukes på flere nivåer. Aspiria bruker skillet som utgangspunkt når vi setter opp testledelse i et prosjekt, fordi det er her de fleste planer slår sprekker.
Et eksempel gjør det konkret. Ytelsestesting er en testtype. Den kan gjennomføres på systemnivå, der du måler hvordan hele løsningen oppfører seg under last, men også på integrasjonsnivå, der du måler hvor lang tid et API bruker på å svare. Samme testtype, to ulike nivåer, to helt ulike funn.
ISTQB definerer testnivåer som grupper av testaktiviteter som organiseres og styres samlet, og testtyper som grupper av aktiviteter rettet mot bestemte kvalitetsegenskaper. Skillet er også utgangspunktet i det norske pensumet for ISTQB Sertifisert Tester på grunnivå, som er den vanligste sertifiseringen blant testledere i Norge.
Hvorfor forvirringen koster penger i planleggingen
Når nivå og type blandes sammen, blir testplanen full av hull ingen oppdager før det er for sent.
Vi ser det typisk slik: planen sier «systemtest, fire uker». Ingen har spesifisert hvilke testtyper som inngår. Teamet tester funksjonalitet, fordi det er det man gjør, og sikkerhet og ytelse faller mellom stolene. Begge deler oppdages i produksjon.
Motsatt feil er like vanlig. Planen sier «ytelsestesting», men ikke på hvilket nivå. Resultatet blir en måling helt til slutt, når arkitekturen er låst og funnene ikke lenger kan rettes uten å bygge om.
De fire testnivåene
De fire nivåene bygger på hverandre. Hvert nivå har sitt eget formål, sin egen eier og sitt eget tidspunkt.
| Nivå | Hva testes | Hvem eier det | Når |
|---|---|---|---|
| Enhetstesting | Én komponent isolert | Utviklerne | Løpende under utvikling |
| Integrasjonstesting | Samspillet mellom komponenter | Utviklings- og testteam | Etter hvert som integrasjoner er klare |
| Systemtesting | Hele løsningen samlet | Testleder og testteam | Når løsningen er funksjonelt komplett |
| Akseptansetesting | Om løsningen dekker forretningsbehovet | Virksomheten selv | Før produksjonssetting |
Enhetstesting
Enhetstesting, også kalt komponenttesting, verifiserer at én enkelt kodeenhet gjør det den skal, isolert fra resten. Utviklerne skriver og eier disse testene, og de kjøres automatisk hver gang koden endres.
Som prosjektleder trenger du ikke lese enhetstester. Men du bør vite om de finnes. Et prosjekt uten enhetstester får alle feilene sine senere, der de koster mer.
Spør leverandøren om testdekningen, og be om et tall. Får du et vagt svar, er det som regel fordi tallet er lavt.
Integrasjonstesting
Integrasjonstesting verifiserer at komponenter og systemer fungerer sammen. Det er her data flyter mellom fagsystem, integrasjonsplattform og tredjepart, og det er her de dyreste feilene bor.
Dette nivået svikter oftest av organisatoriske grunner, ikke tekniske. Leverandør A eier fagsystemet, leverandør B eier integrasjonsplattformen, og feilen ligger et sted midt imellom. Da blir spørsmålet om hvem som skal teste koblingen hengende i lufta.
Systemtesting
Systemtesting tester hele løsningen samlet, i et miljø som ligner produksjon. Perspektivet er teknisk: fungerer systemet slik det er spesifisert?
Her kommer de fleste testtypene inn. Funksjonalitet, ytelse, sikkerhet og brukervennlighet testes normalt på dette nivået.
Akseptansetesting
Akseptansetesting, eller UAT, er der virksomheten selv bekrefter at løsningen støtter faktiske arbeidsprosesser. Perspektivet er forretningsmessig, ikke teknisk.
Dette nivået kan ikke settes bort. Leverandøren kan tilrettelegge, men bare dere kan vurdere om løsningen dekker behovet deres. Det krever domenekunnskap som ingen ekstern part har.
Sett av tid til akseptansetestingen fra starten, og book fagressursene like tidlig som du booker testmiljøet. Den vanligste feilen er å skvise inn UAT på slutten fordi prosjektet er forsinket.
Testtypene du må ta stilling til
Nivåene sier når du tester. Testtypene sier hva du ser etter. Aspiria anbefaler at valget av testtyper gjøres i teststrategien, ikke underveis, fordi det er den eneste måten å oppdage hullene mens de fortsatt er billige å tette.
Funksjonell testing
Funksjonell testing sjekker om systemet gjør det det skal. Kan saksbehandleren registrere en sak? Blir fakturaen sendt? Havner beløpet på riktig konto?
Dette er testtypen alle husker, og den som får mest tid i planen.
Ikke-funksjonell testing
Ikke-funksjonell testing sjekker hvordan systemet oppfører seg, ikke hva det gjør. Ytelse, kapasitet, sikkerhet, tilgjengelighet og brukervennlighet hører hjemme her. Forskjellen på funksjonell og ikke-funksjonell testing er verdt å ha klar før du setter opp planen.
Det er i denne kategorien de fleste prosjekter har hull. Belastnings- og ytelsestesting er det tydeligste eksemplet: alle er enige om at det bør gjøres, få har satt av tid til det.
Regresjonstesting
Regresjonstesting verifiserer at det som fungerte i går, fortsatt fungerer i dag. Den er ikke knyttet til ett nivå, men kjøres på tvers, hver gang noe endres.
I lange prosjekter vokser regresjonstestingen jevnt og trutt. Uten automatisering blir den til slutt så tung at teamet begynner å hoppe over den. Det er akkurat da feilene kommer tilbake.
Hvilke testtyper trenger prosjektet ditt?
Ikke alt skal testes like grundig. Målet er ikke maksimal testdekning, men riktig dekning der risikoen er størst.
Tre spørsmål som avgjør omfanget
Hva skjer hvis dette feiler i produksjon? Et internt rapportverktøy som ligger nede en time er irriterende. Et betalingssystem som ligger nede en time er noe helt annet. Konsekvensen styrer innsatsen.
Hvor mange grensesnitt har løsningen? Jo flere systemer som skal snakke sammen, jo mer vekt på integrasjonstesting. Dette er det spørsmålet flest prosjekter svarer for lett på.
Hva er endret siden sist? Ny funksjonalitet krever funksjonell testing. Ny arkitektur eller nye volumer krever ytelsestesting. Endret tilgangsstyring krever sikkerhetstesting. Endringens karakter bestemmer testtypen, ikke størrelsen på endringen.
Svarene hører hjemme i teststrategien. Det er der du dokumenterer hvilke testtyper som gjelder, på hvilke nivåer, og hvem som eier hva. Uten den avklaringen blir testomfanget bestemt av hvem som har tid, ikke av hvor risikoen ligger.
Ofte stilte spørsmål om testtyper
Hvor mange testtyper finnes det?
Det finnes ingen fasit. ISTQB opererer med hovedkategoriene funksjonell, ikke-funksjonell, strukturell og endringsrelatert testing, og under dem finnes det dusinvis av navngitte varianter. For de fleste IT-prosjekter er det viktigere å velge riktige testtyper enn å kjenne alle.
Er testnivå og testfase det samme?
Nesten, men ikke helt. Testnivå beskriver hva som testes og med hvilket perspektiv. Testfase beskriver en periode i prosjektplanen. I tradisjonelle prosjekter faller de ofte sammen. I smidige prosjekter gjør de det ikke, fordi flere nivåer kjøres parallelt gjennom hver sprint.
Må alle fire testnivåene gjennomføres?
I praksis ja, men omfanget varierer kraftig. Et lite internt verktøy klarer seg med lette tester på hvert nivå. Et saksbehandlingssystem i offentlig sektor med krav til revisjonsspor gjør det ikke.
Hvem bestemmer hvilke testtyper som skal brukes?
Testlederen foreslår, prosjektet beslutter. Valget bør bygge på en risikovurdering og forankres i teststrategien, slik at det er dokumentert hva som er testet og hva som bevisst er valgt bort.
Riktig testing er billigere enn mye testing
Testnivåene sier når du tester. Testtypene sier hva du ser etter. Får du de to aksene på plass tidlig, ser du hullene i planen mens de fortsatt kan tettes uten å koste tid.
De to feilene vi ser oftest er begge planleggingsfeil. Prosjekter tester grundig der det er lett, og hopper over integrasjonene der det er vanskelig. Og de setter av tid til funksjonell testing, men ikke til ytelse og sikkerhet, som begge oppdages først i produksjon.
Begge kan unngås med en teststrategi som tar stilling til nivå og testtype før testløpet starter.
Trenger dere hjelp til å sette opp testløpet, eller til å vurdere om dagens plan har hull? Ta kontakt for en uforpliktende prat med en av våre testledere. Du kan også lese mer om hvordan vi jobber med testledelse i IT-prosjekter.