Every implementation plan has a phase called testing. On most plans it sits near the end, in a box smaller than the ones before it, occupying whatever time is left between configuration and the go-live date that was promised to leadership months ago.
That placement tells you everything about how testing is treated: as a formality to clear, not a phase to run. And it is the reason so many systems that "passed UAT" go live and immediately break in ways nobody saw coming — because what was tested was never the thing that matters.
You did not spend a year and a substantial budget to confirm that the software works. Of course the software works. You spent it to build a system that runs your business — your payroll, your approvals, your exceptions, your edge cases. And that system is precisely the one that testing, as most organizations run it, never actually tests.
"The Vendor Tested It" Is Not Your Testing
There are two completely different questions hiding inside the word testing, and conflating them is where the trouble starts.
The first is whether the software functions — whether the buttons work, the calculations compute, the workflows move as designed. The vendor tests this, thoroughly, before you ever see it. It is their product, and it works. Confirming it again is not what your testing is for.
The second question is whether the system, configured the way you configured it and loaded with your data, produces the right outcomes for your organization. That is a question only you can answer, because only you know what "right" means for your business. It depends on your policies, your pay rules, your approval structures, your exceptions — none of which the vendor tested, because none of them are the vendor's. When testing gets treated as a box to tick, this is the question that quietly goes unanswered, and it is the only one that determines whether go-live succeeds.
The Happy Path Passes. Your Business Isn't the Happy Path.
Most UAT runs on scripts, and most scripts describe the happy path: a standard employee, a standard request, a standard approval, clean data, nothing unusual. Run those scripts and everything passes, because the happy path is exactly what the system was built and configured to handle. Everyone relaxes. The scorecard turns green.
But your business does not live on the happy path. It lives in the exceptions — the four-level approval where the second approver is on leave, the employee on a fixed-term contract whose policy differs from the standard, the retroactive pay adjustment that spans two pay periods, the month-end payroll run that touches multiple entities and currencies. These are not rare curiosities. In most organizations the exceptions are fifteen percent of the volume and sixty percent of the work — and they are the first thing that breaks in production, because they are the last thing anyone tested.
Testing that only covers the happy path is not testing the system. It is admiring it. The scenarios worth building UAT around are the ugly ones: the highest-volume real transactions, the known exceptions, the month-end and year-end cycles, the workflows with conditions. If it is complicated in real life, it belongs in the test — especially if it would be embarrassing to get wrong in front of employees.
The People Who Configured It Cannot Be the People Who Test It
There is a structural conflict at the heart of most UAT, and it explains a great deal of the false confidence it produces. The people running the tests are often the same people who ran the project — the implementation team and the configurers. They wrote the scripts. They built the thing the scripts test. And, entirely without meaning to, they test it the way they built it.
Someone who configured a workflow tends to test it by doing what the workflow expects. They know where the edges are and they stay inside them, because that is how the system lives in their head. The result is a test that confirms the builder's mental model rather than challenging it — a closed loop that passes because it was never designed to fail.
The people who should test are the ones who will actually use the system in anger: the payroll administrator who runs the real cycle, the HR operations lead who handles the real exceptions, the manager who approves real requests. They do not know where the edges are, so they walk straight into them. They try the thing the configurer never imagined because it is simply how their Tuesday works. Their testing is messier, slower, and far more useful — because it is the closest thing to production you will get before production.
A Passed UAT on the Wrong Scenarios Is Worse Than None
It is tempting to think that some testing, even shallow testing, is better than none. In the case of UAT, that is not quite true — because a UAT that passes on the wrong scenarios does something actively harmful. It manufactures confidence that is not warranted.
An organization that knows it has not tested properly stays alert. It watches the first payroll run closely, keeps the implementation team on hand, braces for problems. An organization that ran a full UAT and saw every box go green does the opposite. It stands down, reassigns the team, and tells leadership the system is ready — because on paper it is. The green scorecard becomes a reason to stop paying attention at exactly the moment attention matters most.
This is why a clean UAT report is not the goal. The goal is a UAT that tried hard to break the system and documented honestly what it found. A test phase that surfaces twenty real problems before go-live has done its job. A test phase that surfaces none has almost certainly not tested the right things — because every real implementation has problems, and the only question is whether you find them in a test environment or in front of your workforce.
The Role This Keeps Pointing Back To
Issue 02 of this newsletter described the role nobody budgets for — the HR Tech expert who bridges business operations, HR processes and technology decisions. Testing is where that bridge is most visibly missing, because good UAT requires someone who knows both what the system was built to do and what the business actually does with it — and can see the gap between the two.
That person designs test scenarios from real operations rather than from configuration scripts. They insist the operations people test rather than the project team. They protect the testing window when the timeline starts eating it, and they refuse to read a green report as proof when the scenarios behind it were never real. Without that person, testing defaults to whatever confirms the system works — which is the one thing you already knew.
A Final Thought
Testing is the last chance to find problems where they are cheap to fix. Every issue caught in UAT costs a fraction of the same issue caught in production, where it arrives attached to a real employee, a real paycheck, and a real loss of trust. Yet it is the phase most consistently compressed, delegated, and reduced to a formality — precisely because, by the time you reach it, everyone is tired and the go-live date is close and a green report is such a relief to sign.
Getting it right does not require more time so much as different intent: test the system your business runs, not the one the vendor built; build the scenarios from your real exceptions, not from happy-path scripts; put the tools in the hands of the people who will actually use them; and treat problems found as success, not failure. A UAT run that way is uncomfortable, and it is the cheapest insurance you will ever buy on the whole investment.
The system that passes an easy test is not the system you are going live with. Test the hard one, while it is still cheap to be wrong.
A UAT that finds nothing didn't prove the system works. It proved you tested the wrong things.