Quality Department

On this page

Child Pages


Ensure that GitLab consistently releases high-quality software across the growing suite of products, developing software at scale without sacrificing quality, stability or velocity. The quality of the product is our collective responsibility. The quality department makes sure everyone is aware of what the quality of the product is, empirically.

To execute on this, we categorize our vision into the following areas.

Culture of Quality

Ensure a culture of quality early on in the development process.

Create a timely feedback loop on Quality.

Test Automation Expertise

Own and build out test automation frameworks and infrastructure.

Continuously improve GitLab test coverage, reliability and efficiency.

Continuously improve the release process where Quality is a stakeholder.

Engineering productivity

See more details on the Engineering Productivity team page.


There are currently 3 teams under the Quality Department.

Dev stage cross-functional team

Ops stage cross-functional team

Engineering productivity team

Future teams

Experience and Performance team

The need to ensure performance and quality will not diminish as we scale, so we may consider adding a dedicated team in the future.

Currently this is being handled by each test area owners.

Workload planning and assignment

Please look at our Project Management page for an overview of the projects we currently own and contribute to.


Submitting and reviewing code

For test automation changes, it is crucial that every change is reviewed by at least one Senior Test Automation Engineer in the Quality team.

We are currently setting best practices and standards for Page Objects and REST API clients. Thus the first priority is to have test automation related changes reviewed and approved by the team. For test automation only changes, the quality team alone is adequate to review and merge the changes.

It is strongly recommended not to re-assign or ask someone else to take over a Merge Request if the original engineer is not able to complete it immediately (e.g., due to vacation, illness, etc). An exception might be if the Merge Request can be completed quickly and easily (e.g., it requires only minor changes that someone else can easily make).

Team retrospective

The Quality team holds a once-a-month 30 minute meeting for the team's retrospective. This happens one week before the public GitLab team retrospective. The retrospective is for us to reflect as a team; what went well, what went wrong and how can we improve. Emotions are not only allowed in retrospectives, they are encouraged, this is a safe environment that allows the team to discuss freely. The meeting is private only to the Quality team, however, the agenda items are public within GitLab. The agenda items are populated ahead of time, come meeting time, we discuss the items and identify a positive plan of action as needed. Important findings here can make its way into the public GitLab team retrospective in the following week.

It should be made clear that this is a retrospective and we encourage frank and sincere self-reflection. As a result, we allow passionate and emotional comments in the agenda but we ensure that they are steered towards a positive plan of action.


  • Person A: I was really disappointed by the progress of x because y. => Person B: I noticed that too, in the future let's make sure that we prevent y from happening with this plan etc.
  • Person C: I was really angry that this happened, we are not being efficient here => Person D: should we change the way we currently do things, what improvements can be made.

The Quality team retrospective agenda is only available for viewing inside GitLab. The public team retrospective contains information that is open to the public.

Release process overview

Moved to release documentation.

GitLab QA and Test Automation

The GitLab test automation framework is distributed across two projects:

Architecture overview

See the GitLab QA Documentation and current architecture overview.

Installation and execution