Release Readiness

3 min read

The Release Readiness report tells you whether one release is ready to ship. It gives a verdict, the gates behind it, a score out of 100 with what makes it up, and the blockers and risks that could stop you. Use it as the final check before a release goes out.

It uses the same calculation as the release’s Release Analysis, so both screens always agree.

Choose a release

At the top of the report, pick a Release. Everything in the report, including the verdict, metrics and risks, is for that release. When the release has a target date, a badge shows the days remaining.

The verdict

The verdict is one of four answers:

Ready: no gate has failed and the score is healthy.
At risk: nothing is blocking yet, but something needs attention. For example, the fail rate is above the at-risk bar, a failure has no defect logged, or the score is only fair.
Not ready: a gate is blocking the release. For example, blocker or critical defects are still open, the fail rate is too high, too many failures have no defect, or the score is too low.
Not started: no tests have been executed yet.

A line under the verdict names what caused it, such as Blocker or critical defects are still open before release sign-off.

A failed gate always wins over a good score. A release can score 88 and still be Not ready because one blocker is open.

Readiness gates

Each gate shows the value the release reached, the target, and whether it passed:

Execution coverage: how many of the release’s tests have been run.
Fail rate under control: the share of executed tests that failed.
No open blocker / critical defects: how many blocker or critical defects are still open.
Every failure has a defect: how many failed tests have no defect logged.
Requirements verified: how many of the release’s requirements are fully verified. Shown only when the release traces requirements.

The targets come from Hawzu’s default acceptance criteria, which every release uses today, and each gate shows the target it was judged against.

How the score is made up

The score out of 100 combines these parts. Each part has its own score, a status word, and a line saying why it scored that, such as 42 of 50 testcases executed (84%). Hover a part’s name to see how it is worked out.

Test Execution: executed tests out of all tests in the release.
Quality: passed tests out of executed tests.
Defect Health: starts at 100 and loses points for open blocker or critical defects, high-severity defects left open for a week or more, overdue defects, and a high reopen rate.
Requirements: the share of requirements whose linked tests have all passed. It’s left out when the release traces no requirements, so a release without requirements isn’t marked down for it.
Overall Release Readiness: the parts above combined into one score. How much each part counts is set by the default acceptance criteria.

Each score’s status is Healthy, Needs Attention, At Risk or Not Ready.

Key metrics

The report also shows the numbers behind the score: tests in scope, executed, passed, failed, blocked, skipped and not executed, open blocker or critical defects, open high-priority defects, and requirements in scope.

Risks and supporting views

Risks: failing tests and open critical or blocker defects, the items most likely to block the release.
Defect severity distribution: how open and closed defects are spread across severities.
Automation mix: the automation status of the tests in the release.
Freshness signals: reopened defects and the days since the last fully passing run.
Executions in this release: each execution’s status, test counts and failures.

Exporting

Download the report as a PDF or as Excel (XLSX). The PDF dialog lets you choose its sections: cover page, executive summary, readiness score, score breakdown, key metrics, defect severity distribution, automation mix, freshness signals, risks, executions in this release, and a legend that explains each part of the score.