🗓️ 14-Day QA Lead Prep Plan

// STUDY

• Test strategy components: scope (what to test and, crucially, what NOT to test), approach (test types, levels, and ownership), environment and data needs, and the metrics that tell you whether the strategy is working — and the difference between a strategy document and a test plan
• Risk-based prioritisation: likelihood × impact matrices, how to map technical risk to business impact, and how to justify coverage decisions when resources are constrained — the failure mode of treating a risk matrix as a compliance artefact rather than a decision tool
• Quality metrics: defect escape rate, defect detection efficiency, MTTR, and test execution coverage — what each measures, what it does NOT tell you, and how to present metrics to a director without misleading them with coverage percentages
• Shift-left in practice: getting into planning and design review rather than waiting for a build to test — how to raise concerns about requirements ambiguity, testability gaps, and design trade-offs before a single line of code is written

// PRACTISE

• Draft a 1-page test strategy for a greenfield e-commerce platform (checkout, search, user accounts, payment integration): define the scope, approach, risk priorities, and 3 quality metrics you would track — write it as you would present it to an engineering director, not as a personal study note
• Build a risk matrix for the same platform covering 6 areas of risk: score each by likelihood and impact, and write a one-sentence business justification for your top 3 risks that a product manager could understand without testing vocabulary
• Write a 200-word 'what we will NOT test and why' section — practise justified descoping: each omission requires a reason (low risk, cost-prohibitive, covered by unit tests), not just a list

// STUDY

• Mentoring and feedback: how to give specific, actionable feedback that improves performance without undermining trust — the difference between feedback someone can act on immediately and feedback that just creates anxiety without a clear path forward
• QA in Agile ceremonies: what a QA lead contributes at refinement (testability questions, acceptance criteria review), sprint planning (effort estimation, risk flags), retrospectives (quality trends, not just bugs), and daily stand-up (blocker escalation) — showing up with an agenda, not just presence
• Estimation and planning: decomposition-based effort estimation for a sprint test scope, analogy-based estimation for uncertain new features, and how to communicate a range rather than a false-precision number to a product owner who is already under deadline pressure
• Hiring and onboarding: what to look for beyond tool knowledge (reasoning under ambiguity, communication quality, learning mindset), how to structure a practical hiring exercise that reveals thinking rather than memorisation, and what a 30/60/90-day onboarding plan looks like for a new QA engineer

// PRACTISE

• Write a structured feedback conversation plan for a junior tester who continues to log bugs with insufficient reproduction steps despite two previous conversations: include what you say, what you listen for, and what the next step is if behaviour does not change after this conversation
• Draft a 30-60-90 day onboarding plan for a new mid-level QA engineer joining a team with existing automation infrastructure — specify what they learn, what they own independently, and how you measure their progress without micromanaging
• Write a sprint test effort estimate for a new payment flow with no existing automation: break down the effort by activity, flag the dependencies and risks, and format it so a product manager can include it in sprint planning without asking follow-up questions

// STUDY

• Go/no-go decision frameworks: assessing open defects by user impact, revenue exposure, reversibility, and workaround availability — translating severity ratings into business language a VP can act on rather than a test coverage percentage they cannot
• Communicating risk to non-technical stakeholders: framing testing outcomes as business risk (not pass/fail percentages), knowing when to recommend a conditional release with a mitigation plan versus an outright hold, and how to maintain the quality position when a product owner pushes back
• Post-mortems and escaped defects: running a blameless retrospective on a critical production defect that passed QA — how to present root cause and prevention actions to leadership, and how to rebuild team confidence and trust after a quality incident
• When not to automate: return-on-investment calculations for a brittle UI test suite, the false economy of 100% automation coverage, and how to make the case to an engineering manager for keeping some test types manual on a principled cost-benefit basis

// PRACTISE

• Given a release with 4 open defects — a critical login failure on one specific browser, two medium UX regressions, and one low performance warning on mobile — write a go/no-go recommendation memo in two versions: one for the engineering team (technical framing) and one for the product VP (business impact and risk framing)
• Fill in a post-mortem template for a hypothetical escaped defect: a 30-minute checkout outage caused by a configuration change that QA did not catch — include a timeline of events, root cause, and 3 specific process changes you would recommend to prevent recurrence
• Write a 5-minute verbal release presentation for: 'We have completed the regression suite for the new payments release. Here is what you need to understand before we decide whether to ship tonight.' — practise translating test data into a recommendation a CEO could act on

// STUDY

• Behavioural bank: escaped defect after QA sign-off, a developer team consistently deprioritising defects, a senior tester resistant to a tooling change — review every answer where you gave a principle rather than a specific situation, action, and outcome
• Scenario bank: structured 'what would you do' questions on test strategy from scratch, a team under delivery pressure cutting quality corners, a stakeholder dismissing your quality concerns — practise the STAR shape before the interview, not during it
• JIRA for QA leads: building a sprint quality report from JIRA data, tracking defect trend across multiple sprints, defining what 'done' looks like in JIRA terms for a test story — the operational side of quality reporting interviewers probe at senior level
• Re-read your test strategy document, risk matrix, and post-mortem from earlier in the plan — prepare to defend any decision in them for up to 5 minutes of follow-up questions without revisiting your notes

// PRACTISE

• Answer 10 questions aloud from the behavioural and scenario banks — aim for 2 minutes per answer, reflecting the seniority of the role; use STAR structure throughout and draw on real or realistic situations
• Identify your 5 weakest answers and rewrite them with concrete examples: specific decisions you made, actions you took, and results you can name — not generic principles about what a good QA lead does
• Run a 30-minute mock: present your test strategy document to a colleague acting as a stakeholder, then field a go/no-go scenario where they push back on a hold recommendation — practise maintaining the quality position clearly and respectfully under commercial pressure