Picture the shipment tracking panel of a logistics company. In the final meeting the development team walks through the screens one by one: creating a shipment, assigning a vehicle, the delivery photo, the notification sent to the customer. Everything runs smoothly. Everyone in the room is happy, the handover form is signed and the final payment goes out.
Two weeks later the operations team starts using it for real work. A shipment split across two vehicles on the same day cannot be entered. Customer names containing "&" appear garbled in notifications. The warehouse supervisor, who should only see their own warehouse, sees shipments from every warehouse. None of this came up in the demo, because nobody tried any of it in the demo.
A demo shows that the software works. Acceptance testing should show that the software works in your business. They are not the same thing, and the gap between them usually shows up after handover, when fixing it costs more.
1. Write the acceptance criteria before development starts
"There will be a shipment screen" is not a criterion. "A shipment can be split across more than one vehicle; the delivery status of each part is tracked separately" is a criterion. If what you will test at handover is written down before development begins, the development team knows what to build and you know what to check.
The list does not have to be long. Two or three sentences per important workflow are enough: who should be able to do what, under which condition, and what they should see at the end. The list can change during the project; what matters is that the change is written down too.
2. Test with real data
Records like "Test Company 1" and "John Smith" in the test environment make everything easy. Real life has customer names with apostrophes, long legal names, accented characters, two branches under the same tax number and missing phone numbers.
Before handover, prepare a sample from your own data: pick your longest and messiest records, your largest order and the invoice with the most line items. If the sample contains personal data, mask it before you hand it over. If the software displays and calculates these records correctly, it is less likely to struggle with everyday ones.
3. Deliberately test the paths that go wrong
Demos always show the path where everything goes smoothly. Acceptance testing should ask: What happens if a record is left half finished? Is a submitted form lost when the connection drops? If two people edit the same record at the same time, whose change stays? Does a cancelled order go back into stock? Can an amount entered wrongly be corrected later, and is the correction recorded?
Write at least one "goes wrong" scenario for each main workflow and test that too. The development team will think of most of these scenarios; but only you know which of them actually happen in your business.
4. Let the person who will use the software every day run the test
The person managing the project and the person who will use the software every day are often different people. The manager sees that the screens are complete; the employee in operations notices how many clicks it takes to finish a task, which field they fill in by hand every time and which information they copy from another screen.
Set aside at least one real user for acceptance testing and give them not a checklist but a real working day: "Enter yesterday's shipments into the system." Have someone sit next to them to note where they get stuck. That half day brings out in advance many of the small complaints that would otherwise arrive after handover.
5. Test every role with a separate account
Permissions are the topic most often skipped in acceptance testing, because the test is usually done with an administrator account that can see everything. But the warehouse supervisor, accounting, field staff and customers should see different things and be able to change different things.
Ask for a separate test account for each role, sign in with each one and check: Can this person see a record they should not see? Can they reach someone else's record by changing the number in the address bar? Can they perform an action they have no permission for? These checks matter both for how the business runs and for protecting personal data.
6. Collect findings in one list, with priorities
If findings during acceptance testing are scattered across email, messaging apps and meeting notes, nobody can track which ones have been fixed. Keep a single list and write three things for every finding: what was done, what was expected, what happened. A screenshot is often clearer than a paragraph.
Give every finding a priority as well. "We cannot go live until this is fixed", "fix this within the first month" and "this can wait for the next version" do not carry the same weight. When it is clear from the start what blocks handover, the discussion moves from "finish everything" to "finish these three items".
7. Ask for what sits outside the software in the handover package
The software may work, but if someone else has to take it over tomorrow, working is not enough. Before the final payment, check that you have: the current source code in a repository under your own account, server and service accounts in your name, a short document describing the installation and release steps, and administrator passwords that you have changed yourself.
If these items are not written into the acceptance criteria, they are very easy to forget at handover. We described earlier how to define "done" for an integration project in our API integration story; at the handover of a whole project, the same definition is the sum of these seven steps.
How much time should acceptance testing take?
A few days for a small project and one or two weeks for a large system is a reasonable range. What matters is that this time is in the schedule from the start and that time is also left for the fixes. Squeezing acceptance testing into the day before the final payment turns every gap you find into "we'll look at it later".
In short
- Write acceptance criteria before development starts, a few sentences per workflow.
- Test with the messiest examples from your own data.
- Test one failure scenario for each main workflow.
- Have the person who will use the software every day test it with a real working day.
- Test every role with a separate account.
- Collect findings in one list, with their priorities.
- Make source code, accounts and documents part of the handover package.
In custom software projects, we write the acceptance criteria together with the client during the first planning stage and set aside separate time in the schedule for acceptance testing.
Planning a project like this?
Plan it in 10 steps