Komplekse IT-prosjekter feiler sjelden på grunn av teknologien alene. Integrasjonene som ikke ble testet godt nok. Testdataene som ikke representerte virkeligheten. Testmiljøet som kom på plass to uker for sent. Dette er de tingene som skaper kriser ved lansering, og alle kan forebygges.
Hva skiller prosjektene som lander trygt fra dem som setter teamet i krisemodus den første produksjonsdagen? Nesten alltid handler det om testledelsen. Ikke om verktøyene, metodikken eller budsjettet. Om testledelsen.
Med nesten 30 år i bransjen og prosjekter i bank, offentlig forvaltning og telekom har vi sett begge deler. Her er praksisene som skiller dem fra hverandre.
Involver testlederen fra kravfasen
Den viktigste enkeltpraksisen i testledelse er denne: testlederen skal inn fra starten, ikke fra testfasen.
Det høres selvsagt ut. Det er det ikke i praksis. I altfor mange prosjekter introduseres testlederen når utviklingen er nesten ferdig, gjerne med ordene «vi skal snart i gang med testing». Da er skaden allerede skjedd. Krav er formulert uten tanke på testbarhet. Integrasjoner er designet uten at noen har tenkt på hva som skal verifiseres. Akseptansekriterier er uklare eller mangler helt.
En testleder som er med fra kravfasen, kan påvirke alt dette. Han eller hun stiller spørsmålene ingen andre stiller: «Hvordan skal vi verifisere at dette kravet er oppfylt?» «Hva skjer hvis dette integrasjonspunktet feiler?» «Finnes testdataene vi trenger for å teste dette scenarioet?»
I offentlig sektor, der dokumentasjonskrav og etterprøvbarhet er lovpålagt, er tidlig involvering nærmest en forutsetning. Prosjekter der testlederen ikke er med fra start, bruker uforholdsmessig mye tid på å rydde opp i konsekvenser som var forutsigbare. Les mer om hva god testledelse innebærer i praksis og hva rollen faktisk dekker gjennom et prosjektløp.
Bygg teststrategien rundt risiko
En vanlig feil er å behandle testing som en sjekkliste: test alt, og kryss av etter hvert. Det er verken mulig eller klokt. Tid er alltid begrenset. Det gjelder å teste det som betyr mest, med den kapasiteten som finnes.
Risikobasert testing er svaret. Det innebærer å identifisere hvilke deler av løsningen som har høyest sannsynlighet for feil og høyest konsekvens ved feil, og prioritere testarbeidet deretter. Et betalingsmodul i et finanssystem testes mer grundig enn en visningsside med statisk innhold. En integrasjon mot et eksternt system med historikk for ustabilitet testes tidligere og tettere enn en intern funksjon med lavt bruksvolum.
Denne prioriteringen gjøres ikke intuitivt. Den krever en gjennomtenkt teststrategi som er forankret i prosjektets risikovurdering. Teststrategien er ikke et dokument som skrives en gang og glemmes. Den oppdateres når risikobildet endrer seg, og det gjør det alltid. Du finner en praktisk guide til testrelatert risiko og hvordan du håndterer det i vår gjennomgang av risikostyring i testfasen.
Sørg for testmiljøer og testdata i tide
Spør en testleder hva som skaper mest friksjon i prosjekter, og svaret er nesten alltid det samme: testmiljøer som ikke er klare, og testdata som ikke finnes eller ikke representerer virkeligheten.
Dette er ikke tekniske problemer. Det er planleggingsproblemer. Testmiljøer og testdata må være en del av prosjektplanen fra dag én, ikke noe som ordnes når testfasen nærmer seg. Når de ikke er klare til rett tid, stopper testarbeidet opp. Forsinkelsen vokser. Presset for å korte ned testperioden øker. Og kvaliteten lider.
Konkrete tiltak: Definer testmiljøkrav parallelt med teknisk arkitektur. Planlegg testdata som en egen leveranse med eier og frist. Verifiser at miljøene fungerer som forventet lenge før testperioden starter. Gjør dette systematisk, og du fjerner en av de vanligste årsaksgrunnene til forsinkelser i testfasen.
Test gjennom hele løpet
Tradisjonell tankegang plasserer testing på slutten av prosjektet. Utvikle, så test. Det fungerer dårlig i de fleste moderne prosjekter, og særlig i komplekse løp med mange integrasjoner og avhengigheter.
I praksis betyr det at testlederen planlegger og koordinerer testing gjennom alle faser. Enhetstesting og integrasjonstesting skjer parallelt med utvikling. Regresjonstesting sikrer at nye endringer ikke bryter det som allerede fungerer. Systemtesting og akseptansetesting, UAT, kommer mot slutten, men uten at de er den eneste testaktiviteten som har skjedd.
I smidig utvikling stiller dette enda høyere krav til testlederen. Testing er ikke en separat fase, det er en kontinuerlig aktivitet i hver sprint. Testlederen må sikre at testdekningen er god nok, at regresjon fanges opp raskt og at testarbeidet ikke blir et etterslep som stable opp sprint etter sprint.
Rapporter på en måte ledelsen forstår
En teknisk testrapport med feillogger, testcase-ID-er og dekningsprosenter er nyttig for testteamet. Den er ubrukelig for styringsgruppen.
God testledelse innebærer å oversette testresultater til ledelsesinformasjon: hva fungerer, hva gjenstår, hva er risikoen ved å gå videre og hva anbefales. Tre linjer som gir beslutningstakeren det de trenger, er mer verdifullt enn tjue sider ingen leser.
Rapporten bør alltid inneholde tre elementer: status per i dag, risiko knyttet til det som gjenstår og en tydelig anbefaling om veien videre. Ledelsen trenger et faktabasert grunnlag for å ta beslutninger, ikke en statusoppdatering som krever tolkning.
Sett klare kriterier for «klar til lansering»
Beslutningen om å gå i produksjon er en av de viktigste i hele prosjektet. Den bør ikke baseres på magefølelse, tidspress eller leverandørens forsikringer. Den bør baseres på forhåndsdefinerte exit-kriterier.
Exit-kriterier er konkrete, målbare betingelser som må være oppfylt for at prosjektet er klart for lansering. Eksempler: ingen kritiske feil åpne, akseptansekriterer godkjent av forretningssiden, ytelsestest gjennomført uten avvik mot krav, all dokumentasjon på plass. Disse kriteriene defineres tidlig i prosjektet, ikke rett før lanseringen.
Med klare exit-kriterier unngår man situasjonen der «klar» blir en forhandling mellom tidspress og kvalitet. Enten er kriteriene oppfylt, eller de er ikke det. Hvis de ikke er det, er løsningen ikke klar, uavhengig av hva planen sa.
Vanlige feil som ødelegger testarbeidet
I prosjekter vi har fulgt over nesten 30 år ser vi de samme feilene igjen og igjen.
Testing komprimeres når prosjektet er forsinket. Det er den klassiske feilen. Utviklingen tar lengre tid enn planlagt, og da kuttes testperioden for å holde lanseringsdatoen. Resultatet er en lansering med kjente feil og et team som tilbringer de første ukene med å rydde opp i produksjonen.
Testdata er ikke representativt. Testene kjøres med syntetiske data som ikke gjenspeiler reell bruk. Alt ser bra ut i test. I produksjon, med ekte brukerdata og reelle volumer, dukker problemene opp.
Testlederen mangler uavhengighet. En testleder som rapporterer til prosjektlederen og er under press for å si at alt er klart, er ikke i stand til å gi en ærlig vurdering. Testlederen trenger en uavhengig posisjon som gjør det mulig å si fra når kvaliteten ikke er god nok.
Akseptansetestingen gjøres av feil folk. UAT gjennomføres av IT-avdelingen fremfor av de faktiske sluttbrukerne. Resultatet er at systemet er teknisk godkjent, men ikke funksjonelt tilpasset den faktiske arbeidshverdagen. Les mer om hva ledere bør vite om testledelse for å forstå hvordan du som beslutningstaker kan bidra til å unngå disse feilene.
Ofte stilte spørsmål om beste praksis i testledelse
Hva er beste praksis for testledelse i smidig utvikling?
I smidig utvikling integreres testarbeidet i hver sprint fremfor å samles i en separat testfase på slutten. Testlederen planlegger testaktiviteter per sprint, sikrer tilstrekkelig regresjonstesting og koordinerer akseptansetesting løpende med forretningssiden. Exit-kriterier settes per sprint og for den samlede løsningen.
Hvor tidlig bør testlederen involveres?
Fra kravfasen. En testleder som involveres tidlig, kan sikre at krav er testbare, at akseptansekriterier er definert og at testmiljøer og testdata planlegges som en del av prosjektleveransen. Jo tidligere testlederen er med, jo færre overraskelser oppstår i selve testfasen.
Hva bør en teststrategi inneholde?
En god teststrategi beskriver testnivåer og testtyper, risikovurdering og prioritering av testarbeid, krav til testmiljøer og testdata, ansvar og roller i testarbeidet, rapporteringsformat og hyppighet, og exit-kriterier for aksept og lansering.
Hva er exit-kriterier i testing?
Exit-kriterier er forhåndsdefinerte, målbare betingelser som må være oppfylt for at løsningen godkjennes for lansering. Typiske exit-kriterier inkluderer: ingen åpne kritiske feil, alle akseptansekriterier godkjent, ytelsestester gjennomført innenfor krav og testdekning over et definert minimumsnivå.
Hva skiller en god testleder fra en gjennomsnittlig?
En god testleder er proaktiv fremfor reaktiv. De finner risikoen før den blir et problem, kommuniserer tydelig til både teknisk team og ledelse, og tar ansvar for helheten i kvalitetsarbeidet. De vet hva som skal testes mest og hva som kan testes mindre, og de har ryggrad til å si fra når løsningen ikke er klar for lansering.
Testledelse er et håndverk
God testledelse er ikke et sett med regler som følges mekanisk. Det er et håndverk som kombinerer metodisk planlegging, god kommunikasjon og erfaringsbasert dømmekraft.
De praksisene som er beskrevet her er ikke teori. De er observasjoner fra prosjekter som har lyktes og prosjekter som ikke har gjort det. Forskjellen mellom dem er nesten alltid spørsmål om de ble fulgt eller ikke.
Vil du snakke om hva riktig testledelse kan bety for ditt neste prosjekt? Ta kontakt med oss for en uforpliktende prat.