Testing som skjer for sent, reaktivt og uten plan er en av de vanligste årsakene til at IT-prosjekter ikke leverer det de skal. Studier viser at nesten 30 prosent av IT-prosjektfeil kan spores tilbake til svak kvalitetssikringspraksis. Det er ikke tilfeldige enkeltfeil. Det er tegn på at testarbeidet manglet retning fra starten.
En teststrategi setter rammene for hva som skal testes, hvorfor og med hvilke ressurser. Den gjør testarbeidet til noe prosjektledelsen faktisk kan styre etter, i stedet for noe som skjer på siden av prosjektet.
Denne artikkelen forklarer hva en teststrategi er, hva den bør inneholde, og hvordan du bruker den aktivt gjennom prosjektet, enten du jobber fossefallsbasert eller i smidige sprintsykler.
Hva er en teststrategi?
En teststrategi er et overordnet styringsdokument som beskriver hvordan testing skal bidra til å redusere risiko og sikre kvalitet i et IT-prosjekt. Den tar utgangspunkt i prosjektets mål, rammer og kompleksitet, og gir alle involverte en felles forståelse av hva som skal testes, hvordan det skal testes, og hvem som har ansvar for hva.
Teststrategien definerer hvilke testnivåer som er relevante, hvilke testtyper som skal vektlegges, hvordan risiko håndteres, og hvilke kriterier som avgjør om løsningen er klar for produksjon. Den er ikke en detaljert testplan med enkeltaktiviteter og tidsplaner. Den setter retningen, mens testplanen sikrer gjennomføringen.
En god teststrategi er kortfattet nok til å kommuniseres til styringsgruppen, og konkret nok til å gi testlederen reelt handlingsrom.
Hva bør en teststrategi inneholde?
Innholdet tilpasses alltid prosjektets størrelse og kompleksitet, men noen elementer bør være med i de fleste IT-prosjekter.
Mål for testingen
Teststrategien må svare på hva testingen faktisk skal oppnå. Er hovedmålet å redusere risiko før produksjonssetting? Sikre etterlevelse av krav? Støtte kontinuerlig leveranse i smidige prosjekter? Uten et tydelig mål vet ingen hva de prioriterer mot, og ingen kan vurdere om testarbeidet var godt nok.
Testnivåer og testtyper
Her beskrives hvilke testnivåer som er relevante for prosjektet. I et typisk IT-prosjekt vil det dreie seg om systemtesting, integrasjonstesting og akseptansetesting (UAT). Teststrategien bør også angi hvilke testtyper som vektlegges, som funksjonell testing, ytelsestesting eller sikkerhetstesting, og begrunne prioriteringen opp mot prosjektets risikobilde.
Risikovurdering
En god teststrategi tar utgangspunkt i risiko. Hvilke deler av løsningen er mest kritiske? Hvor vil feil få størst konsekvenser for virksomheten eller brukerne? Svaret på disse spørsmålene styrer både omfang og prioritering av testarbeidet. Les mer om hvordan du identifiserer og håndterer testrelatert risiko i praksis.
Roller, ansvar og eierskap
Teststrategien bør avklare hvem som planlegger, gjennomfører og følger opp testarbeidet. En erfaren testleder eier gjerne strategien operativt, men forankringen må sitte hos prosjektleder og øvrig ledelse, slik at testarbeidet faktisk påvirker prioriteringer og milepælsbeslutninger.
Testmiljøer og testdata
Hvilke miljøer brukes til testing, og hvilke krav stilles til stabilitet, datatilgjengelighet og konfigurasjon? Dette er et felt der vi i Aspiria ser at mange prosjekter undervurderer kompleksiteten. Ustabile testmiljøer og manglende testdata er blant de hyppigste årsakene til forsinkelser i testfasen, særlig i prosjekter med mange integrasjoner mot fagsystemer.
Kvalitetskriterier: hva betyr «klar for produksjon»?
Teststrategien bør definere konkrete kriterier for når testingen anses som tilstrekkelig. Det kan dreie seg om testdekning, feilnivå, gjenstående risiko eller kombinasjoner av disse. Uten tydelige kriterier havner beslutningen om produksjonssetting i en gråsone der ingen vil ta ansvar.
Teststrategi vs. testplan: hva er forskjellen?
Dette er et av de spørsmålene vi oftest får. Kortsvaret: teststrategien gir retning, testplanen sikrer gjennomføring.
Teststrategien er overordnet og relativt stabil gjennom prosjektet. Den beskriver prinsipper, prioriteringer og tilnærming til testing, og endres bare dersom de grunnleggende forutsetningene endrer seg vesentlig. Testplanen er operativ og fasspesifikk. Den beskriver konkrete aktiviteter, tidsplaner, ressurser og leveranser for en gitt fase eller sprint.
I de fleste prosjekter trenger du begge. De erstatter ikke hverandre.
Slik brukes teststrategien aktivt i prosjektet
En teststrategi som legges i en skuff etter oppstart, er ikke verdt papiret den er skrevet på. Vi ser dette mønsteret igjen og igjen – særlig i offentlig sektor, der dokumentasjon lett blir et mål i seg selv fremfor et styringsverktøy.
Det som skiller prosjekter som lykkes fra dem som ikke gjør det, er at teststrategien brukes aktivt i beslutningspunkter. Den definerer grunnlaget for å godkjenne faser, eskalere risiko og justere testomfanget når forutsetningene endrer seg. I prosjekter som moderniseringen av løsninger i offentlig forvaltning er dette avgjørende: mange parter er involvert, integrasjonene er komplekse, og det er ingen rom for å improvisere kvalitetsvurderinger i sluttfasen.
For at teststrategien skal fungere i praksis, må prosjektleder og styringsgruppe eie den, alle prosjektdeltakere kjenne innholdet, og dokumentet ligge tilgjengelig på prosjektets samhandlingskanal. En testleder som sitter alene med strategien, kan ikke gjøre den gjeldende for resten av prosjektet.
Teststrategi i smidige prosjekter
I smidige prosjekter kan en formell strategi oppleves som et unødvendig tungt dokument. Det er forståelig. Men behovet for en overordnet tilnærming til testing er minst like stort i smidig som i fossefallsprosjekter, kanskje større.
I smidige prosjekter bør teststrategien være lettvektsbasert og fleksibel. Den gir føringer for hvordan kvalitet ivaretas løpende gjennom sprintene, hva som automatiseres kontra testes manuelt, og hvordan risiko vurderes fortløpende. Shift-left testing, der testkompetansen involveres tidlig i utviklingssyklusen, er en naturlig konsekvens av en gjennomtenkt teststrategi i smidige løp.
Teststrategien blir da et levende dokument, ikke et statisk arkivdokument. Den oppdateres når løsningen utvikler seg, og brukes aktivt i sprint-planlegging og retrospektiver.
Vanlige feil som gjør teststrategien ubrukelig
Med nesten 30 år i bransjen har vi i Aspiria sett de samme feilene gå igjen. Her er de som skaper størst problem i praksis.
Den vanligste feilen er at teststrategien blir for generell. Hvis den kunne brukes uendret i et hvilket som helst prosjekt, gir den liten verdi i det konkrete prosjektet. En teststrategi som ikke reflekterer prosjektets risikobilde, integrasjoner og kritiske brukerreiser, er ikke en teststrategi, det er en mal.
En annen vanlig feil er manglende forankring. En teststrategi som kun er kjent for testressursene, men ikke for prosjektledelse og fag, vil sjelden påvirke beslutningene som faktisk betyr noe. Eierskap og kommunikasjon rundt teststrategien er lederansvar, ikke noe som kan delegeres til testressursene alene.
Og så er det prosjektene der teststrategien er god på papir, men aldri tas frem igjen etter kickoff. Les mer om feilene som gjøres igjen og igjen i testfasen for å kjenne igjen mønstrene før de rammer ditt prosjekt.
Det er også verdt å merke seg hva som skjer når teststrategien mangler helt: testarbeidet blir reaktivt, fragmentert og avhengig av hvilke testressurser som tilfeldigvis har tid. Det er en høyrisiko-tilnærming i et prosjekt der mye står på spill. Vil du lese mer om grunnlaget for god testledelse? Artikkelen hva bør en leder vite om testledelse gir et godt utgangspunkt.
Vil du ha hjelp til å etablere en teststrategi som faktisk brukes?
En teststrategi gjør testarbeidet målrettet og tilpasset prosjektets faktiske behov. Når den er forankret og brukt aktivt, er den et reelt styringsverktøy, ikke et dokument i prosjektarkivet.
Aspirias testledere har etablert og brukt teststrategier i prosjekter hos virksomheter i bank, offentlig forvaltning og telekom i nesten 30 år. Ta kontakt hvis du vil snakke om hva som vil gi mest verdi i deres prosjekt.