60 UAT-scenarier for adgang til optjent løn før go-live

60 UAT-scenarier for adgang til optjent løn før go-live: fra tidsregistrering til lønafstemning

UAT for adgang til optjent løn kan ikke kun teste 'tryk og se penge komme ind'. Et system kan fungere godt i standardflowet, men fejle når arbejdstid ændres, to anmodninger kommer samtidig, banken timeout, medarbejderen fratræder eller lønnen lukkes. De 60 scenarier nedenfor hjælper virksomheder med at teste hele kæden med data og resultater, der kan verificeres.

> Kort sagt: Go-live bør kun ske, når test beviser korrekt person – korrekt arbejdstid – korrekt beløb – korrekt konto – ingen dobbeltbetaling – kan afstemmes – i korrekt lønperiode. Alle fejl relateret til penge, adgangsrettigheder eller persondata skal have klare blokkeringskriterier.

> Advarsel: Dette er et bibliotek af reference-scenarier, ikke en erstatning for systemets testplan. Undgå destruktive transaktioner eller brug af rigtige data uden tilladelse. Beløb, konti og testmiljø skal godkendes af alle parter.

1. Hvordan adskiller UAT sig fra demo?

(Se også: Hvad virksomheder skal forberede for at implementere adgang til optjent løn og Integration af adgang til optjent løn.)

En demo viser, at produktet kan fungere i en forberedt situation. UAT besvarer, om produktet opfylder de aftalte forretningskrav under reelle og undtagelsesforhold.

Hver test case skal indeholde:

• kode og mål;
• forudsætninger;
• inputdata;
• udførelsestrin;
• forventet resultat;
• faktisk resultat;
• bevis;
• tester/godkender;
• fejlens alvorlighed;
• status og dato for retest.

2. Forberedelse af UAT-data

Opret en kontrolleret simulering af brugere:

• nye, aktive, fratrådte og overførte medarbejdere;
• personer med samme navn men forskellige ID'er;
• personer, der arbejder for en eller flere kunder;
• normal arbejdstid, nattevagter, manglende timer, overarbejde;
• korrekte, forkerte eller ikke-eksisterende konti;
• personer tæt på grænseværdierne;
• succesfulde, mislykkede, ventende og tilbageførte transaktioner;
• åbne, tæt på cut-off og lukkede perioder.

Brug ikke rigtige ID'er eller medarbejderkonti uden godkendelse.

3. Fejlens alvorlighed og blokkeringskriterier

Niveau	Eksempel	Beslutning
P1 Kritisk	Dobbeltbetaling, forkert person, læk af nøgler/store data	Bloker go-live
P2 Høj	Forkert tilgængeligt beløb, forkert løn, overskredne rettigheder	Bloker indtil rettet og retestet
P3 Mellem	Forkert meddelelse, svære undtagelsesflows	Vurder risiko og plan for rettelse
P4 Lav	Præsentationsfejl uden forretningspåvirkning	Kan sættes i backlog hvis godkendt

De endelige kriterier skal være dokumenteret i testplanen, ikke besluttes impulsivt på go-live dagen.

4. Gruppe A — Profiler og brugsbetingelser (UAT 01–06)

UAT 01 — Aktiv bruger med komplet profil

Forventning: log ind og se korrekt kunde/aktiverede funktioner.

UAT 02 — Fratrådt bruger

Forventning: adgang låst efter cut-off; kan ikke oprette nye anmodninger.

UAT 03 — Brugere med samme navn

Forventning: systemet skelner med identifikationsnøgle, blander ikke arbejdstid/transaktioner.

UAT 04 — Manglende ID eller OCR mismatch

Forventning: ingen transaktion tilladt; vis vejledning til løsning, ingen data lækage.

UAT 05 — Bruger overført til anden kunde

Forventning: korrekt før/efter overførsel; ingen adgang til forkert kundedata.

UAT 06 — En bruger arbejder flere steder

Forventning: arbejdstid og tilgængeligt beløb korrekt adskilt for hvert sted; ingen dobbeltoptælling.

5. Gruppe B — Tidsregistrering og synkronisering (07–14)

UAT 07 — Realtids tidsregistrering

Forventning: post vises i henhold til SLA, initial korrekt status.

UAT 08 — Gyldig Google Sheet synkronisering

Forventning: korrekt match af person/dato/skift; rapporter antal succesfulde rækker.

UAT 09 — Forkert bruger-ID i Sheet

Forventning: tilføj til fejlliste, ikke gæt på anden person.

UAT 10 — Genindlæsning af samme fil/post

Forventning: ingen dobbeltoptælling af arbejdstid.

UAT 11 — Nattevagt over midnat

Forventning: korrekt tildeling af skift/dato i henhold til kundens regler.

UAT 12 — Forskellige time/dato formater

Forventning: understøttede formater læses korrekt; ikke-understøttede formater giver klar fejl.

UAT 13 — To kilder med forskellige data

Forventning: anvend korrekt kilde/sandhedsprincip og udsend advarsel.

UAT 14 — Afbrudt synkroniseringsjob og genkørsel

Forventning: ingen tabte/dobbelte poster; korrekt checkpoint og advarsel.

6. Gruppe C — Godkendelse og rettelse af arbejdstid (15–20)

UAT 15 — Godkendelse af gyldig supervisor

Forventning: statusændring, gem godkender/tidspunkt.

UAT 16 — Godkendelse af gyldig kunde

Forventning: påvirker kun personer inden for kundens område.

UAT 17 — Bruger uden godkendelsesret

Forventning: afvist på server og logget.

UAT 18 — To parter godkender næsten samtidig

Forventning: ét konsistent resultat, ingen dobbeltbegivenheder.

UAT 19 — Rettelse af godkendt arbejdstid

Forventning: tilbage til ventende godkendelse, gem før/efter og opdater tilgængeligt beløb i henhold til regler.

UAT 20 — Arbejdstid i dag/fremtid

Forventning: ikke medregnet hvis ikke opfylder lukkede dagsregler.

7. Gruppe D — Formler og tilgængeligt beløb (21–28)

UAT 21 — Grundlæggende formel

Forventning: godkendt arbejdstid × enhedspris minus modtaget og reserve stemmer med manuel beregning.

UAT 22 — Ingen godkendt arbejdstid

Forventning: tilgængeligt beløb er 0 med en forståelig årsag.

UAT 23 — Afrunding ned til 1.000 DKK

Forventning: korrekt ved grænseværdier, ingen afrunding op.

UAT 24 — Delvist modtaget i perioden

Forventning: korrekt reduktion af resterende beløb, ingen dobbelttræk.

UAT 25 — Reserve efter antal dage

Forventning: korrekt opbevaring af de N nyeste dage i henhold til effektive indstillinger.

UAT 26 — Reserve efter procent/grænse

Forventning: korrekt anvendelse af betingelser; grænseflade forklarer den reserverede del.

UAT 27 — Ændring af enhedspris i perioden

Forventning: hver arbejdstid bruger korrekt version af politik eller godkendt regel.

UAT 28 — Flere kunder, flere enhedspriser

Forventning: separat beregning for hvert sted, ingen forveksling af enhedspriser.

8. Gruppe E — Grænser og brugskontrol (29–34)

UAT 29 — Under minimumsgrænse

Forventning: systemet afviser før afsendelse af ordre.

UAT 30 — Præcis minimumsgrænse

Forventning: accepteres hvis andre betingelser er opfyldt.

UAT 31 — Præcis maksimum pr. ordre

Forventning: accepteres; overskridelse af en enhed afvises/justeres korrekt.

UAT 32 — Overskridelse af daglig grænse via flere ordrer

Forventning: dagens samlede ordrer overskrider ikke politikken.

UAT 33 — To samtidige anmodninger med samme tilgængelige beløb

Forventning: låsning forhindrer overskridelse eller dobbeltbetaling.

UAT 34 — Ændring af grænse med effekt

Forventning: korrekt godkendt person, korrekt effektivitetsdato og audit trail.

9. Gruppe F — Konto, enhed og identifikation (35–40)

UAT 35 — Korrekt navngivet VPBank-konto

Forventning: succesfuld verifikation og passende skjulning.

UAT 36 — Forkert navngivet konto

Forventning: ikke tilladt, vis vejledning til løsning.

UAT 37 — Ikke-eksisterende/ikke-verificerbar konto

Forventning: holdes i ikke-verificeret status, ingen transaktion tilladt.

UAT 38 — Forsøg på at ændre låst konto

Forventning: brugeren kan ikke ændre uden for processen; alle undtagelser kræver godkendelse/log.

UAT 39 — Login på anden enhed

Forventning: korrekt anvendelse af politik for én person–én enhed og enhedsændringsproces.

UAT 40 — Udløbet/kapret login-session

Forventning: kræver ny verifikation; gammel token kan ikke oprette transaktioner.

10. Gruppe G — Transaktioner og bank (41–48)

UAT 41 — Succesfuld transaktion

Forventning: én ordre-ID, korrekt beløb/konto, status og kvittering.

UAT 42 — Klar bankafvisning

Forventning: korrekt fejlstatus; tilgængeligt beløb behandles i henhold til regler.

UAT 43 — Timeout efter ordreafsendelse

Forventning: skift til ventende, ingen automatisk ny ordre.

UAT 44 — Forsinket svar efter timeout

Forventning: opdatering med samme transaktion, ingen dobbelt pengepost.

UAT 45 — Gentagne afsendelser

Forventning: idempotency sikrer ét finansielt resultat.

UAT 46 — Forkert signatur/kilde i svar

Forventning: afvist, sikkerhedsadvarsel; ikke ændret til gennemført.

UAT 47 — Tab af pengeoverførselstjenesteforbindelse

Forventning: fail-closed, kø/gendannelse i henhold til design, klar meddelelse.

UAT 48 — Nødstop

Forventning: bloker nye ordrer; ventende transaktioner bevares; genaktivering kræver rettigheder og log.

11. Gruppe H — Afstemning og løn (49–55)

(Detaljer: se Afstemning af transaktioner for adgang til optjent løn med løn og regnskab.)

UAT 49 — Fuldstændig matchende kontoudtog

Forventning: alle transaktioner korrekt matchet og markeret som afstemt.

UAT 50 — På systemet, mangler på kontoudtog

Forventning: generer undtagelse, ingen automatisk konklusion eller ændring uden bevis.

UAT 51 — På kontoudtog, mangler på systemet

Forventning: opdaget fra bank til system og sendt til undersøgelse.

UAT 52 — Forkert beløb/dobbelt ID

Forventning: ingen tvungen matching; advarsel og låsning hvis nødvendigt.

UAT 53 — Overførsel til løn

Forventning: kun succesfulde transaktioner, korrekt person/kunde/periode.

UAT 54 — Transaktion tæt på cut-off

Forventning: korrekt anvendelse af periode regler og forklarlig rapport.

UAT 55 — Dækket arbejdstid

Forventning: ingen dobbeltoptælling i næste periode; lønseddel og samlede transaktioner stemmer.

12. Gruppe I — Adgangsrettigheder, data og drift (56–60)

UAT 56 — Kunde ser krydsdata

Forventning: ingen adgang til andre kunders personer/arbejdstid, selv ved URL/API manipulation.

UAT 57 — Følsomme superadmin-rettigheder

Forventning: konfigurations-/undtagelseshandlinger kræver verifikation, log og godkendelse i henhold til regler.

UAT 58 — Rapporteksport og dataskjul

Forventning: korrekt omfang; ID/konti skjult; eksporterede filer kontrolleret.

UAT 59 — Klage over 'trukket penge men ikke modtaget'

Forventning: kundeservice sporer korrekt ID, ser tilstrækkeligt bevis, ingen data sendt via usikre kanaler.

UAT 60 — Gendannelse efter hændelse

Forventning: service gendannes i henhold til mål; ingen tabte/dobbelte transaktioner; afstemning bekræfter endelig status.

13. Grænsetest for standardkonfiguration af adgang til optjent løn

Hvis pilotkunder bruger standardværdier i koden, bør mindst følgende testes:

Parameter	Under grænse	På grænse	Over grænse
Minimum pr. gang	49.000	50.000	51.000
Maks pr. ordre	2.999.000	3.000.000	3.001.000
Maks pr. dag	4.999.000	5.000.000	5.001.000
Afrunding	99.999	100.000	100.001

Ovenstående tal er tekniske standarder, ikke forpligtelser for alle kunder. Testplanen skal bruge de faktiske konfigurationer i pilotmiljøet.

14. UAT-bevismatrix

Gruppe	Minimum bevis
Profiler	Kildedata, resultat skærmbillede, synkroniseringslog
Arbejdstid	Post før/efter, godkender, audit trail
Formler	Uafhængig beregning og systemresultat
Konto	Verifikationsresultat med skjulte data
Transaktioner	Ordre-ID, status tidslinje, gyldig log
Bank	Svar og test kontoudtog
Løn	Inputfil, rapport, eksempel lønseddel
Adgangsrettigheder	Rettighedsmatrix og blokeret adgangstest
Hændelser	Tidslinje, advarsler, runbook og gendannelsesresultat

Skærmbilleder alene er ikke tilstrækkelige til at bevise end-to-end flow.

15. Anbefalede go-live betingelser

(Efter go-live: se Drift af adgang til optjent løn efter go-live.)

• 100% af P1/P2 scenarier er kørt og bestået;
• ingen fejl, der kan føre til forkert betaling, dobbeltbetaling eller overskredne rettigheder;
• arbejdstid, transaktioner, kontoudtog og løn for pilotprøven stemmer;
• alle P3 fejl er risikovurderet, har ejer og rettelsesfrist;
• produktionskonfiguration er uafhængigt verificeret;
• korrekt liste over pilotpersoner/kunder;
• pengegrænser og nødstop er godkendt;
• bank, HR, løn, IT-sikkerhed og kundeservice er klar;
• overvågning/advarsler er aktive;
• rollback og kommunikationsplan er øvet.

Undgå at kræve '60/60' opfyldt mekanisk, hvis nogle tests ikke er relevante; dokumenter undtagelsesårsager og godkender.

16. Fejlstyringsproces

1. Registrer fejl med data og reproducerbare beviser.
2. Kategoriser efter faktisk påvirkning.
3. Identificer ansvarlig for løsning, undgå rundsendelse mellem parter.
4. Ret i kontrolleret miljø.
5. Genkør fejltest og relateret regressionstest.
6. Forretningsansvarlig bekræfter resultat.
7. Opdater dokumentation, runbook eller kontrol hvis årsagen ikke kun er kode.

Luk ikke fejl blot fordi 'ikke reproducerbar' uden at tjekke log, data og tidsforhold.

17. Ofte stillede spørgsmål

Hvem skal underskrive UAT-protokollen?

Det bør omfatte forretningsansvarlig, produktansvarlig/leverandør og repræsentanter fra berørte områder som HR/løn, finans, IT eller IT-sikkerhed i henhold til RACI.

Er det nødvendigt at overføre rigtige penge under UAT?

Prioriter sandbox eller godkendte pilotkonti/beløb. Hvis produktionstest er nødvendig, skal omfanget begrænses, overvågning være til stede, afstemning ske straks og en nødstopplan være klar.

Kan mange enhedstests erstatte UAT?

Nej. Enhedstest kontrollerer komponenter; UAT beviser, at processen opfylder brugerbehov og politikker med næsten virkelige data.

Kan en mindre fejl blokere go-live?

Afhænger af påvirkningen. Præsentationsfejl kan muligvis ikke blokere; fejl, der misforstår beløb, lækker data, forkert adgang eller påvirker afstemning, skal vurderes strengt.

Skal UAT køres igen efter go-live?

Regressionstest er nødvendig ved ændringer i formler, grænser, arbejdstidskilder, banker, løn, rettigheder, infrastruktur eller betydelige releases.

---

Tác giả: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Adgang til optjent løn for virksomheder