15 July 2026
Acceptance testing is the least loved moment of IT projects. Scheduled at the end, handed to teams already overloaded, run on unrealistic test data. Then everyone is surprised that the real problems show up in production, in front of the clients.
Effective acceptance testing is not played out at the end of the project. It is prepared from the scoping stage. The method below has been proven in the field.
Start from real situations, not features
The usual reflex is to test screen by screen: "the client form opens, the button saves". Necessary, and very insufficient. What breaks in production are complete journeys with their twisted cases: the order modified after partial invoicing, the credit note on last year's invoice, the client that exists twice.
Build your scenarios from daily life: "a day in order management", "a monthly close", "a client return". The vicious cases are known by the people who do the work. Not by the vendor, and not by the project manager.
Write scenarios that can actually be run
A good acceptance scenario fits in three columns: the starting situation, the actions, the expected result, described precisely. "Check invoicing" is not a scenario. "Create a 3-line order with a discount, deliver partially, invoice: the invoice picks up the 2 delivered lines with the discount" is one. If the expected result is not written down, every tester will decide alone what counts as "normal".
Prepare the data before day one
Testing on three demo clients proves nothing. You need a realistic data set, anonymised if necessary, that contains your real cases: clients with special terms, composite products, the awkward history. Preparing that data set takes time. That is precisely why you start early.
Qualify defects before arguing about them
Define the grid before the first defect, not during the dispute: blocking (prevents the business, forbids go-live), major (temporarily workable, fix scheduled), minor (prevents nothing, handled over time). Without a shared grid, every defect triggers a negotiation, and the supplier relationship wears out fast.
Give testers time, for real
The great lie of acceptance schedules: "users will test on top of their day job". They will not, and it is not a motivation problem. Book blocked half-days, backfill people's desks if needed. Testing rushed for lack of time always costs more than the time it seemed to save.
End with a decision, not a sigh
Acceptance ends with a document that says three things: what was tested, what is accepted, what remains under reservation with a fix deadline. This sign-off is not an administrative formality. It is what triggers go-live with eyes open, and it protects both parties if a disagreement comes later.
One last number for the road. A defect found in acceptance is fixed calmly, in a test environment. The same defect in production is fixed urgently, with real data to repair and users to reassure. The cost gap is routinely a factor of ten. Acceptance is not the end of the project: it is what decides whether the project ends well.