Guided Walkthrough — Test Plan, Test Cases, and Execution

This is the guided part of the capstone. For each of the six deliverables you committed to in the previous lesson, this walkthrough shows you what good looks like, walks through a worked example you can adapt, and leaves you the work of producing your own. The aim is not to copy what is shown — it is to model your own version on it. By the end of this lesson you will have produced everything except the final review.

Step 1 — Risk assessment

Use the likelihood × impact matrix from chapter 1 on every major area:

• High (red). Booking flow (race conditions, double-booking prevention, deposit payment). Cancellation and refund logic (windows, partial refunds, payment reversal). Patient data security (session expiry, cross-account access, exports).
• Medium (amber). Search and filtering (postcode validation, distance, "no results" UX). Email and SMS notifications (timing, content, mail-client rendering). Reminder scheduling (timezones, DST).
• Low (green). Static pages (FAQ, About, Privacy). Doctor profile display once data is loaded. Branding.

That allocation tells you where the bulk of your test cases and exploratory time should land — red areas get most coverage; static pages get a smoke check. Save in 01_TestPlan/risk-assessment.md.

Step 2 — Test plan outline

A working one-page plan for HealthBook:

Scope (in). Patient-facing search, slot selection, booking, cancellation, rescheduling, manage-bookings, account log-in/sign-up, and basic admin-panel checks (add doctor, set availability). Cross-browser smoke on Chrome/Safari/Firefox latest. Mobile responsive checks at 360px, 768px, 1280px. Accessibility basics (keyboard, contrast, labels) on the booking flow.

Scope (out). Load and performance testing. Full security audit (penetration testing, OWASP top-10). Native mobile apps (web only). Production payment provider — sandbox only.

Approach. Functional manual testing for happy and error paths; exploratory testing for one 45-minute session on the booking flow; cross-browser smoke; accessibility audit using the six-check method from chapter 5.

Estimation (three-point). Booking flow: O 4h, L 6h, P 10h → 6.3h. Cancellation: O 3h, L 4h, P 7h → 4.3h. Search: O 2h, L 3h, P 5h → 3.2h. Admin: O 2h, L 3h, P 4h → 3h. Cross-browser: 4h. Exploratory: 45m. Bug verification buffer: 4h. Total ≈ 25h spread across days 3–9 of the sprint.

Risks. SendGrid sandbox email delivery has been flaky in past tests — mitigation: alternate provider seeded. Real Stripe sandbox sometimes drops connections — mitigation: always retry once before filing.

Entry criteria. Build deployed to staging; test data seeded (10 doctors across 3 clinics, 5 test patients with varied states); SendGrid and Stripe sandboxes operational.

Exit criteria. All 20 planned cases executed; no open P1/P2 defects; cross-browser smoke green; exploratory log attached.

Save in 01_TestPlan/test-plan.md.

Step 3 — Sample test cases

Six fully-written cases as a model. The full deliverable is twenty.

TC-101 — Book an appointment (happy path). Preconditions: logged in as patient+verified@test.healthbook.dev, ≥ 1 doctor with availability. Steps: search by postcode, pick Dr Patel, click 9:30 slot, click "Book appointment." Expected: redirect to /bookings/{id} within 2s, confirmation email queued in SendGrid sandbox within 30s, .ics link visible.

TC-102 — Double-booking prevention. Preconditions: slot already booked by patient A. Steps: as patient B, attempt the same slot. Expected: server rejects HTTP 409, UI shows "This slot was just taken — please choose another," no booking created, no email sent.

TC-103 — Cancel within window. Preconditions: appointment 5 days away, policy 24h. Steps: /bookings → "Cancel" → confirm. Expected: status "Cancelled," email sent, deposit refunded within 5s on Stripe sandbox.

TC-104 — Cancel outside window. Preconditions: appointment 12h away, policy 24h. Steps: same as TC-103. Expected: refused with "This appointment is within the 24-hour cancellation window — please contact the clinic." No status change, no refund, no email.

TC-105 — Search with no results. Steps: search Speciality = Neurosurgeon, Postcode = TR21 0LL (Isles of Scilly — none listed). Expected: "No matches in your area" with a "Search nearby" suggestion. No empty grey panel.

TC-106 — Book with screen reader (accessibility). Preconditions: VoiceOver on (Cmd+F5), logged in. Steps: tab through the calendar grid, select a slot via keyboard, tab to "Book appointment," press Enter. Expected: each slot announces date/time/state ("9:30, available, button"); confirmation page heading read on landing.

Save in 02_TestCases/test-cases.csv — one row per case, eight columns (ID, title, preconditions, steps, expected, actual, status, priority).

Step 4 — Exploratory testing charter

Charter: Explore the booking flow with edge cases and unusual inputs to find bugs the structured cases would miss. Time-box: 45 minutes. Areas: date/time edge cases (cross-timezone midnight booking, DST transitions, weekends with reduced availability, bank holidays); concurrency (two tabs booking the same slot); email content (iOS Mail subject, Outlook web rendering); mobile keyboard at 320px; currency rounding on .99 deposits. Method: 5–7-minute mini-sessions, time-stamped notes, file anything that looks like a bug.

After the session, debrief in writing: findings, gaps, follow-ups. Save in 03_ExecutionLog/exploratory-charter.md with the session log alongside.

Step 5 — Sample bug reports

Two examples as a model. The full deliverable is five.

BUG-001 — Deposit total displays £20.00 for an item priced £19.99 (rounding). Environment: Chrome 127 / macOS Sonoma; reproduced on Safari 17 / iOS 17. Build #4421. Steps: book Dr Patel (deposit £19.99) and proceed to confirmation. Expected: £19.99. Actual: £20.00, persists in the receipt email. POST /bookings returns deposit: 1999 correctly in pence; front-end currency formatter is rounding wrong. Severity: High. Priority: P1.

BUG-002 — Calendar slots not announced as buttons by VoiceOver. Environment: Safari 17 / macOS Sonoma 14.4, VoiceOver on. Steps: open Dr Patel's profile, tab into the slot grid. Expected: "9:30, available, button." Actual: only "9:30" — no role, no state. The slots are rendered as <div onclick=...> rather than <button>. Severity: Medium. Priority: P2 (affects screen-reader users, a meaningful audience fraction).

Save in 04_BugReports/ as one Markdown file per bug, named BUG-NNN_<short-title>.md.

Step 6 — Test summary report

A working one-page summary at sprint end:

HealthBook capstone — test summary. 20 cases executed, pass rate 80% (16/20). 4 failures tied to 5 defects — 2 P1 (BUG-001, BUG-005) and 3 P2/P3. Cross-browser smoke green on Chrome and Firefox; one Safari-only layout issue (BUG-003) tracked. Accessibility audit passed 4 of 6 dimensions; 2 failures (BUG-002 keyboard label gap, plus a "Forgot password?" link contrast failure).

Risks. Production payment not tested — Stripe sandbox only. Bank-holiday and DST handling flagged in exploratory but no real holiday falls in the test window; recommend follow-up in December. Outlook web rendering of confirmation emails needs a follow-up before launch.

Recommendation. Not yet releasable. The two P1 defects (BUG-001 deposit rounding, BUG-005 double-booking race) must be fixed and verified. Accessibility issues should be fixed before NHS Digital approval is sought.

Save in 06_SummaryReport/summary.md with a one-page export to PDF.

What you should have at this point

Eight folders, each with the named artefacts: a risk assessment, a test plan, twenty test cases, a 45-minute exploratory log, five bug reports, and a one-page summary. That is exactly the body of work a real first-week QA hire would produce. The next lesson is the review.