BlogSoftware acceptance
Accepting software: business tests and verifiable open issues
“It works” needs a case, a result and someone who can approve it. Acceptance begins before the demonstration.
Test worksheet: Software acceptance with verifiable business tests
“It works” needs a case, a result and someone who can approve it. Acceptance begins before the demonstration. Record inputs, expected outcome, evidence, owner and observed result.
Turn scope into results you can verify
“Production module complete” does not tell you whether you can reserve material, record waste and partially deliver an order. Write the starting point, data, steps and final state for each process. Name its tester and approval owner. If a requirement changes during testing, record the scope change before judging the supplier against a different rule.
ITI distinguishes functional testing from acceptance against business needs and processes. Azure Test Plans can organize manual and acceptance tests with results. Tools can organize the work; criteria, representative data and the decision to use the system still need owners.
Fictional example: producing and partially delivering an order
A factory rehearses order P-310 for 100 units. Material is available for 80, a batch of 60 is produced and quality rejects five. The expected outcome is 55 released units, five rejected and 45 still owed on the order. This synthetic case is not a customer's result. Its value is connecting production, quality and a sales commitment in one check.
The buyer should not approve it because each screen opens. They must find the same order, see material reservation, distinguish rejection from delivery and verify that a second click does not create another dispatch. Agree how the outstanding quantity will be handled. If the order can close without an explanation, decide whether that violates the defined process.
| State | Meaning | Next decision |
|---|---|---|
| Passed | Result and evidence match the agreed criterion | Close that case |
| Failed and blocking | Prevents critical work or corrupts data | Correct and retest before release |
| Limited use accepted | Specific workaround and owner-approved risk | Document limit, owner and date |
| Not run | Access, data or dependency was missing | Still pending; never count as passed |
Check normal work, exceptions and retries
The matrix must identify the tested version, environment and input. Evidence should name a reference, export or screenshot that reconstructs the result without unnecessary sensitive data. A long demonstration recording does not replace an identifiable case. Fill observed results during execution rather than copying them from a proposal.
| Test | Expected result | Business owner |
|---|---|---|
| Reserve material for 80 | Visible reservation without authorizing impossible production | Production |
| Release 55 and reject five | Separate quantities and recorded rejection reason | Quality |
| Deliver the 55 released units | Order retains 45 outstanding | Sales and warehouse |
| Attempt to deliver rejected units | Blocked with a useful explanation | Quality |
| Retry confirmation after losing response | One dispatch; existing reference can be queried | Warehouse |
| Unauthorized user attempts release | No state change; traceable attempt | Process owner |
Verify again after a correction
Ask for a new run of the failed case on the corrected version. Also check a neighboring case that could be affected: changing outstanding-quantity calculations may alter returns or cancellations. Keep old and new results; deleting initial evidence to make a matrix look perfect hides useful history. Closing a failure should explain what changed and who confirmed the result.
Do not reduce the decision to a pass percentage. Nine passed tests and one duplicate dispatch may still prevent operation. Classify issues by their business effect and agree on each unresolved item. Performance, specialist security and recovery may need additional evaluation; functional acceptance alone does not demonstrate that those areas are resolved.
Keep delivery and acceptance boundaries clear
Use a controlled copy for rehearsal and agree which test data will remain. User preparation, connections, training and the cutover window can limit use even after code is delivered. Connect acceptance with the cutover and rollback plan, and review questions before hiring a software company to document access and responsibilities.
The downloadable worksheet contains examples to adapt to your process. Bring an anonymized order, a frequent exception and the stage scope to a free consultation for software consulting. We can review whether the criteria support a concrete decision, without turning a successful demonstration into automatic approval.
Frequently asked questions
It can execute and document technical checks, but business acceptance belongs to the agreed owner. That person needs sufficient data and criteria to decide. Signing a list without running the cases does not demonstrate the outcome.
Blockers must be resolved before the affected use begins. Other issues may be accepted with a documented limitation and workaround. The decision depends on risk and agreement; a pass percentage does not replace that review.
Evidence should identify version, input, steps and result without replaying the entire conversation. It may be a reference with an export, an authorized screenshot or a system record. The process and data policy determine the appropriate form.
Not necessarily. A well-described failure can be corrected and retested. Clarify ambiguous criteria; review the agreement when a critical capability is outside scope. Do not accept a different outcome solely because a stage was scheduled to finish.
Sources
- Azure Test Plans overviewMicrosoft
- Pruebas de softwareITI
Last updated:
