Bridge Exercise: Senior Tester to Test Lead
You’re responsible for quality across the team, not just your own tests. Part 1: review a junior’s test plan and give structured feedback. Part 2: write the entry and exit criteria for a release.
You have just been promoted to Test Lead at ResyncPay — a Wellington SaaS payments platform used by NZ businesses to process supplier invoices. It’s your first sprint in the lead role.
The team is building a new bulk payment upload feature: businesses upload a CSV file containing up to 10,000 payment records and the platform processes them as a batch. The junior tester on your team has submitted a test plan for the feature. Your job: review it, give structured feedback, then write the entry and exit criteria.
Part 1 — Review the Junior’s Test Plan
Read the test plan below. It has three significant issues. Identify them and write structured feedback for the junior tester using the format: “I noticed [observation]. The issue is [problem]. A stronger approach would be [recommendation].”
Bulk Payment Upload — Test Plan v0.1
Write your feedback for the junior tester. Use the format provided. Be direct but constructive — you are developing their skills, not criticising them.
Model Test Plan Feedback
Feedback 1: Entry Criteria
“I noticed the entry criteria says testing will begin when development says it’s ready. The issue is that ‘dev says it’s ready’ is a verbal handoff with no objective check — it means different things to different people and puts QA in a reactive position with no way to push back if what arrives is incomplete. A stronger approach would be to define specific, checkable conditions: the feature code is merged to the test branch, a smoke test passes (existing payment features are still operational), test data is prepared including valid, invalid, and edge-case CSV files, and the API documentation has been reviewed by QA. When all of those are met, testing starts — no earlier.”
Feedback 2: Risk Assessment
“I noticed the risk assessment says ‘not applicable — this is a standard upload feature.’ The issue is that bulk payment processing on a financial platform is not a standard upload feature — it is one of the highest-risk features this team will build. Failures include: processing malformed CSVs silently (payments go missing), duplicate payment records (double-paying suppliers), over-limit transactions bypassing controls, and performance failures on large files. Calling this ‘not applicable’ signals that the risk has not been thought through. A stronger approach would be a brief risk table listing at least three scenarios: what fails, what the business impact is, and how we will test to prevent it. That risk analysis also shapes test priority — which is why it needs to come before the test cases are written.”
Feedback 3: Test Types
“I noticed the test types section only mentions ‘manual testing.’ The issue is that manual UI testing alone will not cover the risks of this feature. Bulk processing at 10,000 records requires API-level testing (upload the CSV directly via the API and verify the response), negative testing (invalid CSV format, duplicate payment IDs, amounts over the account limit), and at minimum a simple performance check (does a 10,000-record file complete within an acceptable time window?). Accessibility and security testing (what happens if someone uploads a CSV with script injection in a field?) should also be considered given the regulatory environment ResyncPay operates in. A stronger approach would be a test type table listing: manual UI testing, API integration testing, negative/boundary value testing, performance baseline, and the rationale for what is being deferred.”
Part 2 — Write Entry and Exit Criteria
Write formal entry and exit criteria for the release of the bulk payment upload feature. These are the contractual conditions between QA and the rest of the team: testing cannot start until entry criteria are met; the release cannot proceed until exit criteria are met.
Think about: what does QA need to be in place before you can test effectively? What must be demonstrably true before you sign off on a release of a financial payments feature?
Entry and Exit Criteria — ResyncPay Bulk Payment Upload
Entry Criteria (testing can begin when ALL are met)
- ✓ Feature code merged to the test branch and deployment confirmed by DevOps
- ✓ Smoke test passes: all existing payment features (single payment, payment history, account management) are operational in the test environment
- ✓ Test data prepared: CSV files with valid records, invalid format, duplicate payment IDs, over-limit amounts, and an edge-case file at exactly 10,000 records
- ✓ API documentation updated to reflect the bulk upload endpoint and reviewed by QA
- ✓ Acceptance criteria reviewed and signed off by the Product Owner before testing begins
- ✓ Test environment is isolated from production data — confirmed by DevOps
Exit Criteria (release can proceed when ALL are met)
- ✓ All P1 and P2 test cases passed (no outstanding P1 or P2 defects open)
- ✓ P3 defects documented with explicit risk acceptance sign-off from the Product Owner and Engineering Lead
- ✓ Performance threshold met: bulk upload of 10,000 records completes within 5 minutes from file submission to final processed status
- ✓ Error handling verified for all defined error types: invalid CSV format, duplicate payment IDs, over-limit transactions, and malformed amount fields
- ✓ API integration tests passing: upload endpoint, status polling endpoint, and error response format verified against API documentation
- ✓ QA sign-off document completed, reviewed, and countersigned by the Product Owner
- ✓ Regression suite passes: no regressions in existing single-payment functionality
Senior engineer insight
The hardest thing about moving into the Test Lead role is realising your job is no longer to find the most bugs — it’s to make sure the right bugs get found by the right people at the right time. For years your instinct was to dive in and test; now your first question has to be “who owns this area and do they have what they need to test it well?” That shift from individual contributor to multiplier is where most promotions stall.
The most common mistake: new Test Leads keep doing their old senior tester job in full, then try to squeeze in the lead responsibilities on top. They end up exhausted, the team gets minimal oversight, and nothing improves. The lead role only works if you genuinely hand off testing execution.
From the field
At a Wellington government agency, a newly promoted Test Lead spent the first three sprints assuming her team would escalate blockers to her — that’s what she’d done as a senior tester. Instead, a junior quietly marked twelve test cases as “passed” to avoid slowing the sprint, and the issues surfaced in UAT two weeks later. In NZ public sector projects the Test Lead is named on the sign-off register — those UAT defects became her defects on the audit trail. She immediately introduced a mid-sprint check-in: fifteen minutes, every Wednesday, where each tester walked through one “interesting” test result. Within a fortnight the team was surfacing blockers before end-of-sprint. The lesson: influencing without authority only works when you create the structural moment for it — people don’t escalate by default, they escalate when there’s a safe, low-friction channel to do it.
Why teams fail here
- The new lead keeps doing senior tester work in full and treats lead responsibilities as add-ons — team gets shallow oversight, lead burns out within two sprints
- Feedback to junior testers is either too vague (“this needs to be better”) or delivered as a rewrite rather than a teachable moment — skill gaps persist and the lead creates a dependency
- Entry and exit criteria are written after testing has already started, or left as copy-paste boilerplate — they lose their contractual force and no one enforces them at release
- Risk assessment is skipped or trivialised on features that “seem straightforward” — on financial platforms in particular, the most catastrophic failures always come from features that looked low-risk on paper
Key takeaway
A senior tester is measured by the quality of their own test cases; a Test Lead is measured by the quality of the team’s test cases — and the two jobs require completely different instincts.