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.
Ensure a culture of quality early on in the development process.
Create a timely feedback loop on Quality.
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.
See more details on the Engineering Productivity team page.
There are currently 3 teams under the Quality Department.
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.
Please look at our Project Management page for an overview of the projects we currently own and contribute to.
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).
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
Person B: I noticed that too, in the future let's make sure that we prevent
yfrom happening with this plan etc.
Person C: I was really angry that
thishappened, 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.
Moved to release documentation.
The GitLab test automation framework is distributed across two projects: