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.
Review product requirements and designs to identify risk and steer the team on quality strategy.
Partner with all engineering teams to ensure that our products have testability built in that can be leveraged by the testing infrastructure.
Be a champion for better software design, promote proper testing practices and bug prevention strategies.
Create a feedback loop of Quality.
Create a feedback loop from test results to improve test gaps in our test suites.
Conduct test gap analysis from bugs that are filed by GitLab users.
Be a sounding-board for our end users and non-engineering stakeholders by integrating their feedback on quality into the development process.
Test Automation Expertise
Own and build out our automated testing frameworks and infrastructure.
Contribute to our integration automated testing framework.
Own and expand end-to-end automated testing framework GitLab QA.
Own and build third-party service testing capabilities.
Own and build our Continuous Integration & Delivery test pipelines.
Coach developers (internal & external) on contributing to GitLab QA test scenarios.
Continuously improve GitLab test coverage, reliability and efficiency.
Groom the test pyramid coverage and ensure that the right tests run at the right place.
Improve on the duration and de-duplication of the GitLab test suites.
Improve stability by eliminating flaky tests and transient failures.
Improve test results tracking and reporting mechanisms that aid in triaging test results.
Continuously improve the release process where the Quality is a stakeholder.
Eradicate any manual quality steps in the release process.
Ensure that we have a repeatable and consistent Quality process for every release.
Make metric-driven suggestions to improve engineering processes and developer productivity.
Build automated measurements and dashboards to gain insights into developer productivity and understand what is working and what is not.
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.