Test og ibrugtagning

Brugeraccepttest: bevis at appen passer til arbejdet

En app kan have grønne automatiske tests og stadig være forkert for dem, der skal bruge den. En brugeraccepttest – ofte kaldet UAT – lader forretningsbrugere gennemføre de virkelige arbejdsopgaver med de rigtige roller og tydelige forventninger. Resultatet er ikke bare feedback, men et dokumenteret grundlag for at godkende, rette eller udskyde.

Udgivet 3. november 2026 · Ca. 10 minutters læsetid

Det korte svar

Vælg de vigtigste forretningsforløb, skriv et konkret forventet resultat for hvert, og lad repræsentative medarbejdere udføre dem i et sikkert miljø, der ligner drift. Test med deres normale roller og realistiske, men forsvarlige data. Registrér resultat og bevis pr. scenarie, giv hvert problem en ejer, og aftal på forhånd hvilke fejl der stopper ibrugtagning. Den forretningsansvarlige træffer derefter en tydelig go/no-go-beslutning.

UAT er ikke almindelig klik-rundt-test. Den kontrollerer, om appen understøtter de aftalte arbejdsprocesser og behov. Tekniske tests skal allerede have fjernet de oplagte kode- og integrationsfejl.

Skeln mellem teknisk test, UAT og pilotdrift

De tre aktiviteter svarer på forskellige spørgsmål og kan ikke erstatte hinanden. Microsoft beskriver UAT som forretningsbrugeres kontrol af, om leverancen opfylder deres behov, mens den bredere teststrategi også omfatter blandt andet unit-, integrations-, system-, performance- og regressionstest.

Aktivitet	Spørgsmål	Typisk ansvar
Teknisk test	Virker kode, adgang, integrationer og fejlscenarier som specificeret?	Udviklere og testansvarlige
Brugeraccepttest	Kan brugerne udføre de aftalte arbejdsprocesser sikkert og korrekt?	Forretningsbrugere og procesejer
Pilotdrift	Hvad lærer vi af afgrænset, virkelig brug og drift over tid?	Pilotbrugere, produktejer og drift/support

UAT bør ikke være første gang, nogen opdager at login fejler eller data forsvinder. Hvis testen finder mange grundlæggende fejl, skal løsningen tilbage til teknisk test, før forretningsbrugernes tid bruges på en ny acceptkørsel.

Skriv acceptkriterier i arbejdets sprog

Et scenarie skal beskrive en opgave og et observerbart resultat – ikke hvilken knap udvikleren byggede. Knyt scenariet til en aftalt arbejdsgang, regel eller risiko, så det er tydeligt, hvorfor det er med, og hvem der kan acceptere resultatet.

Eksempel: godkend en timeseddel

Situation: En teamleder skal godkende en medarbejders registrering på en åben sag.
Forudsætninger: Teamlederen er logget ind med sin normale rolle, og der findes både en gyldig og en allerede lukket sag.
Handling: Kontrollér registreringen, ret en kommentar og godkend den gyldige post.
Forventet resultat: Status, godkender og tidspunkt gemmes én gang og kan ses efter genindlæsning.
Vigtig afvisning: Den lukkede sag og en anden afdelings post kan ikke godkendes.
Bevis: Testresultat, appreference og skærmbillede uden unødvendige persondata.

Skriv både normal vej og relevante kanttilfælde. Microsoft anbefaler ved go-live at teste krav i scope, både forventede forløb og edge-scenarier, med korrekte sikkerhedsroller. Det betyder ikke, at alle tænkelige variationer skal ind i UAT; vælg dem, der kan ændre beslutningen om sikker ibrugtagning.

Brug mennesker, der kender den virkelige proces

Byggeren kan demonstrere appen, men bør ikke alene godkende sin egen fortolkning. Vælg personer, der udfører eller ejer de relevante opgaver, og gør deres ansvar tydeligt.

Procesejer: Afgør om arbejdsgangen og reglerne opfylder det aftalte behov.
Repræsentativ bruger: Udfører opgaven som i hverdagen og opdager manglende information, uklare begreber og farlige genveje.
Testkoordinator: Holder styr på version, miljø, scenarier, resultater og genkørsel.
Teknisk ansvarlig: Hjælper med miljø og fejlbeviser uden at styre brugeren gennem hvert klik.
Go/no-go-ejer: Har mandat til at acceptere kendte begrænsninger eller stoppe ibrugtagningen.

En demonstration er ikke en accepttest. Hvis byggeren fører musen og forklarer alle genveje, viser testen mest, at byggeren kender appen. Lad brugeren læse scenariet og løse opgaven med den hjælp, der også vil være tilgængelig efter ibrugtagning.

Gør miljø, version, roller og data tydelige

Et resultat kan kun bruges som beslutningsgrundlag, hvis man ved, hvad der blev testet. Fastlås en releasekandidat eller anden entydig version, og undgå ændringer midt i en kørsel uden at registrere dem. Miljøet skal ligne drift på de forhold, scenarierne afhænger af.

Rigtige roller: Test ikke alle som administrator. Brug de samme rettighedstyper som medarbejdere og kunder skal have.
Realistiske relationer: Medtag eksempelvis kunde, sag, ordrelinjer og historik, hvis arbejdsgangen kræver dem.
Sikre testdata: Brug som udgangspunkt syntetiske data. Produktionskopier kræver et dokumenteret behov og passende beskyttelse.
Integrationer: Angiv om mail, betaling, regnskab eller andre tjenester er ægte testvarianter, kontrollerede erstatninger eller ude af scope.
Kendt nulstilling: Beskriv hvordan scenariet kan genkøres uden gamle resultater, dubletter eller sideeffekter.

Microsoft anbefaler et UAT-miljø, der tilnærmer sig produktion, og realistiske data. Det er ikke en opfordring til ukritisk at kopiere persondata til et mindre beskyttet miljø. Realismen skal komme fra relevante strukturer, mængder, roller og afhængigheder.

Registrér resultatet, så det kan genkøres

Et fælles ark eller issue-system er nok til en lille app, hvis felterne er faste. Hvert scenarie skal kunne forbindes med den testede version og den konkrete observation.

Identitet: Scenarie-id, krav eller proces, version, miljø, dato og testerrolle.
Resultat: Bestået, fejlet, blokeret eller ikke relevant – med en kort faktisk observation.
Bevis: Appreference, tidspunkt, logreference eller et redigeret skærmbillede. Undgå passwords, nøgler og unødvendige persondata.
Opfølgning: Problem-id, alvor, ejer, beslutning og dato for rettelse eller accepteret begrænsning.
Genkørsel: Ny version, tester og resultat, så en rettelse ikke lukkes alene på udviklerens besked.

Adskil fejl, ændringsønsker og nye idéer

UAT mister retning, hvis enhver præference bliver en blocker. Sammenhold observationen med det aftalte acceptkriterium og den reelle forretningsrisiko.

Fejl: Appen opfylder ikke et aftalt kriterium, mister data, giver forkert resultat eller tillader en handling, der skulle afvises.
Blokering: Testeren kan ikke gennemføre scenariet på grund af miljø, adgang eller en anden fejl. Scenariet er ikke bestået.
Ændringsønske: Behovet er forståeligt, men lå uden for det aftalte resultat. Det prioriteres særskilt.
Kendt begrænsning: Et konkret forhold accepteres af en navngiven ansvarlig med konsekvens, midlertidig arbejdsgang og opfølgningsdato.

Giv alle fund en ejer og en frist. Microsoft fremhæver netop ansvar og slutdato for punkter fundet under UAT; en lang liste uden beslutning skaber ikke mere sikker drift.

Aftal go/no-go før resultaterne kommer

Definér på forhånd hvilke resultater der skal være opfyldt, og hvilke fund der stopper ibrugtagning. Ellers bliver beslutningen let styret af deadline eller stemning.

Alle kritiske scenarier er gennemført på den aftalte releasekandidat.
Ingen åben fejl kan give uautoriseret adgang, forkert væsentlig beslutning eller ukontrolleret datatab.
Blokerede scenarier er afklaret; de tæller ikke som bestået.
Kendte begrænsninger har ejer, konsekvens, brugerbesked og en forsvarlig midlertidig arbejdsgang.
Support, overvågning, rollback og relevante brugeroplysninger er klar til den valgte ibrugtagning.
Den forretningsansvarlige har godkendt resultatet skriftligt for den konkrete version og det konkrete scope.

Godkendelse betyder ikke fejlfri software. Microsoft beskriver sign-off som en beslutning om, at løsningen er tilstrækkelig til at drive forretningen sikkert og effektivt – med mindre problemer eller forbedringer håndteret senere.

Typiske fejl i en brugeraccepttest

Testen starter uden acceptkriterier: Resultatet bliver meninger og nye idéer frem for en beslutning om det aftalte behov.
Byggeren er eneste tester: De samme antagelser ligger i både app, test og godkendelse.
Alle tester som administrator: Appen ser færdig ud, men normale brugere mangler adgang – eller har for meget.
Produktionsdata kopieres ukritisk: Testmiljøet skaber unødvendig persondata- og adgangsrisiko.
Versionen ændres undervejs: Ingen kan bagefter sige, hvilken releasekandidat der faktisk blev accepteret.
Et skærmbillede er eneste bevis: Det viser ikke nødvendigvis, at den rigtige post blev gemt, eller at adgangen var korrekt.
Blokeret markeres som bestået: Et scenarie, der ikke kunne gennemføres, bliver fejlagtigt brugt som sikkerhed.
Sign-off er bare “ser fint ud”: Scope, version, åbne fund og beslutning kan ikke rekonstrueres.

Tjekliste til brugeraccepttest

☐ De vigtigste forretningsprocesser og risici i scope er navngivet.
☐ Hvert scenarie har forudsætninger, handling, forventet resultat og relevant afvisning.
☐ Procesejer, repræsentative brugere, testkoordinator og go/no-go-ejer er udpeget.
☐ Releasekandidat, miljø og integrationsgrænser er entydigt dokumenteret.
☐ Testerne bruger de roller og rettigheder, de skal have i den virkelige drift.
☐ Testdata har realistiske relationer uden unødvendige kopier af persondata.
☐ Resultater registreres som bestået, fejlet, blokeret eller ikke relevant med bevis.
☐ Fejl, ændringsønsker og kendte begrænsninger holdes adskilt.
☐ Hvert åbent fund har alvor, ejer, beslutning og opfølgningsdato.
☐ Rettelser genkøres på en ny entydig version.
☐ Stopkriterier og krav til godkendelse er aftalt før den endelige beslutning.
☐ Sign-off angiver version, scope, resultater, åbne begrænsninger og ansvarlig.

Officielle kilder

Guiden bygger på officiel vejledning om brugeraccepttest, testplaner, roller, realistiske miljøer, resultatsporing og forretningsgodkendelse. Omfang og acceptkriterier skal tilpasses appens faktiske processer, data, risici og branchekrav.

Når appen virker, men godkendelsen stadig mangler

I Startklar forbinder vi appens vigtigste arbejdsprocesser med konkrete acceptscenarier, korrekte roller, sikre testdata og et dokumenteret beslutningsgrundlag. Det gør det tydeligt, hvad der er klar til brug, hvad der skal rettes, og hvem der godkender resultatet.

Se Startklar-forløbet