Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Guidelines

Guidelines are high-level directives on how we carry out operations and solve challenges in the Quality Engineering department.

Child Pages

Reliable tests
Debugging QA Test Failures
Tips and Tricks

Weights

We use Fibonacci Series for weights and limit the highest number to 8. The definitions are as below:

Weight Description
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.

Submitting and Reviewing code

For test automation changes, it is crucial that every change is reviewed by at least one Senior Software Engineer in Test (SET) 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 Department alone is adequate to review and merge the changes.

Test Automation & Planning

Test Failures

Debugging Test Failures

See Debugging QA Pipeline Test Failures

Priorities

Test failure priorities are defined as follow:

Building as part of GitLab

Quality Department pipeline triage rotation

This is a schedule to share the responsibility of debugging/analysing the failures in the various scheduled pipelines that run on multiple environments.

Please refer to the Debugging Failing tests guidelines for an exhaustive list of scheduled pipelines and for specific instructions on how to do an appropriate level of investigation and determine next steps for the failing test.

Responsibility

Schedule

**February 2020 March 2020 April 2020 May 2020**
Start Date DRI Secondary
2020-02-17 Jennie Louie Mark Lapierre
2020-02-24 Mark Lapierre Zeff Morgan
2020-03-02 EMEA: Tomislav Nikić
AMER: Zeff Morgan
AMER: Tiffany Rea
EMEA: Sofia Vistas
2020-03-09 AMER: Tiffany Rea
EMEA: Sofia Vistas
EMEA: Grant Young
AMER: Dan Davison
2020-03-16
(Planning week)
APAC EPE: Jen-Shin Lin
EMEA EPE: Rémy Coutable
AMER QEM: Tanya Pazitny
APAC EPE: Albert Salim
EMEA EPE: Mark Fletcher
AMER QEM: Kyle Wiebers
2020-03-23 EMEA: Grant Young
AMER: Dan Davison
APAC: Ramya Authappan
AMER: Erick Banks
2020-03-30 APAC: Ramya Authappan
AMER: Erick Banks
AMER: Jennie Louie
APAC: Anastasia McDonald
2020-04-06 AMER: Jennie Louie
APAC: Anastasia McDonald
APAC: Mark Lapierre
EMEA: Will Meek
2020-04-13
(Planning week)
APAC EPE: Albert Salim
EMEA EPE: Mark Fletcher
AMER QEM: Kyle Wiebers
APAC EPE: Jen-Shin Lin
EMEA EPE: Rémy Coutable
AMER QEM: Joanna Shih
2020-04-20 APAC: Mark Lapierre
EMEA: Will Meek
APAC: Sanad Liaquat
AMER: Nailia Iskhakova
2019-04-27 APAC: Sanad Liaquat and Tomislav Nikić
AMER: Nailia Iskhakova
EMEA: Tomislav Nikić
AMER: Désirée Chevalier
2020-05-04 EMEA: Tomislav Nikić and Sanad Liaquat
AMER: Désirée Chevalier
AMER: Zeff Morgan
EMEA: Sofia Vistas
2020-05-11
(Planning week)
APAC EPE: Jen-Shin Lin
EMEA EPE: Rémy Coutable
AMER QEM: Joanna Shih
APAC EPE: Albert Salim
EMEA EPE: Mark Fletcher
AMER QEM: Vincy Wilson
2020-05-18 AMER: Zeff Morgan
EMEA: Sofia Vistas
AMER: Tiffany Rea
EMEA: Walmyr Lima e Silva Filho
2020-05-25 AMER: Tiffany Rea
EMEA: Walmyr Lima e Silva Filho
EMEA: Grant Young
AMER: Dan Davison

Responsibilities of the DRI and Secondary for scheduled pipelines

Responsibilities of the DRI and Secondary for deployment pipelines

Engineering Productivity team rotation and escalation

In order to provide better input during the planning phase of a release, the schedule will include a member of the Engineering Productivity team during the second week of the month.