# Tester Walkthrough — authoring template > Internal authoring aid, not a rendered doc page. Copy this into your scratch notes while > capturing scenarios, then write the real thing as `walkthroughs//index.html` > (see an existing one, e.g. `walkthroughs/favorites/index.html`, for the HTML shape). Delete > this comment block once you start. ## Title / DevDashboard entry - Feature name and its exact "To Test" row label from `DevDashboard.razor`. - Work item (if any). - Route(s) covered. ## Coverage completeness — before writing scenarios Don't scope the walkthrough to whatever's easiest to find. Before drafting scenarios, inventory the feature's *actual* surface in code (grep for the feature's `.razor`/`.xaml` pages, `@page` routes, and every button/link/toggle on them) and diff it against the scenario list you're about to write. A scenario that only names an action in passing ("tap X to do Y") without steps, screenshot, and expected result is not coverage — it's a placeholder (found via this gap repeatedly on the FTDT walkthrough, AB#2287: Add Rest/Add Note were named but never walked, only one of five op-types was exercised). If a walkthrough already exists for this feature, don't assume it's stale *or* current — check its last-updated date against `git log` on the feature's actual source files since that date; if nothing changed, the existing scenarios are still good and don't need re-writing, only gap-filling. ## Prerequisites - Logged in or logged out to start? - Mock data or Live data (or does the walkthrough deliberately exercise both)? - Any simulator/device state the tester needs first (e.g. an existing favorite, a specific account, a fresh install)? ## Scenarios Repeat this block per scenario. A walkthrough is only useful as a smoke test if a tester can tell *wrong* from *right* — the "what a failure looks like" line is not optional filler. Write and validate every scenario live via MauiDevFlow against a running build — don't write steps or expected results from reading the code alone. Screenshots, exact button text, and computed values (totals, percentages, dates) in the doc must come from what you actually saw rendered, not what the code implies it should render. ### Scenario N — `` - **Steps:** numbered, exact taps/navigation — assume the tester has never used this screen. - **Screenshot:** what the app should look like after the steps. - **Expected result:** the specific thing that proves this scenario passed (not just "looks right" — name the element, state, or text). - **What a failure here would look like:** the concrete wrong outcome a tester might see instead (e.g. "a heart icon is visible here" or "the page shows a blank list instead of redirecting"). **Destructive-action check (do this for every scenario that removes, deletes, or clears anything):** does the button's confirmation friction match what a user would believe is about to happen? A button styled/labeled as destructive (red text, "DELETE", "CLEAR", "REMOVE") needs a genuine arm/confirm double-tap — test it by tapping once and confirming the label changes to a "CONFIRM …" state, then test that CANCEL disarms it without navigating away. If a single tap fires immediately, that's a gap worth flagging even if the underlying action turns out to be recoverable (e.g. archives instead of hard-deletes, per `docs/detail/ENGINEERING-CONVENTIONS.md` § Blazor / CSS class rules) — the mismatch between presentation and actual risk is the finding, not just whether data was technically lost. See AB#2287/AB#2288 (FTDT DELETE) for the pattern. ## What this validates One or two sentences summarizing the end-to-end behavior this walkthrough, taken as a whole, proves works. ## Known gaps / not covered Be explicit about what this walkthrough does *not* prove, so it doesn't silently imply more coverage than it has. Pull from the feature's own spec-doc follow-up/gaps section if one exists rather than re-deriving it.