Release Readiness Report

Requirements

• 1.Read and synthesise the provided test run summary, defect list, and regression status into a structured report — interpret the data rather than restating it; note that 9 of 14 failures share a single root cause, and that 2 failures are likely flakes, not real defects
• 2.Triage each open defect by severity and assess its release impact: classify each as a blocker, an acceptable risk with a documented mitigation, or a deferral candidate — and provide a one-line rationale for each classification
• 3.Assess the completeness of test coverage: identify the gap created by the partial reporting-module regression and state how that gap affects your confidence in the go/no-go recommendation
• 4.Review the environment and configuration state: confirm or flag any risks related to feature flag parity between staging and production, database version alignment, or outstanding infrastructure changes
• 5.Write an unambiguous go/no-go recommendation backed by at least two specific data points from the provided summary — the recommendation must be evidence-based, not a gut call, and must include a conditional path if a mitigation could change the outcome
• 6.Define rollback triggers: specify at least two observable, measurable conditions that would cause the on-call team to initiate a rollback in the first hours after deployment — vague triggers ('if things go wrong') do not satisfy this requirement
• 7.Write the report in a structure that serves two audiences simultaneously: an executive summary paragraph that a non-technical product manager can act on, and detailed findings sections that an engineering manager can use to make and justify decisions

Starter data

Expected deliverables

• ✓A structured release readiness report with all seven sections clearly labelled: Executive Summary, Test Results Summary, Defect Triage, Coverage Gaps, Environment and Configuration Assessment, Go/No-Go Recommendation, Rollback Plan and Triggers
• ✓A defect triage table listing every open defect with: severity, current status, release impact classification (blocker / acceptable risk / deferred), and a one-line rationale for the classification
• ✓A go/no-go recommendation that is explicit ('Go', 'No-Go', or 'Conditional Go with stated conditions') and cites at least two specific data points from the provided test summary or defect list
• ✓At least two rollback triggers stated as specific, observable conditions — for example, a named feature failing a post-deploy smoke test or an error rate exceeding a stated threshold — not vague statements

Evaluation rubric

Sample solution outline

Common mistakes

• ✗Marking the release as go because 831 of 847 tests pass — a 98.2% pass rate sounds healthy, but 9 of the 14 failures stem from a single SEV-1 defect that blocks a core enterprise workflow; a pass rate without reading what failed gives a false sense of quality
• ✗Counting the two intermittent failures as real defects and including them in the blocker count — the provided data notes that both passed on re-run, making them likely flaky tests rather than new defects; conflating flakiness with blocking defects overstates risk and dilutes the report's credibility
• ✗Accepting the SEV-2 workaround without assessing the target user base — a UTF-8 encoding step is trivial for a developer but is a significant and confusing obstacle for a non-technical enterprise administrator who manages user imports; the suitability of a workaround depends on who must apply it
• ✗Omitting the coverage gap caused by the partial reporting module regression — noting that '831 tests pass' without flagging that the most-affected module has 9 unexecuted test cases gives stakeholders a misleading picture of test completeness
• ✗Writing rollback triggers that are vague — phrases like 'if we see customer complaints' or 'if the error rate is too high' do not give an on-call engineer enough information to make a call at 2 a.m.; triggers must name a specific metric, a threshold, and a time window
• ✗Writing an executive summary that requires the reader to reference other sections to understand the recommendation — the summary must stand alone; a product manager in a go/no-go meeting should be able to make a decision from the first paragraph alone

Submission checklist

• Report contains all seven required sections with clear headings: Executive Summary, Test Results Summary, Defect Triage, Coverage Gaps, Environment and Configuration Assessment, Go/No-Go Recommendation, Rollback Plan and Triggers
• Defect triage table classifies all five open defects as blocker, acceptable risk, or deferred — with a one-line rationale for each classification
• Go/no-go recommendation is explicit and unambiguous, citing at least two specific data points from the provided summary
• At least two rollback triggers are stated as specific, observable, measurable conditions — not vague statements
• The partial reporting module regression and its impact on test coverage confidence are explicitly addressed
• The environment/config section covers feature flag state, database version parity, and the untested rollback procedure
• The executive summary paragraph stands alone — a non-technical reader can understand the recommendation and rationale without reading further

Extension ideas

• +Rewrite the same report as a 'Conditional Go' — assume the product manager has formally accepted the SEV-1 risk with a signed customer communication plan and a committed hotfix date; practise changing the recommendation while keeping the evidence base and the rollback plan intact
• +Build a reusable release readiness report template in Markdown with placeholder sections and inline guidance notes for each field, so the next QA lead can complete the assessment under time pressure without starting from a blank page

Related