How to build an acceptance checklist from a recorded demo
Turn a product demo into an acceptance checklist with conditions, actions, expected results and evidence. A worked example based on agreed requirements.
A successful demo covers only the scenarios it shows
On the call, the form appeared to submit the request correctly. The demo might not have covered a different role, a repeated submission or a missing required field. A recording shows what happened during the demo. Other scenarios still need testing.
Build the acceptance checklist from requirements agreed in advance. A viewer’s new idea may be valuable, but record it separately. Otherwise, the scope can shift during acceptance and people end up discussing different versions of the task.
Prepare the checks from the recording
Record the version and conditions
Note the version or build, who demonstrated it and which role they used. Describe the test data and environment in enough detail for someone else to repeat the scenario. Flag any unknown conditions.
Link each check to a requirement
Take the agreed behavior and find the relevant point in the recording. One demonstration can cover multiple checks, but each needs its own expected result. Add a “not tested” item for any required behavior that was not shown.
State the action and expected result
Replace “check the form” with the data to enter, the control to click and the result to expect. Specify the expected response to invalid input. Keep new edge cases outside the acceptance checklist unless they fall within the agreed scope.
Run the checks again
Run the scenarios on the agreed version, record what happened and attach evidence. Use distinct statuses for failures, blocked checks and missing data. After a fix, rerun the affected scenario and record the new date.
Acceptance testing for a consultation request form
This fictional example uses names, conditions and results solely to illustrate the method.
A phone number is required. On successful submission, a request appears in the list and the visitor sees a confirmation. Without a phone number, the form must not submit.
This gives three observable checks: required field validation, request creation and a confirmation shown to the visitor. A polished screen after the click proves only one part.
If the tester cannot access the request list, mark request creation as “blocked.” The presenter’s word alone cannot turn it into a pass.
| Review | Expected result | Evidence to keep |
|---|---|---|
| No phone number | A required-field message appears and no request is created | Screenshot and a check of the list |
| Valid data | One request with the values entered | Entry in the test list |
| Successful submission | Clear confirmation for the visitor | Screenshot after submission |
Template for one acceptance check
Each row should say what observation will determine the final status.
Check ID: Agreed requirement: Version / role / environment: Input data: Actions: Expected result: Actual result: Status: passed / failed / not tested / blocked Evidence and timecode: Related fix: Retest date:
Review the checklist before testing
- Items refer to the agreed scope.
- The expected result can be seen or measured.
- The recording and the tester’s own checks are distinguished.
- Failures have reproducible conditions.
A closer look
Should every comment from the meeting go into the checklist?
Separate defects against requirements from new requests. Assess and agree on requests separately so acceptance does not keep expanding the project.
Can we accept the result based on video alone?
That depends on the agreed acceptance rules. Video can provide evidence for the scenario it shows. Record the method and the limits of what was checked.