Contents
A convincing demo follows a prepared route. Acceptance testing asks whether your people can complete the agreed work, with realistic data, permissions and failures. This guide provides 18 starting scenarios and a reusable decision record for a custom web application.
What this checklist covers
These are business acceptance examples, not an exhaustive security assessment, an accessibility certification or a universal contract. Choose the relevant cases with your delivery team and add the risks specific to your operations.
Agree on the outcome before testing the screens
Start with one complete journey: receive a request, assign it, approve a decision, notify the right person and retrieve the evidence. A page opening successfully says little about whether that journey works. Define who owns the expected result and what would prevent launch.
For example, a fictitious distributor wants warehouse staff to record a received parcel and sales staff to see the updated status. The acceptance result is one correctly linked record with a traceable status change. It is not merely a green confirmation message. This fictional example illustrates the method; it is not a Daillac customer result.
Describe these outcomes in the application requirements brief. The brief helps you define the scope and request a quote. Use the acceptance record to review the resulting delivery.
Prepare a repeatable test environment
- Record the application version, environment, browser, language and test date.
- Create separate customer, employee, manager and administrator test accounts.
- Use synthetic records and files; avoid copying personal customer data into an uncontrolled test environment.
- Write the starting state and expected result before executing each scenario.
- Agree who fixes a defect, who retests it and who makes the launch decision.
A test record needs an identifier, business purpose, preconditions, actions, expected result, observed result and evidence. Include the application version with each screenshot or log. When a new build arrives, a previous successful result may need to be checked again if the changed component affects that journey.
Six checks for the core business journey
TableStarting acceptance grid: business records · shareable block
| Scenario | Expected evidence | |
|---|---|---|
| 01 · Complete request | Submit a valid request and follow it to its destination. | One request ID, correct field values and the expected owner. |
| 02 · Missing information | Leave a required business field empty. | A clear error; existing input retained; no incomplete final record. |
| 03 · Double submission | Submit twice or retry after an uncertain response. | One business operation, or an explicit duplicate-handling rule. |
| 04 · Customer boundaries | Sign in as customer A and try to open customer B’s record. | Access refused without exposing B’s information. |
| 05 · Approval responsibilities | Prepare a change as an employee and approve it as a manager. | The intended role approves; the action and identity are traceable. |
| 06 · Dates and export | Export a record with dates, accented names and decimal amounts. | Values remain meaningful in the agreed language, timezone and format. |
Do not implement a duplicate rule only by disabling a button. A timeout can make a browser retry after the server has already saved the action. Ask the delivery team how it recognizes a repeated operation. The business owner should specify whether two similar requests are valid separate jobs or duplicates.
Six checks for actual working conditions
TableStarting acceptance grid: people and integrations · shareable block
| Scenario | Expected evidence | |
|---|---|---|
| 07 · Small screen | Complete the main journey on the agreed mobile devices. | Fields and actions usable without losing critical information. |
| 08 · Keyboard and errors | Complete the form without a mouse, including an invalid value. | Visible focus, reachable controls and understandable recovery. |
| 09 · French and English | Switch language and repeat the relevant journey. | Correct labels, messages and destination language; data retained as agreed. |
| 10 · Repeated notification | Deliver the same integration event twice in the test system. | No unintended duplicate task, invoice or message. |
| 11 · External outage | Make a connected test service unavailable, then restore it. | A visible pending or failed state and a controlled recovery path. |
| 12 · Concurrent changes | Have two authorized users change the same record. | A documented conflict rule rather than a silent loss of work. |
When an external connection fails, distinguish a request waiting to be processed from a final rejection. Staff need to know whether they should wait, correct information or contact support. A generic error page leaves the operational decision unresolved even when the technical error is logged.
The W3C accessibility evaluation guidance emphasizes human evaluation alongside tools. A keyboard check is a useful acceptance scenario; passing it alone does not establish accessibility conformance.
Six checks for handover and recovery
TableStarting acceptance grid: safe operation · shareable block
| Scenario | Expected evidence | |
|---|---|---|
| 13 · Restore | Restore a controlled backup into the agreed test environment. | The chosen records and their relationships can be recovered. |
| 14 · Release recovery | Rehearse the documented response to a failed release. | Named decision owner, recovery steps and treatment of changed data. |
| 15 · Empty and loading states | Open an empty list and a slow-loading journey. | Staff can distinguish no results, work in progress and a failure. |
| 16 · File handling | Try approved files and a file outside the agreed rules. | Clear limits, authorized access and understandable rejection. |
| 17 · Remove access | Disable a test user and review the relevant active access. | The documented revocation policy takes effect and is verifiable. |
| 18 · Submission monitoring | Complete a test request with the permitted measurement settings. | Business receipt and operational trace are distinguishable from a page view. |
The OWASP ASVS provides a basis for checking technical application security controls. Use an agreed version and scope when security requirements are part of the mandate. This business grid complements that work; it does not replace a professional security review.
Turn a failed test into a decision
Consider fictitious record Q-1042. A request appears in the application, but the accounting connection times out. A useful acceptance record identifies the saved request, shows the pending integration and proves that recovery does not create a second record. If the team cannot distinguish “saved” from “not saved”, keep that journey open rather than marking the screen as passed.
- A release blocker prevents a required journey, exposes unauthorized data or makes recovery unsafe.
- A significant defect has an agreed workaround, an owner and a retest date.
- A cosmetic issue may be deferred when it does not prevent use and the decision is recorded.
These categories are a proposed working convention. Agree their meaning before the review so a supplier and an operations manager do not classify the same defect differently. Never erase a failed result when it is corrected: attach the retest and preserve the history.
What to keep in the acceptance record
Keep the agreed scenario list, results by application version, unresolved defects, accepted workarounds, operating instructions and the named decision owner. Separate the launch decision from a later enhancement request. If a new business rule appears during testing, record whether it corrects agreed behaviour or expands the original scope.
Attach these records to future change requests for your custom web application. The team preparing the quote can review the accepted journeys and any exceptions still open.
IllustrationStaged editorial scene of a warehouse worker scanning a parcel while testing a web application on a tablet · shareable block
Questions fréquentes
Who should run acceptance testing?+
Business users validate expected outcomes with support from the delivery team. Developers can prepare accounts and evidence, but a person responsible for the business process should review the launch decision.
Are these 18 tests sufficient for every application?+
No. They are a starting grid. Payments, regulated data, complex integrations and other risks require additional scenarios and specialist verification.
Should every defect stop launch?+
Use the severity rules agreed for the project. Record any workaround, the person accepting it and the planned correction. Do not treat unauthorized data access as a cosmetic issue.
Does a successful security scan mean the application is accepted?+
No. A security check and a business acceptance review answer different questions. You still need to verify journeys, permissions, data and recovery.
When should acceptance criteria be written?+
During scoping, then refined before delivery. Waiting until the final demonstration makes it harder to distinguish a defect from a new requirement.
Prepare a reviewable launch decision
Bring your key journeys, current requirements and integration list. We can help define what evidence the team needs before launch.
D
