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