Software acceptance testing, often called user acceptance testing, is the phase in which the client checks that the delivered software, website or application matches what was requested, before it goes live. It compares the product with the requirements document and ends with a decision: accept, accept with reservations or reject the delivery. This guide is for owners and managers of small businesses and SMEs who are having a custom tool developed and want to prepare this stage without being testing specialists.
What is software acceptance testing?
Acceptance testing is a testing and validation phase carried out before deployment in the live environment. It applies to any type of project: brochure website, online shop, mobile application, ERP, CRM or business tool.
- It checks that the product complies with the requirements document and with the business needs expressed by users.
- It relies on an acceptance test plan, which describes the test scenarios to run.
- It differs from the tests carried out by the service provider during development: acceptance testing is the client's validation.
- It leads to acceptance without reservations, to validation with reservations or to a rejection if blocking defects persist.
Where acceptance testing fits in the project
Acceptance testing takes place after development, but it is prepared well before, as soon as the needs are formalised. The software requirements document is its starting point: every function described must be verifiable when the time comes.
- Statement of needs: the client formalises their expectations and priorities.
- Requirements document: the reference document describing the functions, constraints and priorities.
- Design and development: the service provider builds the solution and runs its internal tests.
- Acceptance testing: the client validates the delivered product according to the acceptance test plan.
- Go-live: deployment in the live environment.
- Operation and maintenance: monitoring, fixes and enhancements.
In a project delivered in a single release, acceptance testing is grouped at the end of the process. In an iterative approach, intermediate validations take place at each delivery, then an overall acceptance test precedes the switch to production. Whether the tool is custom-built or adapted from an existing solution, as our guide to custom software explains, this validation remains necessary.
Functional, technical and user acceptance testing
In practice, these validation angles overlap, but telling them apart helps organise the work.
- Functional acceptance testing: every function planned in the requirements document is present and produces the expected result, for example creating an account, generating a quote or approving a purchase request.
- Technical acceptance testing: it covers the non-functional aspects, such as stability, security, response times, compatibility with browsers and mobile devices, or data backup. It is often carried out by the service provider, who shares the results with the client.
- User acceptance testing: a representative group of end users checks that the screens are understandable, that the journeys are smooth and that the tool matches real practices in the field.
- Exchanges between systems: when the tool communicates with other software, for example through an API integration, the data exchanges are also among the scenarios to test.
Requirements document, acceptance test plan and acceptance report: who does what?
These three documents form the common thread of a well-managed project.
- The requirements document describes the objectives, the expected functions, the constraints and the priorities.
- The acceptance test plan lists the test cases. For each one, it specifies the prerequisites, the input data, the actions to perform and the expected result. It is best written with the service provider and the business leads, then validated before testing begins.
- The acceptance report (sign-off) formalises the final decision: what is accepted, any reservations and the conditions for lifting them. Its scope depends on what your contract provides; reread it before signing.
The steps of successful acceptance testing
- Preparation: reread the requirements document, define the scope (modules, profiles, critical journeys), choose the test environment and put together the acceptance team on the client side.
- Writing the acceptance test plan: list the critical journeys, detail each test case and prepare the test data.
- Running the tests: run the scenarios and record for each one the result, the discrepancies observed and any useful screenshots, in a single tracking document.
- Fixes and regression tests: the service provider fixes the defects, then you check that the fixes have not affected functions already validated.
- Validation: list the remaining defects, separate acceptable reservations from blockers, then sign the acceptance report.
Classifying defects: blocking, major, minor
A classification agreed in advance avoids disagreements at the time of acceptance and helps decide what must be fixed before go-live.
| Type of defect | Description | Example |
|---|---|---|
| Blocking | The main function is unusable; going live is not possible. | Impossible to complete an order on the website. |
| Major | A key requirement of the requirements document is not met; a temporary workaround exists. | Incorrect calculation of a discount; incomplete report. |
| Minor | Display flaw or marginal behaviour, with no strong effect on the business. | Text cut off on mobile; unclear button label. |
Roles and responsibilities
- Project manager on the client side: they plan the acceptance testing, lead the test sessions, arbitrate the severity of defects and validate the acceptance report.
- Business users: they test the concrete cases of their daily work and flag anything that is hard to understand.
- Management: it frees up time for the testers; without that, validation remains superficial.
- Service provider: it prepares the acceptance environment, contributes to the acceptance test plan, tracks the defects and coordinates the fixes.
Common mistakes to avoid
- Starting without an acceptance test plan and simply browsing the tool at random.
- Entrusting acceptance testing to a single person, without the users concerned.
- Testing only on a large screen with a fast connection, forgetting mobile devices and slower connections.
- Demanding that every graphic detail be fixed before dealing with the blocking defects.
- Neglecting regression tests after the fixes.
- Signing the acceptance report without rereading the list of reservations and the conditions for lifting them.
Acceptance testing checklist for owners of small businesses and SMEs
- The acceptance scope is written down: modules, profiles and critical journeys.
- The requirements document is up to date, including changes decided during the project.
- An acceptance test plan is derived from it and has been validated by the business leads.
- A person in charge of acceptance testing is appointed on the client side.
- Key users are available to test real scenarios.
- The schedule allows time for the tests and for the fixes.
- Defects are reported in a single place, with their severity and status.
- Fixes are verified by regression tests.
- The acceptance report lists the deliverables, the reservations and the conditions for go-live.
- User training and documentation are planned at delivery.
Frequently asked questions about software acceptance testing
When should you start preparing acceptance testing?
As soon as the requirements document is written, by identifying the journeys that will have to be tested before go-live. Waiting until the end of development amounts to improvising.
What is the difference between functional and user acceptance testing?
Functional acceptance testing compares the tool with the requirements document, function by function. User acceptance testing checks that it suits real use, from the point of view of the people who will use it every day.
Can you go live with reservations?
That is a decision to take with your service provider, according to your contract. When non-blocking defects remain, they are described in the acceptance report and their correction is scheduled.
Do you need an acceptance report for a small website?
A short document is often enough: it clarifies what is delivered and accepted, and limits misunderstandings after delivery.
Prepare your acceptance testing with UnzipTech
Acceptance testing links the requirements document, the acceptance test plan and the acceptance report in a single validation chain. An identified person in charge, involved users and rigorous regression tests make it a controlled step rather than a formality.
UnzipTech, an IT consulting and development company based in Fez, designs custom software, websites and mobile applications. Our projects include a free custom quote, training and documentation at delivery, as well as maintenance contracts. Discover our services or contact us to prepare your project.