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.
Senior engineer insight
The shift from mid-level to senior tester is not about knowing more test techniques — it is about changing the unit of work you think in. Mid-level testers think in test cases. Senior testers think in risk exposure: what is the worst thing that can happen, who bears the consequence, and how much confidence do we need before we ship? The moment I stopped asking “have I covered the requirements?” and started asking “would I be comfortable explaining this release sign-off to a clinical director?” was the moment my career changed.
The most common mistake: teams promote their best mid-level tester to senior, then measure them by the same output metrics — test count, pass rate, defect count. Senior testers create value through decisions and influence, not volume. If a newly promoted senior is still primarily measured on how many test cases they write, the team has not actually changed the role.
From the field
A Wellington government agency promoted a strong mid-level tester into a senior QA role on a critical welfare payments system. The team assumed the promotion was largely ceremonial — same work, higher pay, maybe some mentoring. What they discovered six months later was that the tester was still operating exactly as before: thorough test execution, solid defect logging, clean reports. What was missing entirely was upstream influence — they were not in requirements reviews, not challenging architecture decisions, not flagging that a proposed database migration had no rollback plan documented. The release went live with the migration; the rollback had not been tested; a partial failure left 1,200 payment records in an inconsistent state. The fix took 11 days. The lesson that generalises: in NZ public sector, senior tester expectations lean heavily toward governance and risk ownership, not just execution quality. A senior tester who only executes is a mid-level tester with a different job title.
Why teams fail here
- Treating the transition as a skills upgrade rather than a role change — senior testers are responsible for test strategy and quality confidence, not just better test execution. Teams that do not reframe the role set the tester up to fail.
- No seat at the table upstream — NZ senior testers are expected to influence design and requirements, not just review them after the fact. If the senior tester is only involved after stories are written, the most valuable quality work has already been missed.
- Leadership signals are invisible — newly promoted testers default to what they know (execution) and avoid the uncomfortable visible acts that define seniority: pushing back on a release, escalating a risk to a project manager, proposing a testing approach that will delay a sprint. Teams rarely coach these behaviours explicitly.
- Depth vs breadth confusion — NZ hiring managers for senior QA roles expect depth in one area (automation, security, exploratory testing, or performance) plus credible breadth across the rest. Candidates who are broadly average across all areas and deep in none are consistently passed over, yet most mid-level testers prepare by studying breadth rather than sharpening a specialism.
Key takeaway
A senior tester is not someone who writes better tests — they are someone who decides which tests are worth writing, convinces the team of risks they cannot yet see, and owns the quality confidence of the release, not just the test results.