This chapter is the capstone. Across the previous seven you learned the techniques — risk assessment, test planning, advanced design, cross-browser, accessibility, agile collaboration, documentation. Now you combine them on a single project that mirrors a manual tester's first-job work. By the end you will have a portfolio-quality body of work — a real test plan, real test cases, real bug reports, and a real summary — for a system that resembles real healthcare software. Treat the next three lessons as a workshop, not a reading.
The scenario
You have been hired as the sole QA tester for a startup called HealthBook. The team has built a web-based platform that lets patients in the UK find a doctor, book an appointment, and manage their bookings — all from a browser, no app required. The product is two months from public launch. The CEO has hired you to test it end to end, find what is broken, and produce documentation strong enough to satisfy both the engineering team and the company's prospective enterprise NHS customers.
The product is at the stage where every feature works on a happy path, the visual design is mostly final, and the team is ready for serious quality testing for the first time. They know there are bugs; they have no idea where, how serious, or how to plan around them. That is your job.
What HealthBook actually does
HealthBook supports five core flows for patients, plus a small admin panel for clinic staff:
- Search. Patients filter doctors by speciality (GP, dermatologist, cardiologist, etc.) and location (postcode or city). Results show distance, next available slot, rating, and a short bio.
- Slot selection. A doctor's profile shows their next 14 days of availability as a calendar grid. Patients pick a date and a time slot.
- Booking. A patient with an account confirms the slot, optionally pays a deposit (some private clinics require it), and receives a confirmation email.
- Manage bookings. Patients see all upcoming and past appointments, can cancel or reschedule (subject to a clinic-defined window), and download a calendar invite (.ics).
- Reminders. The system sends a reminder email 24 hours before the appointment, plus an SMS reminder for clinics that have it enabled.
The admin side lets clinic staff add doctors, manage slot availability, and view a list of bookings for the day.
The five flows look simple in a diagram and are anything but in practice — they touch payments, identity, email delivery, calendars, timezones, and clinical scheduling rules. That is exactly why a real QA tester is needed.
Who uses HealthBook
The product has three distinct audiences, each with different testing implications:
- Patients. All ages from 18 to 90. Tech literacy varies wildly — a 25-year-old booking from a phone is a completely different user from a 70-year-old booking from a desktop. Both must succeed.
- Doctors and clinic staff. Use the admin panel daily. Skill profile is closer to a power user; failure tolerance is low because they are working between clinical appointments.
- System administrators. Internal HealthBook staff who configure new clinics, debug payment issues, and respond to support escalations.
Your testing scope covers all three audiences, weighted toward patients because patients are the largest and most varied user group.
The constraints
- Healthcare data. HealthBook stores bookings, basic medical context, and contact details. UK GDPR and NHS Digital DTAC apply; the team is aiming for HIPAA-equivalent practices because they want to expand to the US later. You are not running a security audit, but you must verify obvious things: sessions expire, patient A cannot read patient B's data, exports do not leak.
- Mobile-first audience. 60% of bookings happen on phones. Anything broken at 360px breaks for the majority of paying customers.
- Browser policy. Chrome, Firefox, Safari — latest two versions of each. Edge users get a "use Chrome" banner; older browsers are out of scope.
- A regulated launch. The team will apply for NHS Digital approval after launch. Every artefact you produce will eventually be part of an audit conversation — design the work with that in mind.
What you will produce
Across the next two lessons, you will produce six deliverables. They are scoped so the whole capstone fits inside ten working days — a realistic timeline for the kind of testing a real product hire would do in their first sprint.
- A risk assessment. Identify the three or four highest-risk areas of HealthBook. Justify each rating using the likelihood × impact framing from chapter 1.
- A test plan. Half a page to one page, using the structure from chapter 2: scope (in/out), approach (test types), schedule, risks with mitigations, and entry/exit criteria.
- Twenty test cases. A mix of positive (happy path), negative (invalid input, error states), and edge cases. Cover the search, booking, cancellation, and admin flows. Use the seven-section structure from chapter 7 — every case must be executable by another tester on day three.
- An exploratory testing charter. One time-boxed session of ~45 minutes with a stated mission, target areas, and a debrief log. Record at least five interesting findings, regardless of whether they are bugs.
- Five bug reports. Realistic bugs you might find on a system like this — a date-picker quirk, a Safari-only layout issue, an accessibility miss, a double-booking race, an email-delivery timing issue. Each report uses the seven-field template from chapter 7.
- A one-page test summary report. The output stakeholders will read. Executive summary, scope, results at a glance (with at least one chart), risks, and a release recommendation.
The timeline
Ten working days, two-week sprint. A reasonable allocation:
- Days 1–2: Risk assessment, test plan, environment setup, test data preparation.
- Days 3–6: Write the 20 test cases. Run them against HealthBook. Log defects.
- Day 7: The 45-minute exploratory testing charter. Debrief and log.
- Days 8–9: Write up the 5 bug reports in detail. Verify any fixes the team has shipped.
- Day 10: Compile the test summary report. Present.
Setting up your project
Open a folder on your machine called healthbook-capstone/, and inside it create the eight subfolders from chapter 7 lesson 4: 01_TestPlan/, 02_TestCases/, 03_ExecutionLog/, 04_BugReports/, 05_Screenshots/, 06_SummaryReport/, 07_TraceabilityMatrix/, 08_SignOff/. Every artefact you produce drops into the right folder. By the end, this folder is your portfolio.
There is no real HealthBook URL — you simulate the product mentally with realistic test data. The point is the artefacts, not the bug count. Three weeks from now, when a hiring manager says "show me a piece of testing work you have done end to end," this folder is your answer.
How to work through the next two lessons
Lesson 2 is a guided walkthrough — for each of the six deliverables, it shows what good looks like and leaves the work to you. Lesson 3 is the review — a self-assessment checklist, reflection questions, and a roadmap for what to learn next. Block out roughly five hours and treat the artefacts you produce as work you would be proud to show a hiring manager. The next lesson begins with the risk assessment.