
Chapter 1
Define working before you test
checkout acceptance-criteria sheet is the practical output of this chapter. Complete it in one focused work session so you can decide the exact evidence required to call payment and delivery working, without ending the test after one reassuring screen.
What you’ll get
- A completed checkout acceptance-criteria sheet you can use in the next chapter.
- A documented decision about the exact evidence required to call payment and delivery working.
- A pass or fail signal: each buyer-side and seller-side requirement has a binary pass or a reproducible defect.
- A concrete first action: Write pass conditions for page load, price, payment, confirmation, email, access, order record, and refund/support ownership.
Write acceptance criteria
For each step, state what must be true. “Delivery works” is vague. “The buyer can open the confirmation page, receive the delivery message at the address used at checkout, and download the correct named file without seller intervention” is testable.
| Stage | Pass condition | Evidence to save |
|---|---|---|
| Product page | Title, price, format, contents, and policy match the offer | Full-page capture with timestamp |
| Checkout | Correct product and total; required fields work | Redacted checkout capture |
| Payment | Approved route reaches confirmation once | Order/reference ID, never card data |
| Confirmation | Clear next step and support route | Confirmation capture |
| Delivery | Correct file or gated content opens | File name/version and access capture |
| Receipt/delivery message arrives and links work | Redacted email capture | |
| Seller record | Order, customer, product, and amount appear correctly | Redacted order capture |
| Refund path | Responsible person knows the current process | Written owner and test note |
Use safe test data
Never place real card details in screenshots or defect reports. Use the payment-provider test data only inside an official test environment. If you must make a real purchase, keep it controlled, disclose it to the account owner, and record the refund plan before paying.
Apply this chapter to your store
Start with the evidence you already have: the current Tapmy setup, the exact customer path, the messages people see, and the records created after an action. Do not redesign the entire system while you are still trying to locate the constraint.
Implementation move: Write pass conditions for page load, price, payment, confirmation, email, access, order record, and refund/support ownership.
Write the decision beside the evidence that supports it. If a teammate cannot reproduce the conclusion from the same evidence, the work is not yet operational. The deliverable should be specific enough to hand to another person without a meeting.
Decision checkpoint
| Check | Pass condition | If it fails |
|---|---|---|
| Evidence | The current state is visible and reproducible | Capture the real route, screen, record, or message before changing it |
| Decision | the exact evidence required to call payment and delivery working is written in one sentence | Reduce the scope until one owner can choose |
| Execution | Write pass conditions for page load, price, payment, confirmation, email, access, order record, and refund/support ownership. | Assign a time and owner, then complete the smallest end-to-end version |
| Verification | each buyer-side and seller-side requirement has a binary pass or a reproducible defect | Return to the failed boundary and retest only after the cause is changed |
Common failure mode
Defining success as ‘the payment went through’ while ignoring delivery and seller records. This hides the actual constraint and creates false confidence. Use the chapter output as a gate: do not move forward until the decision is explicit and the pass signal is visible.
20-minute implementation sprint
- Open the current Tapmy path and capture the starting state.
- Complete the smallest version of the checkout acceptance-criteria sheet.
- Record the decision, owner, and next review date.
- Test the pass signal once from the customer’s point of view.
- Save the evidence where the person running the next chapter can find it.







