Chapter 6
Log, fix, and retest defects
defect log and retest protocol is the practical output of this chapter. Complete it in one focused work session so you can decide which defects block launch and what evidence closes each one, without patching symptoms without proving the buyer journey is restored.
What you’ll get
- A completed defect log and retest protocol you can use in the next chapter.
- A documented decision about which defects block launch and what evidence closes each one.
- A pass or fail signal: every launch-blocking issue has reproduction steps, an owner, a fix, and a successful clean retest.
- A concrete first action: Capture device, route, timestamp, expected result, actual result, and evidence for every defect; then retest from the beginning.
A defect report should reproduce the problem
Record the exact URL, entry route, device, browser, time, numbered steps, expected result, actual result, order/reference ID, and a redacted capture. Give the issue a severity:
- Blocker: payment, confirmation, or access cannot complete.
- High: wrong product, total, recipient, or permissions.
- Medium: confusing or broken content with a workaround.
- Low: visual inconsistency that does not stop completion.
Retest from the beginning after a fix. A repaired download link does not prove the checkout-to-delivery chain is now correct.
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: Capture device, route, timestamp, expected result, actual result, and evidence for every defect; then retest from the beginning.
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 | which defects block launch and what evidence closes each one is written in one sentence | Reduce the scope until one owner can choose |
| Execution | Capture device, route, timestamp, expected result, actual result, and evidence for every defect; then retest from the beginning. | Assign a time and owner, then complete the smallest end-to-end version |
| Verification | every launch-blocking issue has reproduction steps, an owner, a fix, and a successful clean retest | Return to the failed boundary and retest only after the cause is changed |
Common failure mode
Marking a defect fixed because the changed screen looks better, without repeating the original steps. 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 defect log and retest protocol.
- 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.
