A software demonstration shows what a product can do under selected conditions. User acceptance testing (UAT) asks whether the configured system supports your organisation’s actual work. For HR software, this means testing employee journeys, permissions and data together before managers approve a move to live operation or accept a major change.
Translate requirements into observable results
A requirement describes what the organisation needs the system to do. An acceptance criterion is a specific condition for deciding whether that need has been met. A test case defines the starting data, steps and expected result used to check that condition in practice.
Replace “the system manages leave” with a specific case: an employee submits a request, the appropriate manager reviews it, the balance changes correctly and the record is visible only to authorised roles. State the starting data, action and expected result. This makes disagreements about readiness easier to resolve.
Microsoft’s guidance for planning Dynamics 365 implementation tests connects test cases to the work users perform. The examples here apply that general testing principle to HR work; they do not recommend a particular vendor. Prioritise processes where failure could affect pay, access, employee records or essential reporting.
Hypothetical example: testing a leave request
Before execution, prepare a test environment separate from live operations, with settings that represent the scope being accepted. Train participants on the steps, and assign a tester and result reviewer to each case. Use test accounts for an employee, the responsible manager and an unrelated manager, without sending notifications to real employees.
| Element | Hypothetical example for illustration |
|---|---|
| Starting condition | Test employee has 10 days available |
| Action | The employee submits a 2-day request; the responsible manager approves it using their own account |
| Expected result | Balance becomes 8 days after approval, and the request status is “approved” |
| Permission check | Unrelated manager cannot approve or view restricted detail |
| Execution record | Actual result, pass or fail status, execution date, tester and reviewer |
| Evidence | Case ID, system version and a log or screenshot link restricted to authorised people |
The example assumes that approval deducts 2 full working days, with no holidays, new accrual or simultaneous adjustment. The expected balance is therefore 10 − 2 = 8 days. Record the balance actually displayed; the expected result alone is not evidence of success. Test the organisation’s actual policy separately, including cancellations, part-days and any relevant calendar rules. A successful simple case does not establish that every variation works.
Connect requirements to test cases
After preparing the first example, create a requirements traceability matrix. This table links each requirement’s reference number to its test cases, results and evidence, exposing requirements that have not been tested. A requirement may need a normal-path test, an exception test and a permission test. Distinguish passed, failed, unexecuted and blocked cases. An unexecuted case has not passed, even if the supplier expects a later update to make it work.
For the leave example, do more than check the balance moving from 10 to 8 days. Test rejection and cancellation under the configured policy, then verify effects on balances, reports and notifications. Use accounts with different roles to confirm who may act. The numbers are illustrative; they establish neither a legal entitlement nor a mandatory organisational policy.
Record the system version, configuration and starting data for each case. If the team changes a calculation rule during testing, earlier results may no longer establish readiness for that part. Identify affected cases and repeat them. This prevents results from different configurations being combined as proof that a single release is ready.
Test across teams and systems
Follow complete journeys such as joining, changing role, taking leave and leaving the organisation. Check where HR data moves to payroll, identity management or reporting. A correct screen can still feed incorrect information to another system. An integration exchanges data or actions between systems. Verify the final result at each important interface.
Include exceptions: a manager is absent, a request is rejected, an employee changes department mid-process or an integration fails. Agree who receives the problem and how work continues. Test users should include the people who perform the work, supported by technical specialists where needed.
Reconcile migrated data
Compare meaningful totals and selected records between the approved source and the new system. Matching employee counts are insufficient: one missing record and one duplicate can leave the total unchanged. Check identifiers, effective dates, balances and relationships important to the process. Record expected transformations rather than treating every difference as an error.
Use synthetic data: test records that do not belong to real people. Alternatively, use real data protected by approved controls. If personal information is necessary, approve access, minimise the fields and apply retention rules. Do not place confidential employee screenshots in an unrestricted defect tracker. Evidence should prove the result without creating a second uncontrolled data store.
Test what each role must not do
A permission test should include a denied action as well as an allowed one. Verify that employees cannot see another person’s restricted records, that managers have the intended scope and that administrative privileges are limited to authorised users. Include export and report access, not only the main screens.
Check removal of access when a role changes or an employee leaves. Confirm how exceptional access is approved and later withdrawn. Ask technical owners to verify security controls beyond what business users can observe; user acceptance testing does not replace specialist security assessment.
Make defects actionable
For each failed case, record the expected and actual results, business effect, reproducible steps and owner. Severity describes the size of the defect’s impact; priority determines the order and urgency of repair. A cosmetic issue and an incorrect pay calculation do not have the same consequences. Agree which defects block go-live and who can accept a documented residual issue.
After a fix, repeat the failed case to confirm that the defect has been resolved. Then run regression tests on related cases to check that the fix has not broken previously working functions. Retain the result against the tested configuration and version. A verbal statement that the supplier has fixed an issue is not equivalent to verified acceptance.
Bring evidence to the acceptance meeting
Present the requirements tested, open defects and their business effects. A general pass percentage is insufficient: one pay-related case can fail while many lower-impact cases pass. Separate defect severity from repair priority. Explain who approves a workaround and when its use must end.
Test the workaround too: it is a temporary procedure that lets work continue until the defect is fixed. If the proposed solution is a manual balance correction, identify who may perform it, how it is reviewed and how duplication is prevented when integration resumes. An unclear manual procedure is not a complete resolution. The business owner needs to understand its workload and error exposure before accepting it.
Discuss support after launch: where issues are reported, how relevant records are accessed, who handles escalation and how work continues during a serious interruption. Request evidence that the rollback plan has been rehearsed: this plan restores the previous state if launch cannot continue. It must also explain what happens to transactions entered after go-live. A backup alone does not prove that service and data can be restored correctly.
The acceptance decision should identify the approved scope and release, together with accepted exceptions and their owners. If only one department or workflow launches initially, state what the decision excludes. Review results after real use. Structured testing reduces uncertainty but cannot guarantee that every defect has been found under every operating condition.
Make acceptance a business decision
Before approval, confirm completed critical tests, reconciled data, trained users, support ownership and a workable contingency. Record unresolved issues and decisions explicitly. If readiness is insufficient, reduce the rollout scope or defer it instead of hiding defects behind a completion percentage.
ATMACSS business and operations modelling can help translate HR processes into requirements and acceptance cases. Start with one important employee journey and test it from beginning to end, including one realistic exception.