@@ -16,7 +16,7 @@ description: "This handbook page serves as a central repository for all our Deve
||[dx: Job Metrics](https://dashboards.gitlab.net/d/dx-job-metrics)| Overview of CI jobs metrics. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
||[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. |[Test Governance](../../infrastructure-platforms/developer-experience/test-governance)|
||[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)|
||[dx: Predictive Tests](https://dashboards.gitlab.net/d/dx-predictive-tests)| Metrics for predictive tests. |[Development Analytics](../../infrastructure-platforms/developer-experience/development-analytics)|
@@ -215,10 +215,6 @@ Teams should maintain visibility into their data paths and dogfooding opportunit
*Coming soon*
#### Test Governance
*Coming soon*
## Future Vision
As GitLab's Data Insights Platform (DIP) matures, we expect to consolidate around the Golden Path for most use cases, with the Silver Path becoming simpler through DIP integration. The ultimate goal is to minimize custom tooling while maximizing customer value through dogfooding.
As part of the DevOps transformation, GitLab moved away from a centrally-managed testing function. The Test Governance group has been retired.
Ensure highly effective testing across all teams by providing test frameworks and tools, optimizing configurations, and partnering with development teams to create and maintain comprehensive functional tests that prevent bugs from reaching customers.
**Modular feature teams — and the monolith — own their full testing lifecycle at every level, including end-to-end (E2E)**: test design, authoring, maintenance, triage, and quality. There is no dedicated person or central team that writes or maintains tests — E2E included — on a team's behalf.
## Vision
**Release readiness is a decision made within the team.** No external team approves a rollout to GitLab.com. Automated pipeline checks (for example, staging-canary smoke tests) are *mechanisms* that support that decision — they are not an external approver.
* Providing stable, repeatable, and fast test frameworks and configurations to catch bugs as early as possible
* Training to upskill teams on functional testing and quality. Every engineering team should know what to test, when, and how to contribute valuable tests to our test suites to maintain test coverage as the application grows
* Incident and bug analysis for GitLab.com and Dedicated - identifying test gaps and working with development teams to improve testing
* Effective quarantine process to quickly identify and isolate flaky tests for stage groups to fix or remove
## What DevEx does now
## Team members
The [Developer Experience department](../)**provides guidance and upskilling** so teams can own their testing effectively, and it **owns the shared test infrastructure** (test environments, frameworks, tooling, dashboards, and the E2E pipeline).
{{<team-by-manager-slug"ndenisenko">}}
Triage and first response for failures belong to the **owning feature team**. DevEx is a **last-resort escalation** for severe cases that genuinely require deep expertise — not the default contact when something breaks.
## Core Responsibilities
For guidance, reach out in [`#s_developer_experience`](https://gitlab.enterprise.slack.com/archives/C07TWBRER7H).
```mermaid
graph LR
A[Test Governance Team]
## Where to go
A --> B[Provide test expertise for critical Product releases]
B --> B1[Define test strategy for the critical feature releases]
B --> B2[Ensure adequate and robust test coverage for critical features]
B --> B3[Stay informed about the stage roadmap]
1.[Testing at GitLab](/handbook/engineering/testing/) — testing philosophy, ownership model, and support
1.[Quality is everyone's responsibility](/handbook/engineering/development/principles/#quality)
A --> C[Stage-level test tools and infrastructure]
C --> C1[Design, Build and continuously improve tests, test frameworks and tools]
C --> C2[Influence, advise and increase the testing capabilities for product teams]
C --> C3[Monitor and address test flakiness]
### Owning your testing — helpful resources
A --> D[Test guidance. Provide guidance and coach engineering teams in the areas:]
D --> D1[Writing e2e tests and feature specs]
D --> D2[Debugging and fixing test failures]
D --> D3[Planning testing early in the development process]
D --> D4[Anticipating test infrastructure needs and requesting change in advance]
D --> D5[Shift left and maintaining appropriate ratio between unit, integration and e2e tests]
D --> D7[Post-incident action]
**Coverage strategy and levels**
A --> E[E2E Pipeline triage. Shared responsibility among all DevX sub-department]
```
*[GitLab testing overview](/handbook/engineering/testing/) — sets the overall expectation that teams own comprehensive test coverage across unit, integration, and end-to-end tests, with end-to-end coverage focused on critical user flows.
*[Testing levels](https://docs.gitlab.com/development/testing_guide/testing_levels/) — the clearest statement of the testing pyramid: most coverage should live at the unit level, fewer tests at higher layers, and E2E should be the smallest portion because it is the most expensive to run and maintain.
*[Testing strategy](https://docs.gitlab.com/development/testing_guide/testing_strategy/) — the blueprint for GitLab automated testing: where tests run and when they execute, so teams know which suite carries which risk.
*[Test Coverage](/handbook/engineering/testing/test-coverage/) — how GitLab thinks about coverage across special scenarios such as offline/air-gapped testing and upgrade-path coverage, not just feature-level E2E.
## Roadmap and themes
**Writing tests**
Test Governance Roadmap is based on commitments we do withing the current quarter and aligned with company goals. All Test Governance commitments are roughly divided into the following themes and sub-themes:
*[Testing best practices](https://docs.gitlab.com/development/testing_guide/best_practices/) — everything you should know about writing good tests: test design, RSpec, FactoryBot, system tests, and parameterized tests.
*[Frontend testing standards and style guidelines](https://docs.gitlab.com/development/testing_guide/frontend_testing/) — how to write good frontend tests with Jest, including testing promises and stubbing.
*[Beginner's guide to writing end-to-end tests](https://docs.gitlab.com/development/testing_guide/end_to_end/beginners_guide/) — check existing lower-level coverage first; if unit/feature/integration coverage is already sufficient, an additional E2E test may not be needed.
*[End-to-end testing guide](https://docs.gitlab.com/development/testing_guide/end_to_end/) — how GitLab runs E2E, selective execution, and the principle of avoiding E2E coverage when a lower-level feature test already covers the risk.
* Test Resilience
* Stability. We ensure that quality processes are intuitive and test outcomes are predictable.
* Speed. We make sure that functional testing frameworks are performing at desired speed and new tooling don't add to execution time.
* Test Observability
* Track test levels. We ensure that functional test levels are tracked and respected.
* Flakiness. We ensure that flaky tests detected and taken care of earlier.
* Quarantine. We ensure that our test suite is healthy and consists of a high-value tests.
* Coverage. We improve quality coverage by providing new and extending existing test automation frameworks to enable diverse testing types.
* Testing Knowledge base
* We proved a comprehensive set of documentation, guidelines, how-tos and trainings to coach engineers on quality.
* Test Governance
* We guarantee the quality of the end product by providing the right balance in test coverage; notify about feature changes to upstream teams; making sure that critical journeys are always tested thoroughly.
* Strategy and tools. We evolve quality strategy to support organisational growth.
* Development Enablement
* We provide helper tools to engineers to empower engineers with quality ownership.
**Keeping your tests healthy**
Use [DevEx: Test Governance Issue](https://gitlab.com/groups/gitlab-org/quality/-/epics/116) to see the current Test Governance effort.
### Short-term commitments
Focus: Optimize Test Pipeline Performance Without Compromising Quality (FY27Q1)
* Reduce pipeline execution time
* Reduce CI costs
* Maintain or improve quality (no increase in escaped defects)
* Improve Predictive tests system by leveraging AI to reduce runner costs
* Build system that adapts automated tests to changes in the code to reduce defect escape rate
* Integrate self-healing tests with flaky tests and quarantined tests processes to improve pipeline stability
### Working with us through request for help
The Test Governance group aims to better enable teams to apply the principle that [quality is everyone's responsibility](/handbook/engineering/development/principles/#quality).
Please request all support via the RFH process below. This will allow us to prioritize requests against our planned project roadmap.
Please use the following Request for Help process for all support requests.
#### Request for Help Process
1. Creates an issue in the [Request for Help](https://gitlab.com/gitlab-org/quality/test-governance/request-for-help#step-1-create-a-new-issue) project. Please complete all sections of the template so we can quickly triage your request
1. The Test Governance team will triage the request within a week, adding appropriate labels and assigning team members based on the request type and priority. You will recieve details about the prioritization and next steps on the request for help issue.
For more detailed guidance on E2E test coverage, consider these approaches:
* Engage with key DRIs to define [persona](/handbook/product/personas) use cases that illustrate how different customers will use new features
* Evaluate which parts of use cases can be covered by lower-level tests versus E2E tests, keeping the entire [testing pyramid](https://docs.gitlab.com/ee/development/testing_guide/testing_levels.html) in mind
* Refer to our documentation on [Testing Best Practices](https://docs.gitlab.com/development/testing_guide/end_to_end/best_practices) before submitting your request
<!--
## How we work
### Work related rituals
### Work management
#### Planning
-->
## Team meetings
Please refer to [Group Test Governance's processes](/handbook/engineering/infrastructure-platforms/developer-experience/test-governance/workflows/#processes-and-their-frequencies) for more details on the purposes of these meetings.
***Team sync, knowledge sharing**: bi-weekly (2 sessions to cover all timezones)
***Issues/Epics refinement**: weekly, alternating between sync (2 sessions to cover all timezones) and async
***Quarterly planning**: once per quarter
***Retrospective**: monthly but grouped by quarter
*[Unhealthy tests](https://docs.gitlab.com/development/testing_guide/unhealthy_tests/) — the kinds of flaky tests we encounter and how to identify and fix them, so your team keeps its own suite reliable.
*[Flaky tests](/handbook/engineering/testing/flaky-tests/) — how top flaky tests are automatically detected and reported for teams to act on.
*[Quarantine process](/handbook/engineering/testing/quarantine-process/) — how tests are quarantined and how the owning team (by `feature_category`) is responsible for resolving or removing them.
