An order was created successfully in front of you, but was the rule rejecting it for a different duration or conflicting reservation checked? A count of successful tests cannot answer that alone. When buying user acceptance testing for custom software, request the covered business rules and an explanation of what remains unchecked.
Avoid starting with button instructions such as “save and open details.” Begin with the business decision and conditions that change it. Connect each case to an approved requirement and expected outcome, rather than treating an attractive screen as evidence that every agreed policy was implemented.
One rule may need several cases
Imagine a fictional internal portal for borrowing shared devices. For illustration only, the organization permits a maximum of five days and rejects borrowing that conflicts with an existing reservation. This teaching policy is neither a recommended lending duration nor a description of a system we implemented.
Borrowing an available device for two days checks part of the rule. It does not yet establish behavior at the boundary, beyond it or with a conflict. Document the two rules separately and connect specific cases to them. Successful verification of one does not establish that the other works.
A small coverage sheet
| Starting condition | Attempt | Expected illustrative outcome |
|---|---|---|
| Available device without conflict | Four-day request | Accept subject to other approved conditions |
| Available device without conflict | Five-day request | Accept the maximum boundary itself |
| Available device without conflict | Six-day request | Reject excess duration with an understandable explanation |
| Device with conflicting reservation | Request within the limit | Reject the conflict without creating another reservation |
This begins an acceptance package rather than covering the entire portal. Day calculation, start times, cancellation and other in-scope concerns require separate decisions. Record unresolved questions before execution; differing interpretations cannot be settled by changing expected outcomes after observing the software.
Make results understandable again later
Include the rule reference, software version, role, initial data, date, steps and actual result. Where data changes, retain enough to recreate the sample without unnecessary personal information. A rejection screenshot is useful when the request that produced it is identifiable.
The ISTQB acceptance syllabus connects tests with criteria and traceability, describing techniques including decision tables and boundaries. That principle supports a sheet business owners can review; referencing it does not accredit the project or establish that this table reveals every defect.
Unexecuted does not mean successful
The conflict case may be impossible because the environment contains no existing booking or the reviewer lacks the appropriate role. Record “not executed,” its reason, an owner and next action. A written scenario cannot be counted as passed merely because it appears in a document.
Ask what any reported percentage uses as its denominator: planned cases, executed cases or covered rules? Many passing cases might repeat one decision while an important rule remains untested. There is no universal project success percentage here; the business owner decides using impact, coverage and exceptions.
Who prepares tests and accepts outcomes?
Assign someone who understands policy, environment and sample preparation, discrepancy analysis and decision approval. SFIA describes resources, criteria and realistic conditions within acceptance management. A developer able to operate the demonstration cannot replace the person who can judge a business rule.
Connect discrepancies to their cases and rules, distinguishing implementation defects, new requirements and unresolved decisions. After repair, rerun the case against an identified version and determine related cases requiring checks. An old result cannot automatically represent every subsequent release.
The requirements guide supports criteria writing, while the change-impact sheet addresses new requests. When requesting custom software from Nextwave, include rule coverage and an unchecked-case register among acceptance deliverables, keeping commercial agreements separate.
References and limits
Sections 2.2 and 5.2 of the 2019 ISTQB Acceptance Testing syllabus and SFIA9 user acceptance testing guidance were read on 4 November 2026. The original example and sheet involve no actual assessment. AI assisted preparation, with information and translation review.
