Commit 8af74dc3 authored May 22, 2026 by Nadya Denisenko

Transition Software Engineer in Test (SET) to Backend Engineer, Quality...

Transition Software Engineer in Test (SET) to Backend Engineer, Quality Department and Engineering Productivity departments clean-up

parent 9da08370

assets/includes/engineering-careers/career-matrix-nav.md

+0 −1

Original line number	Diff line number	Diff line
		@@ -3,7 +3,6 @@
		[Engineering](/handbook/engineering/careers/matrix/) \|
		[Development](/handbook/engineering/careers/matrix/development/) \|
		[Infrastructure](/handbook/engineering/careers/matrix/infrastructure/) \|
		[Quality](/handbook/engineering/careers/matrix/quality/) \|
		[Support](/handbook/engineering/careers/matrix/support/)

		---

assets/includes/engineering-careers/quality-staff-technical-competency.md

+2 −0

Original line number	Diff line number	Diff line
		<!-- DEPRECATED: The Software Engineer in Test role has transitioned to Backend Engineer. This file is no longer in use. See the Backend Engineer career matrix at /handbook/engineering/careers/matrix/infrastructure/ -->

		##### Quality

		- Test Strategy (Quad Planning) & Test Coverage

assets/includes/performance_indicator_links.md

+0 −1

Original line number	Diff line number	Diff line
		@@ -3,7 +3,6 @@
		* [Customer Support Department Performance Indicators](/handbook/support/performance-indicators/)
		* [Development Department Performance Indicators](/handbook/engineering/development/performance-indicators/)
		* [Infrastructure Department Performance Indicators](/handbook/engineering/infrastructure/performance-indicators/)
		* [Quality Department Performance Indicators](/handbook/engineering/infrastructure/performance-indicators/)
		* [Security Department Performance Indicators](/handbook/security/performance-indicators/)
		* [Product Performance Indicators](https://internal.gitlab.com/handbook/company/performance-indicators/product/)
		* [Dev Section Performance Indicators](https://internal.gitlab.com/handbook/company/performance-indicators/product/)

content/handbook/company/structure.md

+0 −1

Original line number	Diff line number	Diff line
		@@ -510,7 +510,6 @@ Sometimes there is a lead in this topic that they report to.
		You can be a specialist in only one topic.
		The specialist description is a paragraph in the job description for a certain title.
		A specialist is listed after a title, for example: Developer, database specialist (do not shorten it to Developer, database).
		Many specialties represent stable counterparts. For instance, a "Software Engineer in Test, Create" specializes in the "Create" stage group and is dedicated to that group.
		If you can have multiple ones and/or if you don't spend the majority of your time there it is probably an [expertise](#expert).
		Since a specialist has the same job description as others with the title they have the same career path and compensation.

content/handbook/customer-success/professional-services-engineering/professional-services-delivery-methodology/gitlab-best-practices/_index.md

+1 −1

Original line number	Diff line number	Diff line
		@@ -112,7 +112,7 @@ Before taking the decision to merge:
		* Set the milestone.
		* Confirm that the correct [MR type label](https://docs.gitlab.com/ee/development/labels/index.html#type-labels) is applied.
		* Consider warnings and errors from danger bot, code quality, and other reports. Unless a strong case can be made for the violation, these should be resolved before merging. A comment must be posted if the MR is merged with any failed job.
		* If the MR contains both Quality and non-Quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the Quality related changes are approved by a Software Engineer in Test.
		* If the MR contains both quality and non-quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the quality-related changes are approved by a member of the [Developer Experience](/handbook/engineering/infrastructure-platforms/developer-experience/) team.

		At least one maintainer must approve an MR before it can be merged. MR authors and people who add commits to an MR are not authorized to approve the MR and must seek a maintainer who has not contributed to the MR to approve it. In general, the final required approver should merge the MR.