Readiness Questions

3 min read

Releases, test runs and release executions carry a set of computed signals that no field on the record actually stores. Oracle works them out when you ask, which is why Releases that are risky is a question rather than a report you have to build.

Ask in Plain Terms

You never name the signals. Ask the question:

Ask	Answers from
`Releases that are risky`	the verdict
`Test runs still in progress that are healthy`	the verdict
`Explain why the August release is not healthy`	the reason behind the verdict
`Releases with open blocker or critical defects`	the open blocker count
`Releases where failures have no defect recorded`	failures with no defect
`Test runs with no work left in them`	work remaining
`Test runs that are failing heavily`	fail rate
`Release executions that have stalled`	run condition

Healthy Means the Verdict, Not the Score

This is the thing worth understanding, because it is where intuition goes wrong.

There are two different measures, and they can disagree:

The verdict — Ready, At risk, Not ready or Not started. Decided by hard gates.
The score — a weighted number out of 100.

A release with one open blocker can score 88 and still be Not ready. The gate fired; the number never got a vote.

Not started is not Not ready. A scope nobody has executed anything in has not failed — it has not begun. Oracle keeps those apart, so Releases that are risky does not sweep up work that simply has not started.

The Reason, Not Just the Result

Asking Explain why the August release is not healthy returns the bar that actually triggered the verdict — not a list of everything that happens to be imperfect.

That distinction matters. A verdict that names the wrong reason is worse than one that names none: you check the thing it blamed, find it clean, and stop believing the verdict.

You can also ask which gates did not pass. The bars are:

Execution coverage
Fail rate under control
No open blocker or critical defects
Every failure has a defect
Requirements verified

The requirements gate is absent entirely when a scope traces no requirements — that is different from failing it.

Figures Can Be Frozen

When a release is signed off, its figures are frozen into a sign-off snapshot. After that, its readiness numbers report what was true at the signature, not what is true today.

This is what makes comparing them meaningful — otherwise the same number would mean “as of sign-off” on one row and “as of now” on the row beneath it.

Counting Failures

Releases where failures have no defect recorded counts result rows, not test cases. A case driven by four datasets that failed on three of them is three failures, not one.

A closed defect still counts as an explanation. The question is whether the failure was ever written up, not whether the write-up is still open.

What You Can See Depends on Defects

The signals split by what reading them costs:

Reads only execution results	Computed from defects
Execution coverage, pass rate, fail rate	Readiness verdict and its reason
Results total, executed, remaining	Readiness score
Run conditions — stalled, blocked, failing heavily	Open blocker or critical defects, failures with no defect

A role that cannot read defects can still ask which runs have stalled or how far a run has got. It cannot get a readiness verdict or a score, in a column or as a sort — because both are computed from defects, and a permission you can route around is not a permission.

See Limits and Permissions for how this works generally.

Comparing Scores Across Releases

The bars behind the score can be customised per release. Two releases scoring 74 have not necessarily cleared the same bars, so treat a cross-release comparison of the raw number with care — and prefer the verdict, which reflects each release’s own criteria.