Quality Engineering is function under the Quality Department operating as several teams of Software Engineers in Test, each led by a Quality Engineering Manager reporting to the Quality Engineering Sub-Department Leader.
Quality Engineering is actively hiring! Please view our jobs page to read more and apply.
|Joanna Shih||Quality Engineering Manager, Ops|
|Ramya Authappan||Quality Engineering Manager, Dev|
|Tanya Pazitny||Director of Quality Engineering|
|Vincy Wilson||Quality Engineering Manager, Enablement, Fulfillment, Growth, ModelOps, and Sec|
|Andrejs Cunskis||Senior Software Engineer in Test, Manage:Import|
|Aleksandr Lyubenkov||Senior Software Engineer in Test, Verify:Runner|
|Anastasia McDonald||Software Engineer in Test, Create:Editor|
|Careem Ahamed||Senior Software Engineer in Test, Secure:Static Analysis|
|Chloe Liu||Senior Software Engineer in Test, Fulfillment:Purchase|
|Dan Davison||Senior Software Engineer in Test, Fulfillment:License|
|Désirée Chevalier||Senior Software Engineer in Test, Plan:Project Management|
|Erick Banks||Senior Software Engineer in Test Enablement:Search|
|Grant Young||Staff Software Engineer in Test, Enablement:Distribution|
|Harsha Muralidhar||Senior Software Engineer in Test, Secure:Threat Insights|
|John McDonnell||Senior Software Engineer in Test, Create:Gitaly|
|Mark Lapierre||Senior Software Engineer in Test, Create:Source Code|
|Nailia Iskhakova||Senior Software Engineer in Test, Enablement:Distribution|
|Nick Westbury||Senior Software Engineer in Test, Enablement:Geo|
|Richard Chong||Senior Software Engineer in Test, Verify:Pipeline Execution|
|Sanad Liaquat||Senior Software Engineer in Test, Manage:Authentication and Authorization|
|Sean Gregory||Senior Software Engineer in Test, Ecosystem:Integrations|
|Sofia Vistas||Senior Software Engineer in Test, Package:Package|
|Tiffany Rea||Software Engineer in Test, Verify:Pipeline Authoring|
|Tomislav Nikić||Software Engineer in Test, Create:Code Review|
|Valerie Burton||Software Engineer in Test, Manage:Workspace|
|Will Meek||Senior Software Engineer in Test, Secure:Composition Analysis|
|Zeff Morgan||Senior Software Engineer in Test, Verify:Runner|
Feel free to reach out to us by opening an issue on the Quality Team Tasks project or contacting us in one of the Slack channels listed below.
|Team||GitLab.com handle||Slack channel||Slack handle|
|Dev QE team||
|Ops QE team||
|Sec & Enablement QE team||
|Fulfillment & Growth QE team||
While this team operates as a several teams, we emphasize on ensuring the prioritization and needs of Engineering Leaders via stable counterparts.
Every Software Engineer in Test (SET) takes part in building our product as a DRI in GitLab's Product Quad DRIs. They work alongside Development, Product, and UX in the Product Development Workflow. As stable counterparts, SETs should be considered critical members of the core team between Product Designers, Engineering Managers and Product Managers.
Every Quality Engineering Manager is aligned with an Engineering Director in the Development Department. They work at a higher level and align cross-team efforts which maps to a Development Department section. The area a Quality Engineering Manager is responsible for is defined in the Product Stages and Groups and part of their title. This is with the exception of the Engineering Productivity team which is based on the span of control.
We have compiled a number of tips and tricks we have found useful in day-to-day Quality Engineering related tasks.
For more information, please visit our tips and tricks page.
The Quality Engineering Sub-Department has two on-call rotations: pipeline triage (SET-led) and incident management (QEM-led). These are scheduled in advance to share the responsibilities of debugging pipeline failures and representing Quality in incident responses.
For more information, please visit our on-call rotation page.
The Quality Engineering Sub-Department helps facilitate the quad-planning process. This is the participation of Product Management, Development, UX, and Quality which aims to bring test planning as a topic before the development of any feature.
For more information, please visit our quad planning page.
Reliable tests have met stricter reliability criteria than other tests in our test suite. When a failure is seen in a reliable test, it's less likely to be flakiness and more likely to be a true issue.
For more information, please visit our reliable tests page.
The Quality Engineering Sub-Department helps facilitate the risk mapping process. This requires the participation of Product Management, Development, UX, and the Quality team to develop a strategic approach to risk and mitigation planning.
For more information, please visit our risk mapping page.
The Quality Engineering Sub-Department helps facilitate the test planning process for all things related to Engineering work.
For more information, please visit our test engineering page.
If you need to debug a test failure, please visit our debugging QA pipeline test failures page.
For test automation changes, it is crucial that every change is reviewed by at least one Senior Software Engineer in Test 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 Engineering Sub-Department alone is adequate to review and merge the changes.
We use Fibonacci Series for weights and limit the highest number to 8. The definitions are as below:
|1 - Trivial||Simple and quick changes (e.g. typo fix, test tag update, trivial documentation additions)|
|2 - Small||Straight forward changes, no underlying dependencies needed. (e.g. new test that has existing factories or page objects)|
|3 - Medium||Well understood changes with a few dependencies. Few surprises can be expected. (e.g. new test that needs to have new factories or page object / page components)|
|5 - Large||A task that will require some investigation and research, in addition to the above weights (e.g. Tests that need framework level changes which can impact other parts of the test suite)|
|8 - X-large||A very large task that will require much investigation and research. Pushing initiative level|
|13 or more||Please break the work down further, we do not use weights higher than 8.|