Guide · Apps & software
Software testing for clients: how to accept work properly
Developers test their own work, but only the client can confirm that the result does what the business needs. Acceptance testing is that confirmation. Done well, it catches problems before users do and ends the project with clarity. Done casually — a quick look at a few pages — it lets issues through and creates disputes later about what was agreed.
[ 01 ]
In short
In short
- 01
Test on the staging environment with realistic scenarios, not random clicking.
- 02
Base scenarios on the agreed scope and acceptance criteria.
- 03
Report bugs with steps to reproduce, expected and actual results, and screenshots.
- 04
Distinguish defects (not as agreed) from change requests (new wishes).
- 05
Retest fixes and key flows before sign-off.
[ 02 ]
Guide
Prepare scenarios
List the tasks real users will perform, end to end:
- A customer finds a product, chooses a size, pays by card and receives confirmation.
- A manager receives an enquiry in the CRM and changes its status.
- An editor publishes a news article in two languages.
- An administrator adds a new user with limited rights.
Include unusual cases: a declined payment, a form with invalid data, a user without permission, an empty search. Use the acceptance criteria from the scope or user stories. See writing user stories.
Test environment
Testing happens on staging — a copy of the system with test data and test payment modes. Real customers are not affected, and real cards are not charged. See staging and testing.
Who tests
The people who will use the system: sales managers, operators, editors, accountants. They notice what an outsider would miss. Give them time for testing — it is work, not something done between other tasks.
Reporting bugs
A useful bug report includes:
- Where: page or screen, and the environment.
- Steps: exactly what you did, in order.
- Expected result: what should have happened.
- Actual result: what happened instead.
- Evidence: screenshot or screen recording, error messages.
- Device and browser, especially for layout issues.
- Severity: blocks work, causes errors, cosmetic.
"The form does not work" requires a round of questions; a report with steps and a screenshot gets fixed faster.
Defects vs change requests
- A defect is behaviour that differs from what was agreed.
- A change request is something new or different from what was agreed, even if it now seems obviously needed.
Both are legitimate, but they are handled differently: defects are fixed within the project; changes are estimated and scheduled. Agreeing on this distinction early avoids disputes. See website contract checklist.
Regression
Fixes and changes can break other parts. Before sign-off, repeat the key scenarios, not only the ones where bugs were found.
Multilingual and multi-device checks
- Every language version: texts, forms, emails, error messages.
- Phones and computers, main browsers.
- Slow connection for key flows.
Sign-off
Acceptance is complete when agreed scenarios pass, critical and major defects are fixed, and remaining minor issues are listed with a plan. Record sign-off in writing, with the list of known issues.
After launch
Some issues appear only with real users and real data. A warranty or support period covers fixing defects found after launch. See website maintenance.
[ 03 ]
FAQ
Frequently asked questions
How long should acceptance testing take?
It depends on the size of the system. Plan it as a stage in the timeline, with named testers and time allocated.
Can we test on the live site after launch instead?
Some checks, yes, but finding critical issues after launch costs more and affects real customers.
What if we find many small issues?
Prioritise: fix what blocks or confuses users first, then the rest. A shared list with severity and status keeps everyone aligned.