Skip to content
steelabs

Release readiness

Find the gaps before release.

Eight questions to organise a release conversation. Get a short list of next actions and the worksheets to support them. This is a self-assessment of your answers, not a test of your product or a release certification.

Answer for one release candidate

Use the build you intend to ship, rather than the best state the product reached last month. Select “Yes, with evidence” only when you can point to a current record that somebody has reviewed. “Partly” means some work exists but the control is incomplete; “Not sure” means the evidence needs confirmation.

A missing control and an unknown control require different follow-up. The result puts stated gaps first, then uncertainties, then partial arrangements. This order helps start a discussion; it does not measure the severity of your product’s risks. An untested high-impact payment journey may deserve attention before several lower-impact items.

The questions are deliberately broad. Apply the relevant requirements for your product, users and jurisdiction, and involve a specialist when the scope calls for one. Even eight positive answers cannot establish that a system is secure, accessible, legally compliant or ready to release.

Your current evidence

0 / 8 answered

Are the release scope, acceptance criteria and decision owner agreed?

Look for a specific candidate build, explicit exclusions and a person who can accept remaining risk.

Do critical user journeys have reviewed test evidence for this build?

Include failure paths and integration boundaries. A test written for a previous release is not current evidence.

Are unresolved defects reproducible, triaged and owned?

The record should explain user impact, reproduction steps, evidence and who decides whether a finding can remain open.

Can the team trust the automated checks used in this release decision?

Review relevant coverage, test data, failure investigation and quarantined checks. If checks are entirely manual, select No and review whether automation would help.

Have permission and data-boundary checks been reviewed?

Test permitted and forbidden operations, including one account trying to access another account’s objects, where applicable.

Have the important mobile and keyboard journeys been checked?

Include focus, meaningful labels, form errors and the supported viewport sizes. Automated checks cover only part of accessibility.

Have AI-assisted changes and AI features had independent review?

Check expectations, data permissions, tool authority and failure handling. Select Not applicable only if this release contains neither AI-assisted changes nor AI features.

Are monitoring, recovery steps and operational owners ready?

Someone should know what to observe after deployment and how to roll back or recover if the release causes a problem.

Your action list

Complete all eight questions to see the next actions. Choose “Not sure” when you need to check with somebody; uncertainty is useful information.

Answers are processed in your browser and are not stored by this tool. A shared link contains the selected answer codes in its fragment. Anyone with that link can read them. Do not use it to share confidential release information.

Turn the result into a decision record

Use the release evidence checklist to assign owners and dates, then the test summary to record what actually ran. Keep the supporting reports in the team’s approved workspace and arrange a fresh review after the build, configuration or scope changes. The action list is useful only when someone follows it through.

Browse all templates and examples