Who owns which part of user acceptance testing
Key users
The staff who will process the transactions after go-live. They follow scripts, record what happened, and say plainly when something would slow them down.
- โExecute scripts in the sandbox
- โLog defects with screenshots
- โRetest fixes
Process owners
The controller, warehouse manager or sales lead who is accountable for a process. They decide whether a defect blocks go-live and sign off their area.
- โApprove the scripts
- โJudge severity
- โSign off their process
Implementation consultants
Consultants prepare the environment, explain expected behavior, triage defects and correct setup or code. However, they should not be the ones marking tests as passed.
- โLoad test data
- โTriage and fix
- โExplain standard behavior
Project sponsor
Usually the CFO or owner. The sponsor protects time for testers, settles disputes between departments and makes the final go or no-go call.
- โFree up tester time
- โResolve disputes
- โMake the final call
Business Central testing scripts built from last month's transactions
Nobody should invent the best test scripts. Instead, take a recent month and pull real documents. Think of a sales order with a partial shipment, a customer who pays short, and a purchase invoice that does not match its receipt. Add a credit memo, an intercompany charge and an inventory adjustment after a cycle count. Each becomes a script that says what to enter, what the tester should expect to see, and which report or ledger proves the result.
Scripts should follow a process end to end rather than testing one screen at a time. Order to cash runs from quote through shipment, invoice, payment and the customer statement. Procure to pay runs from requisition to payment and the vendor aging. Record to report finishes with a trial balance and the financial statements your board actually reads. Testing whole chains catches the handoff problems that single-screen checks miss.
Two details separate useful testing from theater. First, testers must log in with the permission sets they will have in production, not an administrator account. Otherwise you will discover on day one that the receiving clerk cannot post a receipt. Second, testing should run on migrated data that you load the same way you will at cutover. That way, the balances, open items and item cards under test are the real ones.
One acceptance testing cycle in Business Central
- 1
Prepare the environment
Create a sandbox from the current configuration, load the latest data migration, and set up each tester with their production permission sets.
- 2
Walk testers through the scripts
A short session per department explains the scripts, where to log results and how to describe a defect so someone else can reproduce it.
- 3
Execute and record
Testers run every script, mark each step passed or failed, and attach a screenshot and the document number for anything that went wrong.
- 4
Triage daily
Consultant and process owners meet briefly to agree severity for new defects, separate real faults from training gaps, and assign fixes.
- 5
Retest and regress
The person who raised each fixed item retests it. Then the team reruns a small set of core scripts to make sure a fix did not break something else.
- 6
Sign off by process
Each process owner signs their area and lists any open low-severity items. So the sponsor can see exactly what the business is accepting.
User acceptance testing severity levels and what they mean for go-live
Habits that quietly ruin user acceptance testing
- โTesting with administrator rights, so permission problems stay hidden
- โLetting the consultant who built the setup mark tests as passed
- โUsing a handful of tidy demo records instead of migrated data
- โSkipping the month-end steps because they feel far away
- โSqueezing testing into spare minutes while testers do their full day jobs
- โTreating every complaint as a defect instead of separating training gaps
User acceptance testing for Business Central: who, where and how often
Who should do user acceptance testing on Business Central?
The people who will do the work after go-live should run the tests, with process owners deciding what passes. Consultants prepare the environment and fix what testers find, but they are too close to the setup to judge it. A tester who processes receipts every day will spot problems a consultant never would. The sponsor's role is to protect their time.
Should we test in production or in a sandbox?
Always test in a sandbox environment, never in the production company you will go live on. Business Central online lets an administrator create sandboxes, including copies of production, from the admin center. Testing in a sandbox means you can reload data, repeat scripts and break things safely. The production environment should only receive the final, signed-off configuration and the cutover data.
How many test cycles do we need?
Plan for at least two, because the first cycle always finds issues whose fixes need retesting. The first pass exposes setup gaps and data problems; the second confirms the fixes and runs the full chains on a fresh data load. Complex operations, heavy integrations or poor first results may justify a third. The scope we write at the start sets the plan for your project.
Scope changes, integrations and reports during testing
What if testers find problems nobody asked for in the requirements?
Log them anyway, then decide deliberately whether each one is a gap, a change or a training point. Some are genuine misses that you must fix before go-live. Others are new wishes that can wait for a later phase without hurting operations. Keeping them visible, with a decision against each, stops them turning into arguments after the system is live.
Does acceptance testing cover integrations and reports?
Yes, and they are often where the serious problems hide. Test every integration with real volumes and at least one deliberate failure. Then you see how errors surface and who gets told. Tie reports and financial statements back to ledger totals, rather than just opening them for a glance. If the board pack will come from Business Central, test the board pack.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
