@@ -17,7 +17,8 @@ description: "This handbook page serves as a central repository for all our Deve
||[dx: Failure Analysis Dashboard](https://dashboards.gitlab.net/d/dx-failure-analysis)| CI pipelines failure analysis. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[dx: Master-Broken Incident Detection](https://dashboards.gitlab.net/d/dx-master-broken-incident-detection)| Master-broken incidents related dashboard. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[dx: Test Governance Key Metrics](https://dashboards.gitlab.net/d/dx-test-governance)| Key metrics related to CI/CD pipeline execution in gitlab-org/gitlab. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
|Test metrics|[dx: Test Suite Overview](https://dashboards.gitlab.net/d/dx-suite-overview/dx3a-test-suite-overview)| Overview of test suite health and status.|[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
|Test metrics|[dx: Test Health](https://dashboards.gitlab.net/d/dx-test-health)| Per-group test-suite health scores across the Flaky, Quarantine, and Slow pillars. [How to read Test Health scores](/handbook/engineering/infrastructure-platforms/developer-experience/development-analytics/test-health). |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[dx: Test Suite Overview](https://dashboards.gitlab.net/d/dx-suite-overview/dx3a-test-suite-overview)| Overview of test suite health and status.|[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[dx: Predictive Tests](https://dashboards.gitlab.net/d/dx-predictive-tests)| Metrics for predictive tests. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[dx: Test File Failure Overview](https://dashboards.gitlab.net/d/dx-test-file-failure-overview)| All test failures aggregated by test file. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
Development Analytics dashboards are listed on [Developer Experience Dashboards page](/handbook/engineering/infrastructure-platforms/developer-experience/dashboards)
The [Test Health](/handbook/engineering/infrastructure-platforms/developer-experience/development-analytics/test-health) page explains the per-group test-suite health scores (Flaky, Quarantine, and Slow pillars) and how to act on them.
Test Health scores every stage group's test suite from three angles, called pillars: Flaky (open flaky-test debt and the pipelines it blocks), Quarantine (tests removed from the blocking suite and how long they have sat there), and Slow (test files slow enough to drag pipeline duration). Each pillar is a 0 to 100 score per group, where 100 means no measured debt.
At launch the scores cover RSpec backend tests and QA end-to-end tests in `gitlab-org/gitlab`. Jest, contract tests, and Workhorse Go tests are deferred.
## How to read a score
Scores carry a red/amber/green status: 0 to 29 is red, 30 to 70 is amber, 71 to 100 is green. Every deduction is itemized. Each pillar section on a group's detail dashboard ends with a score-math panel showing exactly what was charged, for example: Issue backlog -7, Blocked pipelines -70 (at cap), Score 23. Stage, section, and org scores are the mean of their member groups' scores, so they read as "the average group in this slice".
## Where to find your group
Start at the [Test Health dashboard](https://dashboards.gitlab.net/d/dx-test-health). The grid shows one row per group with all three pillar scores; your group's row links to its detail dashboard, which carries the score breakdown, 90-day trends, and the specific tests, issues, and files behind each number.
## Acting on a red Flaky score
ci-alerts opens an issue in `gitlab-org/quality/test-failure-issues` for each top flaky test file (label `automation:top-flaky-test-file`) with the failure evidence attached, and sets a due date of the next business day. From there:
1. Triage the issue promptly: one in its first week costs the least, one past its due date with no `workflow::` label costs the most.
1. If the detection is wrong, apply `~"flaky-test::false-positive"`.
1. Quarantining a file moves its backlog cost from the Flaky pillar to the Quarantine pillar (priced by age). Any failures the file still causes keep counting in the Flaky blast radius, so quarantine parks the debt without hiding live damage.
1. Moving a fixed issue to `workflow::verification` drops its cost to the minimum while it waits out the detection window.
## Roadmap
The score formulas are calibrated so every action a team takes moves its score. A low score doesn't trigger anything on its own yet. But flaky-test issues, which feed the scores, now carry a due date of the next business day. Please start improving low scores now.
Questions and feedback: the [Test Health feedback issue](https://gitlab.com/gitlab-org/quality/analytics/team/-/work_items/734)(GitLab internal).
@@ -251,6 +251,7 @@ To maintain visibility and accountability:
-**Weekly summaries**: Sent to engineering teams with current quarantine status and encouragement to resolve tests.
-**Monthly rollups**: Provided to senior management on test health metrics.
-**Team dashboards**: Available to track your team's quarantined tests by feature category.
-**Test Health scores**: Quarantined tests are priced by age into your group's Quarantine pillar score. See [Test Health](/handbook/engineering/infrastructure-platforms/developer-experience/development-analytics/test-health) for how the scores work.
These reports help ensure quarantine remains a temporary state, not a backlog.
