The release meeting ran on gut feel and a spreadsheet of results

The problem

Every week the QA lead gathered results from the functional suites, a performance tool, a security scanner and an accessibility checker into a slide for the release meeting. There was no shared rule for what should block a release, so each meeting re-argued the same questions.

• Results from separate tools were compiled by hand before every release.
• Every failure looked equally urgent, or equally ignorable.
• Performance and security were checked occasionally rather than every release.
• There was no written record of who decided to ship, and on what evidence.

The solution

The QA lead sets the rules once. Each release is then read against them, and the release owner records the decision.

1. 1

   One verdict from every signal

   Quality Command Center

   A ship-confidence score out of 100 with a ship, caution or blocked verdict, fused from functional results, coverage and stability plus the latest performance, security, accessibility and visual-regression runs. When it says blocked, it names the gates that blocked it. When tests are linked but none has run yet, there is no score: it reads “No runs yet”.

2. 2

   Gates the test lead sets

   Project release gates

   Each of sixteen rules blocks, warns or is off, alongside the score needed to say ready and the performance limits. By default five rules block — a critical requirement untested or failing, a confirmed security issue, a missing UAT sign-off or an approver's rejection — and the other eleven warn. The page and the report say who set the gates and when.

3. 3

   Rate failures, not just count them

   Severities + Open Failures

   Each failure can be rated Critical / High, Medium or Low and marked OK to release, which changes no pass or fail count. Open Failures lists the tests still failing across automation runs over a chosen period, with each one's severity and when it started failing.

4. 4

   Make non-functional checks routine

   Scheduled scans + Scan trends

   Load or soak tests and security scans run daily or weekly on a schedule. Scan trends shows each target over 30 to 365 days and states the change in words, such as “120 ms slower” or “3 fewer issues”.

5. 5

   Take one PDF to the meeting

   Release readiness report

   A single PDF opens with a recommendation — Ready to release, Release with caution, Hold release or Not enough evidence — an executive summary, what must be resolved first, the known risks, and a line for the release owner to record the decision. The report recommends; it does not decide.

What changes

• The release meeting starts from one verdict and the gates behind it, not a slide assembled the night before.
• Open failures carry a severity, rated by the team or suggested until they rate it, so the conversation is about risk rather than counts.
• Performance, security and accessibility evidence is current every week, not only when someone has time.
• The decision, and who made it, is written down with the evidence it was made on.

Read more

• Performance and security testing
• Accessibility testing
• Your benefits