Quality

On this page

Vision

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 vision, we categorize our efforts into the following areas.

Culture of Quality

Bake in a culture of quality from within and early in the development process.

Create a feedback loop of Quality.

Test Automation Expertise

Own and build out our automated testing frameworks and infrastructure.

Continuously improve GitLab test coverage, reliability and efficiency.

Engineering Productivity

Continuously improve the release process where the Quality is a stakeholder.

Make metric-driven suggestions to improve engineering processes and developer productivity.

OKRs

See OKRs

Team

The current team consists of the follow individuals with their area of expertise:

Long term

Our long-term direction is to have sub-teams under Quality aligned to either a cross-functional group or focused on building productivity tooling.

Dev stage cross-functional team

Engineers in this area are embedded in the Dev cross-functional group. They are responsible for coverage of Dev stage features product catagory.

Ops stage cross-functional team

Engineers in this area are embedded in the Ops cross-functional group. They are responsible for coverage of Ops stage features product catagory.

Experience and Performance team

Developer Productivity team

Test Automation

The GitLab test automation framework is distributed across two projects:

Architecture overview

See the GitLab QA Documentation.

Our current architecture overview is here.

Installation & Execution

Development process quality

Issue Triage

Note: We are currently working on involving all of Engineering as part of the issue triage process.

The issue triage process can be found at: Issue Triage

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.

Examples:

  • 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

The release process follows this set of templates. Additional supporting docs about the release process can be found here.

Recruiting