Hvad UAT i Business Central egentlig skal bevise
UAT (User Acceptance Test) i Business Central er det sted, hvor et projekt enten bliver forankret hos brugerne eller mister fart. Ikke fordi løsningen nødvendigvis er “forkert”, men fordi mange UAT-forløb mangler en skarp testplan, realistiske testdata og en enkel måde at registrere afvigelser på.
Hvis du står med en implementering, en opgradering fra NAV eller en modernisering af en ældre Business Central-løsning, kan en god UAT-testplan fungere som jeres fælles kontrakt: Hvad tester vi, hvornår tester vi, hvem godkender, og hvad er “godt nok” til go-live?
UAT er ikke en teknisk test, hvor man prøver at “knække systemet”. UAT skal vise, at forretningen kan løse sine kerneopgaver i den nye løsning, med de rigtige rettigheder, data og arbejdsgange.
Det betyder, at en UAT-testplan typisk bør dække:
- End-to-end flows (ordre til faktura, indkøb til betaling, lager til regulering)
- Rapporter og udskrifter (fakturaer, kreditnotaer, rykkere, moms)
- Integrationer (bank, EDI, webshop, lagerstyring, dokumenthåndtering)
- Tilretninger og apps (extensions) der påvirker arbejdsgange
- Kontroller og compliance (godkendelsesflows, audit trail, sporbarhed)
Microsoft har en god, generel guide til teststrategi og planlægning, som også kan bruges som reference for UAT-strukturen:
https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/testing-strategy-planning
Scope, mål og “hvad der ikke testes”
Mange UAT-planer bliver for brede. Når alt skal testes, ender intet med at blive testet grundigt, og testerne mister overblikket efter dag 2.
Start derfor med at skrive scope ned i almindeligt sprog, som forretningen kan godkende. Det hjælper også, når der kommer ændringsønsker midt i UAT.
Efter en kort afklaring kan I fastlægge jeres vigtigste succeskriterier.
- Kerneprocesser
- Kritiske integrationer
- Lovpligtige rapporter
- Rollebaserede rettigheder
- Kontroller ved månedsluk
Testmiljø og testdata: gør det virkeligt, men sikkert
UAT bør køre i et dedikeret miljø, typisk en Business Central sandbox, hvor I kan teste uden at forstyrre drift. Miljøet skal være stabilt i UAT-perioden. Hvis der løbende deployes rettelser, skal det være styret og kommunikeret, så testresultater stadig er til at stole på.
Testdata er ofte den skjulte tidsrøver. Hvis brugerne tester på “tomt” data eller kunstige eksempler, overser man alle de praktiske undtagelser: rabataftaler, del-leverancer, returvarer, valutakøb, dimensioner, afrundinger, momsopsætning.
En enkel tommelfingerregel: Hellere færre, men realistiske datasæt, end et stort kopiudtræk, ingen forstår.
I testplanen bør I derfor beskrive:
- Hvordan data er skabt eller kopieret
- Om data er anonymiseret
- Hvilke stamdata der er “frosset” i UAT (kontoplan, bogføringsgrupper, dimensioner)
- Hvilke testbrugere og roller der anvendes
Microsoft beskriver også testmiljøer og testpraksis i Business Central-udviklingskontekst her:
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-testing-application
Roller og ansvar: få det skrevet ned, før første testdag
UAT fungerer bedst, når der er tydelig rollefordeling. Ikke tung governance, bare klare aftaler om hvem der gør hvad.
Brug et simpelt rolleoverblik i testplanen, så alle ved, hvem der kan svare på proces-spørgsmål, og hvem der kan tage fejl videre til udvikling eller konfiguration.
Eksempel på ansvarsfordeling:
- Testleder: Plan, tempo, daglig status, prioritering af fund
- Procesejer: Godkender procesflow og beslutninger om “sådan gør vi fremover”
- Superbrugere/testere: Udfører testcases og dokumenterer afvigelser
- Løsningsansvarlig (konsulent/IT): Fejlsøgning, rettelser, afklaringer
- Udvikling: Rettelser på extensions og integrationer
Skabelon: UAT-testplan til Business Central (kopiér og tilpas)
Her er en tekstskabelon, der er hurtig at genbruge i Word eller Confluence. Den kan også ligge i SharePoint sammen med testcases og fejl-log.
UAT-TESTPLAN (Business Central)
1. Formål og mål
- Formål:
- Mål (målbare):
- Afgrænsning (ikke i scope):
2. Scope (processer og områder)
- Salg:
- Indkøb:
- Lager:
- Finans:
- Service/produktion (hvis relevant):
- Integrationer:
- Tilretninger/apps:
3. Testmiljø
- Miljønavn:
- Version/build:
- Tilgængelighed (tider):
- Rettigheder/roller:
- Print/udskrifter sat op (ja/nej):
4. Testdata
- Grunddata (kunder, leverandører, varer, kontoplan):
- Åbningsposter (hvis relevant):
- Bankkonti/betalingsmetoder:
- Anonymisering:
5. Testmetode og dokumentation
- Hvor ligger testcases:
- Hvordan registreres resultater:
- Hvordan registreres fejl:
- Krav til dokumentation (skærmbilleder, trin, video):
6. Tidsplan
- UAT start/slut:
- Fælles testsessioner:
- Deadline for kritiske fejl:
- Retest-vinduer:
7. Entry/exit-kriterier
- Entry (klar til UAT):
- Exit (klar til go-live):
8. Godkendelse
- Procesejere der godkender:
- Godkendelsesdato:
- Kendte restpunkter (med plan):
Skabelon: testcase (Excel eller DevOps)
En testcase behøver ikke være lang, men den skal være reproducerbar. I Business Central-projekter ser man ofte, at “testcase” bliver en løs beskrivelse, og så tester alle lidt forskelligt. Resultatet bliver uens, og fejl kan ikke genskabes.
Sørg for, at hver testcase har preconditions og et forventet resultat. Microsoft beskriver minimumselementer for en testcase her:
https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/testing-strategy-planning
TESTCASE-SKABELON
- Test Case ID:
- Procesområde:
- Titel:
- Reference til krav/user story:
- Prioritet (H/M/L):
Preconditions
- Testdata (kunde, vare, lokation, dimensioner):
- Rolle/brugertype:
Trin
1.
2.
3.Resultat
- Forventet resultat:
- Faktisk resultat:
- Status (Pass/Fail/Blocked):
- Kommentar:
- Link til fejl (hvis Fail):
- Tester + dato:
Eksempelpakke: UAT-scenarier der typisk giver værdi i Business Central
Når I har skabelonen, skal den fyldes med test, der matcher virkeligheden. Her er et sæt scenarier, som ofte dækker meget for SMV’er, uden at blive uoverskueligt.
- Salg: tilbud, ordre, levering, faktura, kreditnota, rykker
- Indkøb: indkøbsordre, varemodtagelse, fakturamatch, retur til leverandør
- Lager: flytning, regulering, tælling, sporing (batch/serienr.), lokationer
- Finans: bogføringsopsætning, moms, periodisering, bank, afstemning
- Rapportering: standardrapporter, kontoudtog, dimensioner, ledelsesrapport
- Integrationer: bankfil, EDI/webshop, dokumentflow, betalinger
Fejlregistrering: gør det let at skrive en god “bug”
En fejl uden klare trin bliver ofte en samtale frem for en opgave. Derfor bør UAT-testplanen også definere, hvad en god fejlrapport indeholder, og hvordan den prioriteres.
Her er en skabelon, der fungerer i både Excel, Azure DevOps og Jira.
FEJL (BUG) – SKABELON
- ID:
- Titel:
- Område/proces:
- Alvorlighed (Blocker/Critical/Major/Minor):
- Prioritet (P1-P4):
Kontekst
- Miljø + version:
- Bruger/rolle:
Trin til at genskabe
1.
2.
3.Resultat
- Forventet resultat:
- Faktisk resultat:
Vedhæftning
- Skærmbillede (ja/nej):
- Eksempeldata (dokumentnr., varenr., bilagsnr.):
Flow
- Ejer (hvem undersøger):
- Status (New/In progress/Fixed/Ready for retest/Closed):
- Retest udført af + dato:
Efter en kort beskrivelse af alvorlighed og prioritet kan I bruge en lille “fælles ordbog”, så alle vurderer ens.
- Blocker: Stopper processen helt, ingen workaround
- Critical: Kan gennemføre, men giver forkert resultat eller høj risiko
- Major: Irriterende eller tidskrævende, men kan leve kortvarigt
- Minor: Kosmetik, tekst, små forbedringer
Sporbarhed: bind testcases sammen med krav, ændringer og rettelser
Sporbarhed lyder tungt, men kan gøres meget praktisk. Målet er enkelt: I skal kunne pege på, at alle krav og ændringer faktisk er testet, og hvad resultatet blev.
Hvis I bruger Azure DevOps, giver det god mening at linke testcases til user stories og bugs, så I kan følge kæden. Microsoft beskriver sammenhængen mellem test og livscyklusværktøjer her:
https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/lifecycle-services/using-task-guides-and-bpm-to-create-user-acceptance-tests
Hvis I kører Excel, kan I nøjes med en kolonne “Krav-ID” og en kolonne “Bug-ID”, så I stadig kan lave en enkel status.
Afvikling af UAT: en rytme, der holder
UAT dør ofte af kalenderproblemer. Testere har drift, kundesager, leverancer, telefoner. Derfor hjælper det at køre UAT i en fast rytme, hvor det er tydeligt, hvornår man tester, og hvornår der rettes.
En praktisk model er en kort, fast daglig kadence:
- Morgen: status på åbne fejl og dagens fokusområder
- Testblokke: 60 til 120 minutter pr. procesteam
- Opsamling: afklar spørgsmål, triager nye fund
- Aften eller næste morgen: deploy af godkendte rettelser til UAT-miljø
- Retest: kun på det, der faktisk er ændret
Page Scripting i Business Central kan også bruges til at gøre gentagne tests mere ensartede, især når man skal reteste efter rettelser. En introduktion kan findes her:
https://ssosic.com/bc-learn/conducting-uat-in-business-central-and-hidden-features-of-page-scripting/
Godkendelseskriterier: “vi er klar” uden at love det umulige
Der vil næsten altid være småting tilbage. Det vigtige er, at I på forhånd har besluttet, hvad der skal være løst, og hvad der kan planlægges til første sprint efter go-live.
Her hjælper det at definere exit-kriterier, som forretningen kan godkende. Et realistisk sæt kan være:
- Ingen Blocker-fejl åbne
- Alle Critical-fejl enten lukkede eller med accepteret workaround og plan
- Kerneprocesser testet end-to-end med dokumenteret Pass
- Nøgleudskrifter og rapporter godkendt
- Roller og rettigheder valideret for de vigtigste brugergrupper
- Cutover-aktiviteter afprøvet i mini-format (fx import, opsætning, bank)
Hos Naviteam ser man ofte, at de bedste UAT-forløb opstår, når godkendelse kobles til både proces og ansvar: procesejeren godkender flowet, og systemejeren godkender driftbarhed og ændringsstyring. Det giver ro på beslutningen, også når der er små restpunkter.
Mini-skabelon: UAT-status i én boks (til styregruppe eller ledelse)
Når mange tester samtidig, bliver “hvordan går det?” et dagligt spørgsmål. I stedet for lange mails kan I rapportere kort og ens hver gang.
UAT-STATUS (dato)
Gennemførte testcases: xx / yy
Pass: xx
Fail: xx
Blocked: xx
Nye fejl i dag: xx
Lukkede fejl i dag: xx
Åbne fejl (Blocker/Critical/Major/Minor): x / x / x / x
Top 3 fokusområder næste testdag
1.
2.
3.Risici/beslutninger der mangler
- …