·Audun Martinussen

Testing og UAT ved ERP-innføring: en sjekkliste som faktisk fanger feil

De fleste UAT-runder tester «happy path» og går glipp av nettopp det som feiler i drift: unntakene. Her er hvordan du strukturerer brukertesting rundt prosesskartet, så dere går live på et system som er testet på det som er vanskelig.

UAT — User Acceptance Testing — er den siste sjekken før et nytt ERP går live. I teorien er det her dere bekrefter at systemet støtter forretningen. I praksis blir UAT ofte en hake-i-boks: noen klikker gjennom de enkle tilfellene, alt ser greit ut, og dere går live. Så feiler systemet på det første unntaket i ekte drift.

Hvorfor de fleste UAT-runder bommer

  1. Bare happy path testes. De enkle, vanlige tilfellene fungerer alltid. Det er unntakene — kreditnota, delleveranse, avvik over toleranse, utenlandsk leverandør — som feiler.
  2. Ingen kobling til faktiske prosesser. Uten et prosesskart vet ingen hvilke scenarioer som burde testes. Testingen blir tilfeldig.
  3. Feil personer tester. De som tester er ofte prosjektdeltakere, ikke de som faktisk gjør jobben daglig og kjenner unntakene.
  4. Ingen sporing av kontroller. UAT verifiserer at en faktura kan registreres — ikke at godkjenningsgrensen faktisk stopper en for høy.

Bruk prosesskartet som testgrunnlag

Et BPMN-prosesskart er en ferdig testplan. Hver gateway (beslutningspunkt) er et testscenario: hva skjer ved «ja» og ved «nei»? Hvert unntak i kartet er en test-case. Hvis as-is-mappingen fanget de 3–5 spesialtilfellene per syklus, har du nettopp listen over det UAT må dekke.

Sjekkliste for ERP-UAT

  1. Dekk hver gateway begge veier. For hvert beslutningspunkt: test både utfallene.
  2. Test unntakene eksplisitt. Kreditnota, delleveranse, retur, avvik over toleranse, manglende dokumentasjon, utenlandsk valuta.
  3. Test kontrollene ved å forsøke å bryte dem. Prøv å godkjenne over grensen. Prøv å la samme person opprette og attestere. Kontrollen skal stoppe deg.
  4. La de som gjør jobben teste. Den som registrerer fakturaer daglig finner feil en prosjektleder aldri ser.
  5. Test integrasjoner ende-til-ende. Ikke bare at data går ut, men at det kommer korrekt frem og kan avstemmes.
  6. Logg og prioriter funn. Skill mellom blokkerende feil (må fikses før go-live) og forbedringer (kan vente).

Definér go-live-kriterier på forhånd

Bestem før UAT hva som må stemme for å gå live. «Alle blokkerende test-case grønne, alle kontroller verifisert, integrasjoner avstemt.» Uten definerte kriterier blir go-live en magefølelse under tidspress — og da går man live på et halvtestet system.

Koblingen til kontrollmiljøet

UAT er din siste sjanse til å bekrefte at kontrollene overlevde systembyttet. Test derfor ikke bare at prosessen kan gjennomføres, men at den ikke kan gjennomføres feil. En godkjenningsgrense som ikke ble konfigurert, oppdages her — eller i revisjonen, som er en mye dyrere måte å finne det på.

Oppsummering

God UAT handler om å teste det som er vanskelig, ikke det som er lett. Bruk prosesskartet til å finne hver gateway og hvert unntak, la de som gjør jobben teste, forsøk aktivt å bryte kontrollene, og definér go-live-kriteriene på forhånd. Da går dere live på et system som er testet på virkeligheten — ikke bare på happy path.

Vil du se hvordan vi dokumenterer prosesser i praksis?

Et komplett eksempel — innkjøp-til-betaling for en 80-personers grossist — er publisert med BPMN, kontroller og risikoer.