Section 2 Solutions

These are the answers to the Section 2 Review's Knowledge Check. If you haven't attempted the four scenarios yet, do that first.

Scenario 1: The Two-Week Crunch

Correct answer: The combination of impact and likelihood, per Risk-Based Strategy — rate each of the five areas on both factors and allocate effort disproportionately toward the highest-risk combinations.

Explanation: This is the module's own opening scenario restated — spreading effort evenly across all five areas, regardless of their actual risk, leaves the highest-risk areas under-tested.

Alternative approaches considered: Prioritizing by complexity alone, or by which areas are most familiar, ignores impact entirely — a simple but low-impact area doesn't deserve the same attention as a complex, high-impact one.

Real-world reasoning: Tests whether the two-factor (impact and likelihood) method was understood as the actual mechanism, not just "focus on what matters."

Scenario 2: The Faster Cadence

Correct answer: No — the existing checklist needs a genuinely rebuilt approach, not a compressed version, per Release Strategy. Twice-weekly releases need heavier investment in automated regression and likely feature flags, with manual effort concentrated on genuinely novel or high-risk changes.

Explanation: This is the module's own core lesson — a testing approach built for one release model doesn't survive being applied unchanged to a faster one; it needs to be redesigned around the new model, not sped up.

Alternative approaches considered: Simply asking the team to "test faster" against the same checklist just compresses time pressure without addressing the actual structural mismatch.

Real-world reasoning: Tests whether "rigor shifts location, not just speed" was understood as the fix, not just "do the same thing quicker."

Scenario 3: Three Definitions of "Critical"

Correct answer: A shared severity and risk vocabulary, per Organization-Wide Quality Strategy. What shouldn't change: each team's own day-to-day testing approach and product-specific decisions, which should stay with the teams closest to that product.

Explanation: This connects directly to the module's central distinction — shared vocabulary and classification genuinely benefit from central consistency, while team-level execution decisions don't.

Alternative approaches considered: Mandating one identical testing process across all three teams overcorrects — the actual gap is in comparable classification, not in process uniformity.

Real-world reasoning: Tests whether the specific distinction (centralize vocabulary and cross-cutting risk, not team-level execution) was understood, not just "standardize things."

Scenario 4: The 40-Page "Strategy"

Correct answer: They received a test plan, not a strategy, per What Is Test Strategy?. What's missing: risk priorities and the reasoning behind them, an explicit testing approach by risk area, and a stated quality bar for release — none of which a test-case list provides.

Explanation: This is that module's own opening scenario restated — a document detailed and specific enough to be a plan isn't a strategy, and stops being useful the moment its specifics change.

Alternative approaches considered: Assuming the document is simply "too detailed" but otherwise a valid strategy misses the actual problem — it's answering the wrong question entirely (what, not how and why).

Real-world reasoning: Tests whether the strategy-versus-plan distinction was understood as a difference in kind, not just a difference in length or detail level.

Section 2 Complete

Across four modules, this section built the strategic foundation for everything from here forward: what a test strategy actually is, how to allocate limited effort using risk, how to adapt that approach to how a product actually ships, and how to extend a single-product strategy across an entire organization. From here, continue to Section 3 — Leadership, starting with Leading Without Authority.