Regression & Smoke Test Communication

Regression testing specifically targets the risk that new changes break existing functionality.

A smoke test is fast and shallow — it confirms the build is deployable and basic features work, but does not re-verify the entire suite. A sanity test is a targeted, narrow check on one recently changed area — not the full suite. Exploratory testing is unscripted and session-based. Only regression testing describes the systematic re-execution of existing test cases across the product to catch unintended side effects — making Option C the most accurate answer.

Key vocabulary:
• Regression test — re-execution of existing tests after a change to confirm no breakage
• Smoke test — quick, shallow check that the most critical paths work after a new build
• Sanity test — narrow, targeted re-test of a specific recently changed area
• Side effect — an unintended change in behaviour caused by a modification elsewhere in the code

Test coverage discussions require specific numbers, named components, and explanations for gaps.

Options A and B use hedge language ("most of it", "good", "around 70%") that signals imprecision and reduces trust. Option D deflects the question without answering it — unhelpful in a sprint review context. Option C provides exact percentages per component, identifies what the uncovered 18% represents (error-handling branches), and explains the mitigation (manual exploratory tests) — demonstrating QA mastery and enabling an informed conversation about release readiness.

Key vocabulary:
• Statement coverage — the percentage of code statements executed during test runs
• Branch coverage — the percentage of conditional branches (if/else paths) exercised by tests
• Error-handling branch — code paths triggered only by infrastructure failures, timeouts, or exceptions
• Exploratory test — an unscripted, experience-based test session that complements scripted automation

A blocking defect in regression must be communicated with its Jira ID, impact scope, and an explicit call for a decision.

Option A is too casual — logging a bug without explaining its downstream impact fails to convey urgency. Option B is dismissive ("something to keep an eye on"). Option C is factually wrong: if the order submission flow is completely broken, it cannot be classified as non-blocking — calling something non-blocking when it is blocking creates serious release risk. Option D is correct: it names the defect (REG-112), specifies the blocking impact (other modules cannot be tested), and requests a formal team decision — giving leadership the information needed to act.

Key vocabulary:
• Blocking defect — a defect that prevents continued testing or release of affected functionality
• Non-blocking defect — a defect that does not prevent release; a workaround or deferral is acceptable
• Go/no-go decision — a formal team decision on whether to proceed with a release
• Dependent module — a feature or component whose testing depends on another module working correctly

A sprint test summary must provide quantified metrics, open defect IDs, and an explicit release recommendation.

Options A and B are narrative summaries that lack the data precision stakeholders need to make release decisions. Option D deflects to a tool link without providing the summary itself — unhelpful in a standup or sprint review. Option C includes all the required elements: sprint identifier, total TCs, breakdown by status with percentages, open defect IDs by priority, and a clear recommendation — enabling the PO and SM to make an informed go/no-go decision on the spot.

Key vocabulary:
• Test execution summary — a report of test case results by pass/fail/blocked/not-run status
• P1 defect — a high-priority defect that must be resolved before release
• Conditional release — approval to proceed with deployment under specific conditions (e.g. fix two P1s first)
• Sprint velocity — the number of story points completed in a sprint, used alongside QA metrics

A professional Go/No-Go statement specifies the defect status by priority, deferred items, approval status, and exit criteria.

Options A and B use hedge language and lack supporting evidence — "I think" and "looks good" are not sufficient for a production release decision. Option D is equally vague — calling a No-go without specifying which defects or what threshold was not met leaves the team without direction. Option C is the professional standard: it confirms P0/P1 resolution, documents deferred P2s with formal sign-off, references exit criteria, and delivers a clear recommendation — creating an auditable release decision record.

Key vocabulary:
• Go/No-Go decision — a formal binary release recommendation based on defined criteria
• Exit criteria — the defined conditions that must be met for testing to be declared complete
• Deferred defect — a known issue acknowledged but intentionally postponed to a future sprint
• Business sign-off — written approval from product ownership to accept a known risk or deferral