De fleste IT-prosjekter består systemtesting. Koden er testet, integrasjonene virker, og utviklingsteamet er fornøyd. Likevel snubler mange prosjekter i siste innspurt, ikke fordi løsningen er dårlig, men fordi akseptansetestingen ble behandlet som en formalitet.
Det koster. Feil som oppdages etter produksjonssetting er langt dyrere å rette enn feil som fanges opp i tide. Og frustrasjonen som følger, hos brukerne, hos ledelsen, hos alle som har brukt måneder på å levere noe som ikke fungerer i praksis, er like reell som regningen.
Akseptansetesting, eller UAT (User Acceptance Testing), er siste stopp før et system går live. Gjort riktig er det et kraftfullt styringsverktøy. Gjort halvveis, eller ikke gjort i det hele tatt, er det en risiko som kan velte selv gode prosjekter.
Her er en praktisk gjennomgang av hva akseptansetesting faktisk er, hvem som eier det, og hvordan du unngår de vanligste fallgruvene.
Hva er akseptansetesting?
Akseptansetesting er en testform der virksomheten selv vurderer om et IT-system er klart til å tas i bruk. Målet er ikke å finne tekniske feil. Det er systemtestingens jobb. Målet er å bekrefte at løsningen støtter faktiske arbeidsprosesser, roller og forretningsbehov.
Det høres enkelt ut. Men det er akkurat her mange prosjekter undervurderer oppgaven.
Akseptansetesting vs. systemtesting: hva er forskjellen?
Forskjellen er perspektivet. Systemtesting har et teknisk perspektiv: fungerer systemet som det skal? Akseptansetesting har et forretningsperspektiv: fungerer systemet for oss?
En løsning kan bestå systemtesting med glans og likevel feile i akseptansetesting. Kanskje er arbeidsflyten tungvint. Kanskje støtter ikke tilgangsstyringen faktisk rolleinndeling. Kanskje er rapportene uleselige for dem som skal bruke dem daglig.
Det er denne typen avvik akseptansetesting er designet for å fange.
Hva testes egentlig i en UAT?
Fokus er på helhet og realistisk bruk, ikke detaljerte tekniske scenarier. I praksis betyr det å sjekke om sentrale forretningsprosesser kan gjennomføres fra start til slutt, om roller og tilganger stemmer med faktisk arbeidsdeling, om brukergrensesnitt og arbeidsflyt er forståelig i hverdagen, om løsningen dekker definerte krav, og om kjente avvik er håndterbare ved oppstart.
Testene bør basere seg på realistiske scenarier, ikke «glade stier» der alt går perfekt. Det er i de vanskelige scenariene at svakhetene viser seg.
Når bør akseptansetesting gjennomføres?
Tidligere enn de fleste tror.
Tradisjonelle prosjekter vs. smidige leveranser
I tradisjonelle prosjekter skjer UAT typisk som en egen fase etter at systemtesting er fullført, men før produksjonssetting. Det gir en tydelig struktur og et klart beslutningspunkt.
I smidige prosjekter er grensene mer flytende. Akseptansetesting kan skje løpende, knyttet til sprint-leveranser, ferdigstillelse av brukerhistorier, eller større releaser. Det krever tettere involvering av produkteier og fagressurser gjennom hele prosjektet.
Uansett metodikk er hensikten den samme: å gi virksomheten et tydelig grunnlag for å godkjenne eller utsette produksjonssetting.
Hva skjer når UAT kommer for sent?
Det er et mønster vi ser gang på gang. Akseptansetestingen skvises inn på slutten fordi prosjektet er forsinket. Tidspress gjør at riktige folk ikke er tilgjengelige. Testingen blir overfladisk. Og plutselig er systemet i produksjon med feil som burde vært fanget opp for måneder siden.
En god teststrategi planlegger akseptansetestingen inn fra starten, ikke som en ettertanke.
Hvem eier akseptansetestingen, og hvorfor det betyr alt
Det viktigste prinsippet i akseptansetesting: ansvaret tilhører virksomheten, ikke leverandøren.
Hvem gjør hva i en UAT?
Akseptansetesting eies normalt av produkteier, fagressurser og nøkkelbrukere. Produkteier har overordnet ansvar for at løsningen dekker forretningsmessige mål. Fagressurser kjenner arbeidsprosessene og vet hva som faktisk må fungere. Nøkkelbrukere representerer dem som skal bruke systemet til daglig.
Testleder, QA og prosjektleder bidrar med planlegging, struktur og oppfølging av funn. Men de eier ikke godkjenningen.
Samspillet mellom prosjektleder og testleder er avgjørende for at denne arbeidsdelingen fungerer i praksis.
Hvorfor leverandøren ikke kan gjøre det for deg
Dette er en av de vanligste misforståelsene vi møter. Leverandøren kan hjelpe til med tilrettelegging, testmiljø og feilretting. Men de kan ikke vurdere om løsningen dekker dine forretningsbehov. Det krever din domenekunnskap.
Når virksomheten tar reelt eierskap til akseptansetestingen, blir også beslutningen om produksjonssetting bedre forankret i organisasjonen.
Hva er de vanligste feilene i akseptansetesting?
«Vi fikk det ikke til å fungere i praksis, selv om systemtesten gikk fint»
Dette er en klassiker. Systemtesten bekrefter at teknologien virker. Akseptansetesten bekrefter at teknologien virker for dere. Disse to tingene er ikke det samme.
Avviket oppstår ofte fordi kravene var for generelle fra starten. Systemet gjør det det ble bedt om, men det som ble bedt om viste seg ikke å dekke det faktiske behovet. Det er ikke et teknisk problem. Det er et kravproblem.
Løsningen er å involvere fagressurser tidlig i kravarbeidet og sikre at akseptkriteria er konkrete og forankret i reelle arbeidsprosesser.
Hva skjer når riktige folk ikke er involvert?
Midt i akseptansetestingen oppdager du at nøkkelbrukerne ikke har vært involvert. Testere uten domeneforståelse kan ikke vurdere om løsningen dekker faktiske behov. Beslutninger tatt uten de rette folkene i rommet er vanskelige å forankre etterpå.
Sørg for at de som faktisk skal bruke systemet er med fra planleggingsfasen. Det tar tid å booke dem inn. Det tar enda mer tid å rydde opp i konsekvensene av at de ikke var der.
Slik planlegger du en god akseptansetest
Forberedelse: krav, testscenarier og testmiljø
En god akseptansetest starter lenge før selve testingen. Du trenger tydelige akseptkriteria, altså hva som skal til for at løsningen kan godkjennes. Du trenger realistiske testscenarier basert på faktisk bruk, testdata som ligner produksjonsdata, og et stabilt testmiljø. Manglende testmiljø er en av de vanligste kildene til forsinkelse, og det er overraskende lett å unngå hvis du planlegger tidlig nok.
Avklar også på forhånd hva som ikke er i scope for UAT. Tydelige grenser gjør det enklere å håndtere funn som dukker opp underveis.
Gjennomføring og funnhåndtering
Loggfør funn strukturert, ikke bare «det fungerer ikke», men hva som skjedde, i hvilket scenario, og hva som var forventet resultat. Det gjør feilretting langt enklere.
Skill mellom feil som er blokkerende og feil som er akseptable å håndtere etter go-live. Ikke alt må være perfekt, men du må ha kontroll på hva som ikke er det.
Godkjenning eller utsettelse: hva er kriteriene?
Resultatet av akseptansetestingen er en beslutning: gå i produksjon, gå i produksjon med forbehold, eller utsett. Den beslutningen bør basere seg på forhåndsdefinerte kriterier, ikke magefølelse i møterommet.
Typiske godkjenningskriterier er at alle kritiske forretningsprosesser kan gjennomføres, at ingen blokkerende feil er åpne, og at kjente avvik er dokumentert, risikovurdert og bevisst akseptert av virksomheten.
Akseptansetesting gir trygghet, når det gjøres riktig
UAT er der du finner ut om systemet ikke bare fungerer, men fungerer for dere. Det er en forretningsmessig vurdering, ikke en teknisk øvelse, og den krever at de rette menneskene er involvert.
Mange av feilene vi ser i akseptansetesting handler ikke om manglende kompetanse. De handler om at testingen kom for sent, at feil folk ble satt til jobben, eller at ingen hadde tatt stilling til hva «godt nok» faktisk betyr. Det er problemer som løses i planleggingsfasen, ikke i testfasen.
Vil du vite mer om hvordan du bygger testing inn i prosjektet fra starten, er vår oversikt over de vanligste feilene i IT-prosjekter et godt sted å begynne. Og hvis du trenger en testleder som kan ta ansvar for hele løpet, fortell oss om prosjektet ditt.