Keep the failed check in the report

A checklist is useful when someone can understand what was tested and repeat the important parts. A row marked “done” does not provide that context. The SaaS Mirror release review tool records the outcome, conditions, and evidence together, including the work that is still unresolved.

The walkthrough below uses an entirely fictional reading-list app called Paper Lantern. These are illustrative observations, not test results from a real customer or product. You can inspect the sample JSON review or start from the blank Markdown checklist.

Start with the conditions

The sample release is demo-42. Its environment is private staging, and the only record is book-001, titled The Lantern Manual. In an actual review, record the browser version and device too. A claim about a phone layout is difficult to reproduce without knowing which phone, browser, and orientation were used.

Choose one concrete journey: open the book, change its title, save it, and find it again. The conditions apply to that journey, not to every feature in the product.

Make a pass reproducible

For check 01, the fictional reviewer opens /books/book-001 directly and records a 200 response with the expected title. For check 02, Back returns to /books?status=unread and restores the unread filter. These observations describe actual conditions within the example. They do not mean that every URL and navigation sequence works.

For check 06, an empty title produces “Enter a title” and keeps the other sample input. The reviewer records the invalid value, the exact response, and what happens after correction. Client-side validation improves this interaction, but server-side validation remains a separate concern. MDN: form validation

Keep a failure even after a successful retry

The next sample uses a documented staging failure fixture. Saving reports an error and clears the notes. Restoring normal conditions makes the retry succeed. That later success does not resolve the earlier loss of input.

Check 08 stays at “Needs follow-up.” Its note identifies the failure condition, the text that disappeared, and the result after retry. A useful follow-up is to fix the preservation of input and repeat that same condition. Repeating only the normal successful path would not test the reported problem.

A separate fictional phone check finds Save obscured by the on-screen keyboard in landscape. Check 15 keeps that finding separate from the desktop keyboard outcome. The environment and observation matter more than a single aggregate score.

Explain exclusions and preserve unknowns

Because this sample is private staging, the public-search checks are marked “Not applicable” with that reason. The example does not make the staging app public to satisfy a checklist. Likewise, a check that has not been performed stays “Not checked.” An unavailable test environment is not an observed pass.

The sample record contains three observed passes, two follow-ups, two exclusions, and eleven unchecked items. That describes review coverage. It is not a percentage of safety, accessibility, or release readiness. W3C similarly distinguishes preliminary accessibility checks from a comprehensive evaluation.

Export the whole record

Use the tool’s filters to focus on open issues while working. Exporting Markdown or JSON still includes all eighteen checks, the conditions, the notes, the checklist version, and the export time. The summary also identifies reviewed checks with no evidence or reason recorded.

Answers remain in the current tab rather than being saved to a server. Export before leaving and confirm the file was saved. Share a review containing appropriate sample data and keep its unresolved items intact. A useful handoff tells the next reviewer both where to start and what still needs to be established.