Prosjektet er levert. Systemet er satt i produksjon. Og så begynner meldingene å komme inn.
Spør du prosjektlederen, peker hen mot testleder. Spør du testleder, var testmiljøet ikke klart i tide, og kravene ble aldri tydeliggjort. Spør du utvikleren, er feilen «utenfor scope».
Vi ser dette igjen og igjen. Ikke fordi folk er illojale, men fordi ingen ble enige om hvem som eide hva. Resultatet er en gråsone der alle tar æren for suksessen og ingen vil ha fiaskoen.
Denne artikkelen er en gjennomgang av hva kvalitetssikring faktisk innebærer, hvilke roller som har ansvar for hva, og hva som typisk går galt når det ikke er avklart.
Hva er kvalitetssikring i et IT-prosjekt?
KS er ikke det samme som testing
Testing er en aktivitet: du kjører testcaser, avdekker feil og dokumenterer resultater. Kvalitetssikring er noe bredere. Det er systemet av rutiner, roller og kontrollpunkter som gjør at feil fanges opp tidlig, ikke bare i testfasen.
KS omfatter kravhåndtering, revisjon av leveranser, testplanlegging, risikovurderinger og oppfølging av avvik. Det er et løpende arbeid, ikke en fase på slutten.
Kvalitet må defineres tidlig
Her feiler de fleste prosjekter: de starter uten å bli enige om hva kvalitet betyr akkurat i dette prosjektet.
Er det nullfeil i produksjon? At systemet svarer innenfor avtalte responstider? At sluttbrukerne klarer oppgavene sine uten opplæring? Svaret er ulikt fra prosjekt til prosjekt. Det er prosjektlederen og testlederens felles jobb å avklare dette i starten.
Uten en felles definisjon jobber alle mot hvert sitt mål. Ingen treffer det samme.
Hvem har ansvar for hva?
Prosjektlederen eier betingelsene
Prosjektlederen eier ikke kvaliteten direkte. Men prosjektlederen eier betingelsene for at kvalitet er mulig: tid til testing i planen, testmiljøer som er klare, krav som er dokumentert og forankret, og en eskaleringssti når testleder melder kritiske funn.
En prosjektleder som halverer testperioden fordi prosjektet er forsinket, øker risikoen for at feil havner i produksjon. Det er ikke testlederens feil at perioden ble halvert, men det blir testlederens problem.
Med nesten 30 år i bransjen ser vi at de fleste kvalitetsproblemene i en leveranse har røttene sine i beslutninger tatt lenge før testfasen. Mangelfulle krav, for knapp tidsbuffer, testmiljøer satt opp for sent. Prosjektlederens grep tidlig i prosjektet setter spillereglene for hele KS-arbeidet.
Testlederen eier teststrategien
Testlederen eier teststrategien og gjennomføringen: hva som skal testes, i hvilken rekkefølge, med hvilke testtyper, og hva som er kriteriene for en godkjent leveranse.
Testleder er prosjektets uavhengige stemme på kvalitet. Rollen er å si ifra, også når det er ubehagelig. Når testleder melder at systemet ikke er klart for produksjonssetting, er det prosjektleders ansvar å lytte.
I prosjekter hos kunder i offentlig forvaltning, finans og telekom ser vi at testlederens tidlige involvering er det som gjør størst forskjell. En testleder som er med fra forprosjektfasen kan påvirke kravdokumentasjonen, testmiljøoppsettet og teststrategien. En testleder som kommer inn to uker før go-live kan bare rapportere det hen finner.
Utvikleren er ikke utenfor
Her snubler mange prosjekter: de behandler KS-ansvar som noe som tilhører testleder og prosjektleder, og glemmer utviklerne.
I moderne utvikling: smidig, DevOps eller hybridmodeller forventes det at utviklere skriver enhetstester, gjennomfører kodegjennomganger og leverer kode som faktisk fungerer. «Det er testernes jobb å finne feilene» holder ikke.
Feil funnet i kodegjennomgang koster nesten ingenting å fikse. Funnet i systemtest koster ti ganger mer. Funnet av sluttbrukere i produksjon koster hundre ganger mer. Det er ikke en studie, det er et mønster vi gjenkjenner fra prosjekt etter prosjekt.
Forretningssiden er glemt
Produkteier og forretningssiden er sjelden med i KS-diskusjoner. Det er en feil.
De vet hva systemet skal brukes til, hvilke prosesser som avhenger av det, og hvilke feil som faktisk er kritiske for virksomheten. Uten dem i kravstilling og akseptansetesting risikerer du å levere noe teknisk korrekt som ikke fungerer i praksis.
Akseptansetesting, der reelle sluttbrukere verifiserer at systemet dekker forretningsbehovene er en av de viktigste KS-aktivitetene som finnes. Den kan ikke gjennomføres skikkelig uten at forretningssiden er engasjert og forberedt.
De vanligste misforståelsene
«Testleder skal finne alle feil»
Nei. Testleder avdekker og synliggjør feil. Hen kan ikke garantere at alle er funnet. Fullstendig testdekning er umulig i ethvert reelt system.
Det betyr at prosjektet må ta risikobaserte valg: hvilke feil er kritiske nok til å stoppe leveransen, og hvilke kan leve til neste release? Det er en beslutning for prosjekteier og prosjektleder, ikke testleder alene.
«Vi fikser kvalitet i testfasen»
Testfasen avdekker manglende kvalitet. Den skaper den ikke.
Kvalitet er resultatet av gode krav, god arkitektur, god koding og god prosjektstyring. Når testfasen starter er det for sent å bygge inn kvalitet. Man kan bare måle hva som er der og beslutte om det er godt nok.
«Prosjektlederen har ikke noe med selve kvaliteten å gjøre»
Jo. En plan uten tid til testing, et budsjett uten rom for testmiljø, krav som aldri ble forankret i forretningen. Alt dette er prosjektlederens ansvar. Og alt dette påvirker kvaliteten direkte.
Hva skjer når ansvaret ikke er avklart?
Vi har sett det i saksbehandlingssystemer for offentlig sektor: testleder melder funn, men finner ingen som tar beslutning om hva som utsettes og hva som aksepteres. Prosjektet leverer på dato, systemet havarerer i bruk, og alle mener de gjorde jobben sin.
Vi har sett det i migrasjonsprosjekter i bank: utviklerne mener datavalidering er forretningens ansvar, forretningssiden mener det er IT, og ingen har testet at dataene faktisk er riktige etter migrering.
Fellestrekket er alltid det samme: ingen ble enige om hvem som eide hva.
Finansdepartementets KS2-ordning ekstern kvalitetssikring av statlige investeringsprosjekter over én milliard finnes nettopp fordi uklart ansvar og svak styring er blant de vanligste feilkildene i store prosjekter. For deg som leder et prosjekt uten slike kontrollrammer, er konsekvensen den samme: gråsoner gir forsinkelser, overskridelser og leveranser som ikke holder mål.
Slik avklarer du ansvar tidlig
RACI som startpunkt
RACI (Responsible, Accountable, Consulted, Informed) er et enkelt verktøy: for hver KS-aktivitet definerer du hvem som utfører (R), hvem som har siste-ansvar (A), hvem som konsulteres (C) og hvem som bare informeres (I).
Det tar et par timer i oppstartsfasen og sparer uker av forvirring underveis. En typisk RACI for KS i et IT-prosjekt:
| Aktivitet | Prosjektleder | Testleder | Utvikler | Produkteier |
|---|---|---|---|---|
| Definere kvalitetskrav | A | C | C | R |
| Utarbeide teststrategi | C | R/A | C | I |
| Gjennomføre systemtest | I | A | R | C |
| Godkjenne for produksjon | A | C | I | R |
Forankre ansvaret i teststrategien
Teststrategien er ikke bare testlederens dokument. Den er prosjektets felles avtale om hva som skal testes, hvem som er ansvarlig for hva, og hvilke kriterier som må oppfylles for godkjenning.
Jo tidligere teststrategien lages og forankres med prosjektleder, testleder og produkteier Desto mindre rom er det for ansvarsglidning senere. Se også forskjellen på prosjektleder og testleder og hva testrelatert risiko innebærer for mer om hvordan disse rollene henger sammen i praksis.
Hva er forskjellen på kvalitetssikring og testing?
Testing er en del av kvalitetssikringen. Testing handler om å kjøre konkrete tester: systemtester, akseptansetester, regresjonstester for å avdekke feil. Kvalitetssikring er det bredere systemet av rutiner, roller og kontrollpunkter som sikrer tilstrekkelig kvalitet gjennom hele utviklingsløpet. Du kan ha mye testing og likevel dårlig kvalitetssikring, hvis testingen skjer uten strategi, for sent, eller uten at funnene leder til konkrete beslutninger.
Bør vi ha en dedikert KS-ansvarlig?
I store og komplekse prosjekter: ja. I mindre prosjekter kan testleder ivareta KS-rollen, forutsatt at hen er koblet på tidlig og har mandat til å påvirke krav og testmiljø. Okke bare gjennomføre tester i sluttfasen. Tittelen er ikke det avgjørende. Det avgjørende er at noen faktisk eier ansvaret og har ressursene til å ivareta det.
Noen må eie det
Kvalitetssikring er et felles ansvar. Men felles ansvar uten tydelig rollefordeling er ikke ansvar. Det er en forhåpning.
Prosjektleder setter rammene. Testleder eier teststrategien. Utviklerne svarer for koden de leverer. Forretningssiden definerer hva som er godt nok.
Og noen, gjerne testleder med mandat fra prosjektleder, må ha det samordnende ansvaret for at delene henger sammen.
Hos Aspiria er testlederne koblet på fra første dag, ikke bare i testfasen. Vil du snakke om roller og ansvar i ditt neste prosjekt? Ta kontakt.