Quality Center & Insights — Frequently Asked Questions

What is the Quality Command Center?

Open Insights → Quality Center. It reads your suite runs and scans, and the project's requirements and UAT cycles, into one score out of 100 and a recommendation for the release. 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.

How is the score calculated?

Four weighted pillars make up the score:

• 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.

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. Coverage is also left out until a suite has run, however many tests are linked.

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

What do the recommendations mean?

• 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, and nothing blocking, so there is no number. Requirements or linked tests alone never give a number, but they can still hold the release: a business-critical requirement with no test that can run reads Hold release, with no score.

The 75 is a default that can be changed for each project.

What are release gates, and who can change them?

Release gates are eighteen rules covering requirements, UAT, security, performance, accessibility and visual regression. Each one blocks, warns or is off. By default five block, eleven warn and two start off. The five that block by default are:

• Critical requirement untested — a business-critical requirement has no test that can run.
• Critical requirement failing — a business-critical requirement's test is failing.
• Confirmed security issue — a scan assigned to this project found a proven critical or high vulnerability, an expired certificate or a public site on plain HTTP.
• Sign-off missing — a UAT cycle in progress awaits sign-off, its sign-off is out of date, or it has no approvers.
• Rejected by an approver — an approver on the list rejected the cycle's current results.

Gates are set for each project, or for your own work outside any project, together with the score needed to say ready and the performance limits. In an organisation this takes the Change release gate settings permission. Recent changes lists the latest 10 saves, with who made them and when.

Can a release gate fail my CI pipeline?

Yes. A pipeline step can call GET /quality/gate with a personal API key, sent as Authorization: Bearer followed by the key. It answers HTTP 200 with passed, score, verdict, blockers and reason, and your step decides what to do with the answer. A blocking gate gives passed: false. With nothing measured, nothing blocking and no threshold, it gives passed: true, so add threshold to also fail on a low score, and projectId to read one project. The threshold comes only from that request, and commit and branch are only stored with a scored result.

If our server hits an error while working out the answer, the gate usually answers passed: true with a reason starting "Gate unavailable". If one source of data can't be read, it is skipped and the answer looks normal. A bad key answers 401 and a project you can't see answers 404, with no passed field. Your pipeline step decides what to do in those cases, and when the server can't be reached.

What is in the Release readiness report?

On Insights → Quality Center, the Readiness report button opens a short panel, and Download PDF saves the report. It opens with the recommendation, an executive summary in plain sentences, what must be resolved first and the known risks of releasing now.

The evidence follows by test type: requirement evidence, integration tests (SIT), UAT, operational checks, failing automated tests and the pull requests analysed in that range. It closes with how the numbers were calculated, who set the gates, and the windows and limits they were read under.

The report recommends; it does not decide. The PDF leaves a line for your release owner to write the decision, and nothing records it for them.

• 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, pull requests and which closed UAT cycles are listed. The recommendation doesn't change with it.

What is the Open Failures page?

Insights → Open Failures lists the tests failing in the range you choose, from your automation runs, each data row judged by its own results, with its severity, when it started failing, when it last failed and whether it was marked OK to release.

• Whose — Mine, or Everyone's in the project for an organisation member with the View execution reports permission. A teammate's row shows its title, suite, owner, severity and dates, never their error text or environment.
• What — Still failing, or All failures in the range. Severity chips and a suite filter narrow the table, the PDF and the email.
• When — the last 7, 30 or 90 days, or two dates up to 90 days apart.

Skipped results, infrastructure aborts and suite sensitivity runs never count as failures. A summary PDF can be downloaded or emailed.

How do failure severity and OK to release work?

On a run's result page, the suite's owner can rate a failure Critical / High, Medium or Low and switch it to OK to release. Neither changes a pass or fail count. Until a failure is rated, a severity is suggested from the same failure on an earlier run, the test's business risk or its priority, and Open Failures draws a suggestion differently from a rating.

Severity and OK to release are for reading and reporting. They do not change the score or the release gates, and in the Release readiness report's summary only rated failures count as Critical / High.

What is SIT by Area?

Insights → SIT by Area shows the system integration test results of a project, split by integration area: Interface Contract, Data Flow, Auth Between Services, Downstream Failure, Ordering and Idempotency, and Timeout and Retry. Cases with no area tag are shown as Unclassified. For each area you see how many cases passed, failed or didn't run, and which ones failed or didn't run and how they failed, sorted into kinds such as contract, data, auth and timing, with a separate view of the failures that broke the interface contract.

It reads test cases saved in your suites that were generated from an Integration record, plus cases with no generation record of their own in a suite generated from one. Test Sets are left out, and so are generated Integration cases that were not saved to a suite. Choose Mine or Everyone's in the project and a range of the last 7, 30 or 90 days, or two dates up to 90 days apart, and download the report as PDF or Excel. With the same project, results and range, the Release readiness report's SIT section counts the same cases the same way.

What is Scan Trends?

Insights → Scan Trends shows how each scanned target has changed over 30, 90, 180 or 365 days, or between two dates up to 365 days apart:

• Performance — p95 response time for load and soak runs. Better or worse is judged only between runs at the same load.
• Security — open and confirmed issues.
• Accessibility — the score.

Each target gets a chart, its latest values and the change in words, such as "120 ms slower" or "3 fewer issues". Scheduled runs and public API runs made with a personal key are included. Choose your own results or, with the View execution reports permission, everyone's in the project, and download the data as PDF or Excel.

Do these pages use credits?

No. Reading the Quality Center, Open Failures, SIT by Area and Scan Trends, and downloading their reports, uses no credits. The runs and scans behind them are charged when they run.