Acceptance testing – how you know the app delivers

When the agency says the app is done, your job begins. Acceptance testing is the client’s own check that the delivery actually does what was agreed, before you approve it and pay the final invoice. Unlike “clicking around a bit and seeing if it works,” the difference is structure: you test against something defined, with the right people, and base the approval decision on facts instead of a gut feeling.

From acceptance criteria to test cases

The foundation for an acceptance test already sits in the requirements spec, in the acceptance criteria you set for what the app must handle. The problem is that criteria are often written broadly, and broad statements can’t be tested directly. The step is to turn each criterion into a concrete test case.

A criterion like “the user can book a time slot” becomes a test case with clear steps: log in, choose a service, choose an available time, confirm, and an expected result – the booking shows up in my bookings and a confirmation arrives. Every test case should have preconditions, steps, and an expected outcome, so whoever runs it only needs to confirm whether it holds true or not.

The point is to remove room for interpretation. A good test case can be run by anyone in the business and give the same answer: pass or fail. Then approval becomes a sum of concrete results, not a general gut feeling that the app “seems fine.”

Organize the test period with the right users

An acceptance test should be done by the people who will actually use the app, not by project management alone. The business’s own users know the real workflow and find problems no one else sees, because they test the app the way it will actually be used.

Set up the period with clear structure:

• Set a time limit. A defined test period with a start and an end creates focus and a date to rally the results around.
• Appoint testers and roles. Who tests what? Divide the test cases so everything is covered and nothing falls through the cracks.
• Provide a reporting channel. Decide how a finding should be reported and what the description should include: what the tester did, what happened, and what was expected.

A loosely run test period mostly produces scattered opinions that are hard to act on. A structured one produces a list of reproducible findings the agency can fix, and that you can follow up on.

Classify the findings and decide what blocks approval

Not all findings are equally serious, and treating them as if they were leads you astray. Either you approve a broken app because “most of it works,” or you get stuck on details and delay a perfectly usable launch. The solution is to classify findings by severity.

A critical defect, like a payment not going through or login failing, should stop the approval. A cosmetic issue or a request for an extra feature shouldn’t, and is handled after launch. By deciding the classification in advance, you avoid arguing over every single finding in the heat of the moment when the schedule is tight.

A concrete scenario

Say you’re acceptance testing a booking app. The testers, who are staff who’ll use it daily, run the test cases and report twelve findings. Two are critical: a booking is sometimes double-booked, and the confirmation doesn’t arrive in one particular flow. The rest are minor: a button sits slightly off, a text is unclear. The decision becomes easy thanks to the classification: the two critical issues must be fixed before approval, the rest is handled after launch. So you don’t approve a broken app, but you also don’t get stuck on details.

A sharp acceptance test rests on a clear requirements spec with testable criteria. Read more about how we work with requirements and delivery among our services, or get in touch if you’d like support setting up the test.