Bridge Exercise: Mid-Level to Senior Tester
You’ve written the tests. Now design the strategy. Part 1 is analysing a test suite for coverage gaps. Part 2 is proposing a risk-based testing strategy for a release.
A Christchurch health tech startup, MedSync NZ, is releasing v2.0 of their patient appointment booking platform. The platform is used by patients to book GP appointments and receive SMS and email confirmations.
The existing Playwright suite has 40 happy-path UI tests, 0 API tests, and 0 tests for the patient notification system (SMS + email). Your job: assess what is missing and propose what to test before v2.0 goes live.
Part 1 — Identify 3 High-Risk Coverage Gaps
Review the current test suite inventory below. Identify the three coverage gaps that are highest risk given the application type — a patient health platform where failures have direct consequences for patient care.
| Area | Tests | Coverage notes |
|---|---|---|
| Login flow | 4 | Happy path only |
| Appointment booking | 12 | Happy path + one cancellation scenario |
| Patient profile update | 6 | Happy path only |
| GP dashboard | 8 | Happy path only |
| Notification sending (SMS + email) | 0 | No tests at all |
| API layer | 0 | No tests at all |
| Concurrent booking conflict | 0 | No tests at all |
| Error recovery (network failures) | 0 | No tests at all |
For each of your top 3 gaps: name the gap, explain why it is high risk for a patient health platform specifically, and describe what could go wrong if it is not tested before v2.0 ships.
Top 3 High-Risk Coverage Gaps
Gap 1: No notification tests (SMS + email)
Notifications are the primary mechanism through which patients know their appointment is confirmed. If the notification system fails silently — the booking goes through but no SMS or email is sent — patients may miss their appointments. Missed GP appointments have real health consequences. This is not a UX issue; it is a patient safety issue.
What goes wrong: A code change in v2.0 breaks the Twilio SMS integration. All bookings succeed in the database. Zero patients receive confirmations. The defect is discovered when patients call the clinic to confirm appointments that they never received a confirmation for.
Gap 2: No concurrent booking conflict tests
Two patients can attempt to book the same GP at the same time slot simultaneously. Without a concurrency test, the platform may double-book appointments. A GP arriving to find two patients expecting the same slot is a real operational failure. Manual testing cannot reproduce this scenario — it requires concurrent API calls or at minimum a test that sends two booking requests for the same slot in rapid sequence.
What goes wrong: Under the load of v2.0’s increased user base, double-bookings begin occurring during peak morning booking times (7–9am). Discovered by GP practices reporting scheduling conflicts.
Gap 3: No error recovery tests (network failures)
If the booking API times out mid-request, the patient needs to know clearly whether their appointment was created or not. An ambiguous outcome — spinner running, no confirmation, no error — may cause patients to attempt to rebook (creating duplicates) or assume they are booked when they are not (causing missed appointments). Health platforms require deterministic error states.
What goes wrong: Third-party scheduling API experiences a 30-second timeout spike. Patients see a loading spinner that never resolves. Some book again; others assume the original booking went through. Clinic receives 200% of expected bookings for that period.
Part 2 — Write a Risk-Based Testing Priority List
Given the v2.0 release scope, write a risk-based testing priority list for the release. Assign each area to P1 (must test before release), P2 (test but can defer to early post-release if needed), or P3 (defer to v2.1). Justify each priority decision.
Think about: what is the worst-case impact of a failure in each area? What would clinical staff, patients, and MedSync leadership consider unacceptable?
Risk-Based Testing Priority Matrix — MedSync NZ v2.0
- Concurrent booking conflict: Double-booking a GP appointment is a direct operational failure affecting patient care. Zero tolerance.
- Notification delivery (SMS + email): Patients missing appointments due to no confirmation is a patient safety and regulatory risk. Must verify both channels deliver successfully before v2.0 ships.
- API error handling: Ambiguous failure states on booking create duplicate bookings or missed appointments. The platform must return a clear, deterministic error state within a defined timeout.
- Login security (negative paths): The existing 4 tests cover happy path only. Account lockout, brute force prevention, and session expiry must be tested before launch — health platforms are a target for credential attacks.
- Advanced GP dashboard filtering and bulk management: Failure affects GP efficiency but not patient safety. P2 is acceptable if sign-off is obtained from the clinical lead.
- Patient profile update edge cases: Missing middle name, long address strings, international characters in te reo Māori names. Lower risk than booking integrity but important for data quality.
- API layer baseline tests: Start with the booking, cancellation, and notification endpoints. Full API test suite can be phased.
- UI edge cases on unsupported browsers (IE11, older mobile Safari). No active users reported on these browsers in analytics.
- Advanced recurring appointment patterns (monthly repeat bookings) — not in scope for v2.0 feature set.
- Performance testing at 10× current load — v2.0 does not change the infrastructure tier. Defer until v2.1 scales the platform.