Release Visibility Check

How clear is your
release picture?

Find the gaps between a green pipeline and the evidence your team needs.

Answer 14 short questions about your setup and how your team uses test results. Get a visibility score and practical next steps.

No account. No email required.

See how the score works

JavaScript is needed to calculate your score. Your answers are calculated in your browser. You can still read the questions and scoring method.

Think about your last three releases, or the last 90 days if you release continuously. Choose the highest description that is consistently true in your scope.

Your setupWhat are you assessing?

Choose the scope you know best. Use the same scope for every answer.

One product or projectSeveral products released togetherThe organization I work withAnother scopeI'm not sure

Your practicesWhen a release decision is needed, how do people get the relevant test results?

Include all projects in your chosen scope. Consider whether people must open each project or ask teams separately to build the summary.

We cannot reliably find the results needed for the decision.We ask people and search across messages, files, or pipeline pages.We use a known list of sources, then assemble the results for each decision.We have a shared summary of the required sources, updated before the decision.Our shared summary updates as results arrive and clearly shows its scope.I'm not sureOur approach is differentNot applicable to this scope

Your practicesHow much detail is available from the automated tests used in release decisions?

Required sources are the suites or pipelines you expect to review. Can someone move from the summary to the exact failed test and its available diagnostic evidence?

We have no usable automated test results.We mostly see whether a pipeline passed or failed.We can find individual test outcomes for some of the required sources.We can find individual test outcomes for all required sources.Those outcomes also link directly to the available failure details and diagnostic evidence.I'm not sureOur approach is differentNot applicable to this scope

Your practicesHow do you notice that expected tests or test reports are missing?

Expected scope means the sources and tests you agreed should report. It is different from code coverage or requirements coverage.

We have no defined check for missing tests or reports.Someone may notice an unusual count or a missing report by chance.We compare the received results with a maintained checklist before the decision.Automated checks flag missing sources or reports against a defined expected scope.Those checks also flag unexpected reductions in test scope, with changes explicitly reviewed.I'm not sureOur approach is differentNot applicable to this scope

Your practicesBefore a release, how are skipped or disabled tests handled?

If no tests were skipped recently, answer for the process that would detect and handle them.

They are not distinguished from passed tests, or are left out of the summary.They can be found in individual reports, but are not reviewed routinely.They are visible in the release summary and reviewed before the decision.Excluded tests also have recorded reasons and named owners.Exclusions are time-limited, reviewed, and closed with evidence of restored testing.I'm not sureOur approach is differentNot applicable to this scope

Your practicesCan you tell whether a test result applies to the version being released?

Use an exact commit, artifact digest, package version, or equivalent identifier. A branch name alone can contain several versions.

We usually cannot link a result to a specific version.We mostly rely on a branch name or whichever result is latest.We can manually trace the exact run, version, and test environment.These identifiers are included in the release summary for every required source.A mismatch with the intended release version or environment is explicitly flagged.I'm not sureOur approach is differentNot applicable to this scope

Your practicesCould someone later reconstruct which test evidence supported a release decision?

Consider the period your team needs. Keeping evidence indefinitely is not required.

We do not keep a record of the evidence used.We keep links to changing latest results or rely on people's memory.We record the exact runs, but do not check how long their evidence remains available.We retain the selected evidence for a defined period that meets our needs.We also check that the retained evidence stays accessible and identifiable throughout that period.I'm not sureOur approach is differentNot applicable to this scope

Your practicesWhen a required test fails, how is the follow-up owned?

A named team can be an owner. Consider whether the next action remains clear when work changes hands.

There is no clear person or team responsible for the next action.We ask around in messages to find someone to investigate.A person or team is assigned, but progress is tracked inconsistently.The owner, current status, and next action are visible to the people involved.Unresolved failures are also reviewed against an agreed response time and escalation path.I'm not sureOur approach is differentNot applicable to this scope

Your practicesWhat happens when a failed test passes on a rerun?

Answer for your agreed practice even if this has not happened recently. If reruns do not apply, choose Not applicable.

The passing rerun replaces or hides the original failure.Both attempts remain available, but we usually move on without review.We review both attempts before deciding whether the failure is resolved.Repeated instability also gets a tracked issue and owner.Unstable tests have reviewed, time-limited handling and evidence is required to close the issue.I'm not sureOur approach is differentNot applicable to this scope

Your practicesHow are the test-evidence criteria for a release decision defined?

Consider the written criteria, not just whether a pipeline has a green status.

There are no agreed criteria.The criteria depend mainly on who is available or how urgent the release is.We use a checklist, but it leaves required evidence or exceptions unclear.Criteria define the required evidence, blockers, and who can approve an exception.We also review and update those criteria using findings from previous releases.I'm not sureOur approach is differentNot applicable to this scope

Your practicesWhat happens if required test evidence fails the agreed release criteria?

A checkpoint can be an enforced pipeline rule or a required, recorded human review.

Release can proceed without a defined check or recorded exception.Someone may stop the release, but the check is informal.A required checkpoint flags the problem, but exceptions are not consistently recorded.Release is held until criteria are met or an authorized exception is recorded.The checkpoint also catches missing or outdated evidence, and exceptions have follow-up owners.I'm not sureOur approach is differentNot applicable to this scope

Your answers stay in this page unless you choose to share them after the result. Refreshing or leaving the page clears them.

How clear is your
release picture?

Tell us what gets in your way.

Review your answers before sharing

Tell us what gets in your way.

Review your answers before sharing

Be the first to know when we launch.