Skip to main content
Quality Command CenterReport · Sign-off

Ready to release?
One recommendation, with reasons.

The Quality Command Center reads your suite runs and scans, and the project's requirements and UAT cycles, into one score out of 100 and a recommendation. When it says hold, it names what is holding the release, so your QA team has the evidence and your release owner makes the call.

Release gates
18
Rules your test lead can set
Each one blocks, warns or is off. By default five block, eleven warn and two start off.
Score
8
Signals behind one number
Functional, coverage, stability, performance, security, accessibility, visual and UAT.
Sign-off
3
Decisions an approver can give
Approve, approve with conditions or reject. Each one is kept with the counts it saw.
The score

One number, and how it got there.

Four pillars, weighted. A pillar with nothing measured is left out and the others are re-weighted, so read the score beside the Discipline health cards, which show what wasn't measured.

  • Functional

    30%

    The pass rate of every test result from your automated suite runs, over all time. Skipped results, suite sensitivity runs and infrastructure aborts are left out.

  • Coverage

    30%

    Weighted by business risk: a critical requirement counts eight times a low-risk one. A requirement counts once it has a test that can run, whether or not that test has run yet.

  • Stability

    15%

    The share of tracked tests that are not flaky. A test needs enough runs to be judged at all.

  • Disciplines

    25%

    The average of your performance, security, accessibility and visual results, each read by its weakest target, and your UAT pass rate, from the last 30 days, for those that have results.

It reads your own suites and scans, filed under the project or under none, and the project's requirements and UAT cycles, so two people on one project can see different scores.

Ready to release

A score of at least 75 and no open gate, with suite results behind it.

Release with caution

A lower score, a warning, or scan and UAT results with no suite run. Each warning costs 7 points.

Hold release

Any blocking gate, whatever the score. It also caps the score at 40.

Not enough evidence

No suite run, scan or UAT result to score, so there is no number. Requirements or linked tests alone don't change that.

A blocking gate holds the release even with no score. The 75 is a default your test lead can change.

Release gates

Your test lead decides what stops a release.

Eighteen rules, set per project, or for your own work outside any project. Each one blocks the release, warns or is off. These are QAEverest's defaults until someone changes them.

Requirements

  • Critical requirement untestedA business-critical requirement has no test that can run.
    Block
  • Critical requirement failingA business-critical requirement's test is failing.
    Block
  • Critical requirement not runA business-critical requirement's tests have not all run.
    Warn
  • No suite runsRequirements exist, or a scan or UAT cycle has results, but no suite run has a result.
    Warn
  • Critical requirement without evidenceNo test ran with its checks in the last 30 days without being weakened since or found unable to fail.
    Off
  • Critical requirement not provenNo test of it that ran in the last 30 days has been seen to fail by Check strength and stayed unchanged since.
    Off

UAT

  • Sign-off missingA cycle in progress awaits sign-off, its sign-off is out of date, or it has no approvers.
    Block
  • Rejected by an approverAn approver on the list rejected the cycle's current results.
    Block
  • Must-have cases failingIn a cycle in progress.
    Warn
  • Must-have cases not runIn a cycle that has started.
    Warn
  • Planned cycle not startedA planned cycle has not started.
    Warn
  • Closed without sign-offA cycle was closed without being signed off.
    Warn

Security

  • Confirmed security issueA scan assigned to this project found a proven critical or high vulnerability, an expired certificate or a public site on plain HTTP.
    Block
  • Confirmed issue, scan outside the projectA scan of yours saved with no project confirmed an issue.
    Warn
  • High-risk findings to reviewA scan found other critical or high-risk findings, such as a missing header. A newer scan that no longer finds them clears it.
    Warn

Performance

  • Slow or failing load testOver the p95, slowdown or error limits.
    Warn

Accessibility

  • Critical accessibility issuesOn a scanned page.
    Warn

Visual regression

  • Unreviewed visual differencesA suite run differs from its baseline, and nobody has set that screenshot as the new baseline.
    Warn

Scan, visual and UAT rules read the last 30 days: older results stop counting, and so do their gates. A requirement's risk comes from its linked tests or, with none rated, its refined story's priority. A Jira or generated requirement with no rated test counts as medium risk.

Gate settings

The numbers are yours too

  • Anyone who can see the project can read the gates. Changing them needs the Change release gate settings permission, held by the ready-made Lead and Admin roles.
  • A save changes the score, the recommendation and the readiness report, and which gates fail the CI gate.
  • The page and the report say who set the gates and when, and Recent changes shows the latest saves and what moved.

Use QAEverest defaults puts every rule and number back, ready to save.

CI gate

The release gate in your pipeline

  • It answers passed: false on a blocking gate, and on a score under the threshold you send. Warnings don't fail it.
  • With no score, sending a threshold fails the gate. Send none and only blocking gates fail it.
  • It reads the suites and scans of the person whose key it uses. Any signed-in user can create a key under Profile → API Keys.
  • The commit you send is saved with the trend point. It doesn't choose which results are read.

If our server hits an error, the gate answers passed: true with the reason “Gate unavailable”, and a check that can't be read drops out of the answer. If the server can't be reached, your pipeline step decides what happens.

For the release meeting

One PDF with a recommendation, and why.

On Insights → Quality Center, the Readiness report button opens a short panel, and Download PDF saves the report. It opens with what the person making the call needs. The rest is the evidence your QA team stands behind.

  1. First

    The recommendation

    Ready to release, Release with caution, Hold release or Not enough evidence, with an executive summary in plain sentences.

    • A line for the release owner's decision
    • Must be resolved before release
    • Known risks if released now
    • At a glance
  2. Then

    Evidence by test type

    Requirement evidence over the last 30 days, for information unless an evidence gate is on, followed by:

    • Integration tests (SIT)
    • User acceptance tests (UAT)
    • Operational checks (OAT)
    • Failing automated tests
    • Change coverage (pull requests)
  3. Last

    How these numbers were calculated

    For QA leads and auditors: the rules behind the recommendation, who set the gates, and the windows and limits the numbers were read under.

Whose results
Mine or, in an organisation project with the View execution reports permission, Everyone's. Everyone's widens the SIT results and failing tests. The recommendation and operational checks still read your own suites and scans.
Range
The last 7, 30 or 90 days, for the SIT results, failing tests and pull requests. The recommendation doesn't change with it: functional results cover all time, and the operational checks and UAT read the last 30 days.
Insights → Open Failures

Automated tests still failing, on one list

  • Each data row is judged by its own results, over the last 7, 30 or 90 days or two dates you pick. Skipped results, infrastructure aborts and suite sensitivity runs never count.
  • The suite's owner sets a severity on the run result page. Until then, a level carried over from an earlier run, or suggested from business risk or priority, is marked as a suggestion.
  • OK to release says the team will ship with this failure. It belongs to the latest failing run, isn't carried to later runs, and the failure still counts.
  • A teammate's row shows its title, suite, owner, severity and dates, never their error text.
  • Severity and OK to release appear among the report's risks. They don't change the score or the gates.

Download the list as a PDF, or email it. Recipients outside your organisation get a masked copy unless your admin has approved them. With no organisation, you choose which copy they get.

User acceptance testing

UAT sign-off, tied to the exact results.

Your QA lead plans the cycle, the people who know the business run it, and each approval counts only for the results it was given against.

  1. 01

    Plan the cycle

    A QA lead creates the cycle, with its environment and dates if needed, and copies in cases from their own suites, Test Sets or generated test cases, or writes them by hand. AI can also write UAT scenarios from a story's acceptance criteria, charged per scenario.

  2. 02

    Assign it

    The owner assigns cases to people in the project, one person per case. Every case starts as a must-have, and the owner switches off the ones that aren't. The ready-made tester role holds three permissions: view projects, view execution reports and run assigned UAT cases.

  3. 03

    Run it

    Testers work through My UAT Tasks one case at a time, recording pass, fail, blocked or skipped. A fail or a block has to say what they saw.

  4. 04

    Triage the defects

    The owner or the assigned tester can rate a failed or blocked case, and file it to a connected Jira or ClickUp from the cycle's Defects list.

  5. 05

    Sign it off

    Approvers review the results, then approve, approve with conditions or reject, and type their full name. Conditions have to be listed, and a rejection has to say what must change. The exit criteria inform the decision and don't stop a sign-off.

When results change

A sign-off counts only for the results it was given against

Record a result, add or remove a case, or change a case's assignee or must-have flag, and the results version moves on. Earlier sign-offs read as out of date. While the cycle is in progress, that holds the release by default until they are given again. If the owner closes the cycle instead, it becomes a Closed without sign-off warning.

On file

A certificate you can file with the release

The cycle owner and signed-in approvers can download it as a PDF once any listed approver has answered. Its banner says where sign-off stands, and it lists each approver's decision, the name they signed as, when, the results version and whether that sign-off still stands. The cycle report downloads as PDF or Excel.

Approvers outside the project

Sign off by emailed link

  • Project members who approve need the Sign off UAT cycles permission. Anyone else can be named by email, with no QAEverest account.
  • When the owner requests sign-off, each gets a link good for up to 14 days. Signing needs a one-time code sent to their own address.
  • The link shows the counts, the stories and the environment, and for each failed or blocked case its title, story and what the tester saw. It never shows steps, expected results, test data or who ran a case.
UAT Overview

Every cycle in a project you belong to

  • Progress per cycle and per tester, what is overdue and where sign-off stands, for the newest 500 cycles.
  • A burndown for any one cycle.
  • For people with the Plan UAT cycles permission. It shows counts, names, dates and statuses, with no case text, and gives no access to a cycle you have no role in.
Part of the release decision

UAT reaches the gate

  • Six of the eighteen release rules are about your UAT cycles.
  • By default, among cycles touched in the last 30 days, one in progress holds the release until every listed approver has approved the current results, and so does a current rejection from a listed approver.
  • Approved with conditions counts as approved. For people who can plan or sign off UAT cycles, the report lists the conditions as a known risk.
  • The traceability matrix has a UAT column: Accepted, Failing or Not run. It reads case results rather than sign-off, and leaves out hand-written cases.
Who decides

The report recommends. Your release owner decides.

The report says what it read and over which window, and the PDF leaves a line for your release owner to write the decision.

Links alone give no score

Linked tests with nothing run give no number, so coverage alone never reads as ready.

A hold names its reason

Blocking gates are listed in words a release owner can read.

Gaps are named

SIT, UAT, performance, security or accessibility with nothing to read are named as not assessed in the executive summary.

Sign-offs can go out of date

A new result moves the version, and earlier sign-offs stop counting until they are given again.

Rated and estimated stay apart

In the report's summary, only failures your team rated count as Critical / High, and estimates are shown beside them.

Changes stay on record

Recent changes lists the latest 10 saves of the gates, with who made them and when. Each sign-off keeps the counts it was given against.

Walk into the release meeting with the evidence.

Run your suites, open Insights → Quality Center, and download the Readiness report before your next release.