PM wants to start system testing a critical, overdue release, but dev's unit tests are incomplete. What's your immediate strategy?

Overview

This scenario probes a QA Lead's ability to navigate high-stakes delivery pressure while upholding quality standards. It challenges them to define and enforce testing entry criteria under duress, demonstrating risk management and strategic stakeholder communication.

Interview Question:

PM wants to start system testing a critical, overdue release, but dev's unit tests are incomplete. What's your immediate strategy?

Expert Answer:

The immediate strategy revolves around pragmatic risk management and transparent communication, rather than a flat "no." My goal as a QA Lead is to ensure efficient and effective testing, even under pressure.

1. Immediate Information Gathering & Risk Assessment:

   • Dev Lead Sync: First, I'd connect directly with the Development Lead to understand the scope and impact of "incomplete unit tests." Are we talking about minor coverage gaps or fundamental instability in critical paths? This determines our inherent quality risk.
   • Build Health Check: Review the latest build's CI/CD pipeline results. Are there any critical failures, integration issues, or significant regressions indicated by automated checks?
   • Stakeholder Context: Understand the PM's urgency. What's driving the "overdue" status, and what are the downstream implications of further delays versus quality compromises?

2. Defining (or Adapting) Entry Criteria:

   • Standard Definition: My standard entry criteria for system testing include: code complete for the planned scope, no showstopper defects from previous phases (e.g., integration testing), all critical unit tests passing, and a stable build deployed to the test environment.
   • Situational Adaptation: Given the pressure and incomplete unit tests, a strict adherence might halt progress. I'd propose a "Go/No-Go" decision based on:
     • Critical Path Stability: Are the core business flows and high-impact features covered by passing unit tests or confirmed stable through other means (e.g., successful integration tests, early developer sanity checks)?
     • Known Risk Acceptance: Clearly document the risks associated with starting system testing with incomplete unit tests (e.g., higher Defect Leakage Rate, increased Defect Reopen Rate due to unstable builds, extended test cycles). Get explicit agreement from Dev and Product on accepting these risks.
     • Minimal Viable Quality Baseline: Define the absolute minimum acceptable quality level for the build to begin system testing. This might mean "no known critical or major functional defects," even if some unit tests are still pending.

3. Execution Strategy & Team Coordination:

   • Prioritization: If we proceed, I'd collaborate with the Dev Lead to identify the highest-risk modules or features lacking unit test coverage. My team's test efforts would be surgically prioritized to aggressively target these areas.
   • Delegation & Mentoring: Assign senior QA Engineers to the highest-risk areas for focused exploratory testing and deep functional validation. Mentor the team on how to efficiently identify, reproduce, and report defects under pressure, emphasizing clear root cause analysis (e.g., build instability vs. functional bug).
   • Adaptive Test Plan: Update test plans to reflect the shifted risk profile. Increase focus on integration points and end-to-end flows that might be exposed due to weaker component-level testing. Ensure Requirement Coverage for critical paths remains paramount.

4. Stakeholder Communication & Release Readiness:

   • Transparency: Communicate the revised entry criteria and the associated quality risks transparently to the Product Manager and Development Lead. Highlight the potential impact on Test Execution Progress and the overall timeline.
   • Metrics for Decision-Making:
     • Defect Leakage Rate: Emphasize that starting prematurely will likely inflate this metric, leading to more costly fixes post-release.
     • Defect Reopen Rate: Unstable builds often result in higher reopen rates, signaling inefficiency.
     • Test Execution Progress & Requirement Coverage: Track these meticulously to provide real-time status updates and demonstrate where quality gaps might exist.
     • Regression Coverage: If we bypass unit test completeness, we must ensure critical regression packs are executed effectively on stable parts of the build.
   • Release Decision: Ultimately, the release decision will be a shared one, but my recommendation will be data-driven. A low UAT Pass Rate or persistent showstopper defects discovered late due to early entry would be clear indicators to hold the release. My role is to provide the clearest picture of quality and associated risks to enable an informed go/no-go decision.

Speaking Blueprint (3-Minute Verbal Response):

[The Hook] "I understand the urgency around this critical, overdue release, and the PM's desire to kick off system testing. However, the information that developer unit tests are incomplete immediately raises a significant flag for me. Prematurely starting system testing on an unstable foundation doesn't accelerate delivery; it almost always introduces significant quality risks, increasing our Defect Leakage Rate and potentially pushing our release further out due to rework and instability."

[The Core Execution] "My immediate action would be a rapid sync with the Dev Lead. I need to understand the scope of these incomplete unit tests – are we talking about a few non-critical components, or core business logic? Concurrently, I'd clearly articulate to the Product Manager that our standard entry criteria for system testing require a stable, functionally complete build, validated by passing unit tests for the core features. If we must proceed under this pressure, we'll need to agree on a minimal viable entry criteria that focuses heavily on the stability of critical paths. I'd propose we verify if the highest-priority features are stable enough to proceed, even if other areas are pending unit tests.

If we get the green light, my team won't just 'start testing everything.' We'll pivot. I'll strategically assign our senior QAs to conduct focused exploratory testing on the areas identified as high-risk due to missing unit tests, prioritizing Requirement Coverage for the most critical features. We'll meticulously track Test Execution Progress daily and ensure rapid defect reporting and triage. I'll also mentor the team on how to identify whether a bug is a functional defect or a symptom of build instability, directly impacting our Defect Reopen Rate. Transparent communication of these risks, our progress, and any critical blockers to both Dev and Product will be continuous."

[The Punchline] "Ultimately, my leadership philosophy here is about intelligent risk mitigation. We're not just gatekeepers; we're strategic partners in delivery. My goal is to maximize our QA team's efficiency and ensure we deliver a high-quality product, not just a fast one. By pushing for a stable entry point, or at least understanding and mitigating the risks if we can't get one, we avoid the costly cycle of 'test-fix-retest' on unstable builds. This disciplined approach is what truly supports a smoother UAT Pass Rate and ensures we meet our release objectives with confidence."