---
layout: handbook-page-toc
title: "Verify:Testing Group"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## Vision

We provide confidence in software through the delivery of meaningful, actionable automated testing results in GitLab.

## Mission

The Verify:Testing Group provides automated testing integration into GitLab. We aim to allow software teams to be able to easily integrate many layers of testing into their GitLab CI workflow including:

* Code Testing
* Code Quality
* Code Coverage
* Web performance testing
* Usability testing
* Accessibility testing

We want software teams to feel confident that the changes they introduce into their code are safe and conformant.

## Team Members

The following people are permanent members of the Verify:Testing group:

<%= shared_team_members(role_regexps: [/Verify(?!:)/, /Verify:Testing/]) %>

## Stable Counterparts

The following members of other functional teams are our stable counterparts:

<%= stable_counterparts(role_regexp: /[,&] Verify/, direct_manager_role: 'Engineering Manager, Verify:Testing', other_manager_roles: ['Frontend Engineering Manager, Verify', 'Engineering Manager, Verify:Continuous Integration', 'Engineering Manager, Verify:Runner']) %>

## Technologies

Like most GitLab backend teams we spend a lot of time working in Rails on the main [GitLab app](https://gitlab.com/gitlab-org/gitlab). Familiarity with Docker and Kubernetes is also useful on our team.

## Common Links

 * [Issue Tracker](https://gitlab.com/groups/gitlab-org/-/boards/364216?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Atesting)
 * [Slack Channel](https://gitlab.slack.com/archives/g_testing)
 * [Roadmap](https://about.gitlab.com/direction/ops/#verify)

## Our Repositories

* [GitLab](https://gitlab.com/gitlab-org/gitlab)
* [CodeQuality](https://gitlab.com/gitlab-org/ci-cd/codequality)
* [Accessibility](https://gitlab.com/gitlab-org/ci-cd/accessibility)

## How we work

### Meetings

We meet on a weekly cadence for two separate meetings. Typically we conduct both of these meetings sequentially.

#### Testing Group Weekly Meeting
This synchronous meeting is to discuss anything that is blocking, or notable from the past week. This meeting acts as a team touchpoint.

#### Testing Group Grooming Meeting
This synchronous meeting is to groom the current milestone's issues, as well as ensuring the next milestone has appropriately sized issues. In this meeting we should be: discussing priority, sizing issues, estimating the weight of issues, keeping track of our milestone bandwidth and removing issues appropriately.

### Definition of Ready

Before the team will accept an issue into a milestone for work it must meet these criteria:

* Issues labeled with ~feature include a well stated "why" and customer problem
* Issues labeled ~bug include steps to reproduce
* Designs are in the design tab if needed

### Definition of Done

GitLab has a documented [Definition of Done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done) for contributions to GitLab. We will follow that standard for our own definition of done.

## How to work with us

### On issues

Issues worked on by the testing group have a group label of ~"group::testing". Issues that contribute to the verify stage of the devops toolchain have the ~"devops::verify" label.