Разработка
Разработчик
Пять уровней от Junior до Principal и шесть компетенций — от разработки и выпуска до развития команды.
- 5 уровней
- 6 компетенций
Шаблон карьерной лестницы
Грейды QA-инженера: шаблон карьерной лестницы
Четыре уровня от Junior QA до Lead QA и шесть компетенций — от тест-дизайна до практик качества в команде.
Бесплатный тариф · Банковская карта не нужна
Эта карьерная лестница написана для QA-инженеров в компаниях примерно на 20–200 человек: тестировщики работают внутри продуктовых команд, на всю компанию их может быть всего несколько, и один и тот же человек утром проводит исследовательское тестирование, а после обеда пишет автотесты. В ней четыре уровня — от человека, который учится хорошо тестировать одну фичу, до того, кто определяет подход к качеству во всей компании. Верхний уровень, Lead QA-инженер, — экспертный, а не управленческий.
Каждый уровень описан через то, что человек делает и насколько далеко распространяется его работа, а не через стаж или число заведённых багов. Читайте строку матрицы компетенций слева направо, чтобы увидеть, как растёт одно ожидание, или раздел уровня — чтобы увидеть всё, что ожидается на нём. С её помощью удобно объяснять, что значит следующий шаг, проводить самооценку и чек-ины и сравнивать кандидатов на повышение между командами.
Считайте её черновиком. Если ваши QA-инженеры не пишут автотесты или большую часть тестирования берут на себя разработчики, поправьте формулировки до публикации: ожидание, которое в ваших условиях невыполнимо, только демотивирует.
Уровни коротко
Junior QA-инженер
Тестирует чётко описанные фичи по готовым тест-кейсам и изучает продукт и его пользователей.
- Масштаб
- Отдельные истории или исправления багов в одной части продукта; тест-планы проверяет кто-то опытнее.
Middle QA-инженер
Отвечает за тестирование фич одной команды — от разбора требований до решения о релизе.
- Масштаб
- Фичи одной продуктовой команды вместе с их ручными и автоматическими тестами.
Senior QA-инженер
Определяет, как одна–две команды встраивают качество в работу, и отвечает за стратегию тестирования крупных проектов.
- Масштаб
- Стратегия тестирования, наборы автотестов и решения о релизах одной–двух команд, а также проекты на стыке команд.
Lead QA-инженер
Задаёт подход компании к качеству и помогает каждой команде выпускать продукт с меньшим числом пропущенных дефектов.
- Масштаб
- Качество всего продукта: общая тестовая инфраструктура, стандарты релизов и то, как устроена и работает функция QA.
Матрица компетенций
Строки — компетенции, столбцы — уровни. Читайте строку слева направо, чтобы увидеть, как растёт ожидание.
Что означает каждая компетенция
- Тест-дизайн и анализ
- Понимать, что может пойти не так, и выбирать тесты, которые это найдут.
- Автоматизация тестирования
- Строить быстрые и стабильные автотесты, которым команда доверяет.
- Поиск и описание дефектов
- Находить, воспроизводить и объяснять проблемы так, чтобы их быстро исправляли.
- Решения о релизе и оценка рисков
- Решать, готово ли что-то к выпуску, и ясно говорить об этом.
- Практики качества
- Встраивать качество в то, как работает команда, а не проверять его только в конце.
- Менторство и обмен знаниями
- Помогать другим тестировать лучше и не давать знаниям о продукте жить в одной голове.
| Компетенция | Junior QA-инженер | Middle QA-инженер | Senior QA-инженер | Lead QA-инженер |
|---|---|---|---|---|
| Тест-дизайн и анализ | Внимательно проходит готовые тест-кейсы, пишет новые для небольших историй с основным сценарием и очевидными граничными случаями и до начала тестирования уточняет неясные требования. | Пишет тест-план для каждой фичи команды с граничными случаями, правами доступа, состояниями данных и интеграциями и ещё до начала разработки ищет пробелы в требованиях. | Разрабатывает стратегию тестирования проектов, затрагивающих несколько фич или команд, решает, что покрывать на уровне unit-, API- и end-to-end-тестов, и сосредотачивает усилия на том, что вероятнее всего сломается. | Определяет, как в компании решают, что и насколько глубоко тестировать, исходя из рисков и данных об использовании, и следит, чтобы все команды применяли этот подход единообразно. |
| Автоматизация тестирования | Добавляет автотесты в существующий фреймворк по принятым образцам, запускает набор локально и сообщает о непонятных падениях, а не перезапускает тесты, пока они не позеленеют. | Автоматизирует регрессионные тесты для фич команды, поддерживает их стабильными и читаемыми и чинит или удаляет нестабильные тесты, а не игнорирует их. | Проектирует структуру набора автотестов, встраивает его в CI/CD-пайплайн с разумным временем прогона и ревьюит тесты, которые пишут разработчики и другие QA-инженеры. | Выбирает инструменты тестирования и общую инфраструктуру компании, балансирует уровни пирамиды тестирования по всем продуктам и держит весь набор достаточно быстрым, чтобы команды действительно дожидались результата. |
| Поиск и описание дефектов | Заводит баг-репорты с понятными шагами, ожидаемым и фактическим результатом и окружением, чтобы разработчик мог воспроизвести проблему без уточняющих вопросов. | Локализует баги по логам, сетевым запросам и данным в базе, оценивает их критичность по влиянию на пользователей и проверяет исправления вместе со смежными сценариями. | Расследует плавающие и воспроизводящиеся только на продакшене проблемы на стыке сервисов, замечает закономерности в повторяющихся дефектах и превращает их в предложения, которые устраняют целый класс багов. | Отвечает за то, как в компании учитывают и приоритизируют дефекты, докладывает руководству разработки о динамике пропущенных багов и добивается, чтобы на устранение главных источников дефектов выделялись ресурсы. |
| Решения о релизе и оценка рисков | Выполняет назначенные проверки перед релизом, сообщает, что было протестировано, а что нет, и поднимает сомнения перед более опытным QA-инженером. | Даёт ясную рекомендацию «выпускаем» или «не выпускаем» по релизам команды, объясняя известные риски и то, что осталось непроверенным, и участвует в проверках после релиза. | Вместе с разработчиками выбирает способ выпуска рискованных изменений — фиче-флаги, поэтапную раскатку, дополнительный мониторинг — и руководит тестированием во время инцидентов и хотфиксов. | Задаёт стандарты релизов для всех команд, определяет, когда релиз можно остановить, и именно к нему руководство приходит с вопросом, готов ли продукт к крупному запуску. |
| Практики качества | Следует принятому в команде определению готовности и процессу тестирования и сообщает о шагах, которые пропускаются или непонятны. | Участвует в груминге и обсуждении решений, чтобы заранее добавить критерии приёмки и вопросы тестируемости, и вместе с разработчиками решает, что им покрыть своими тестами. | Улучшает процесс тестирования одной–двух команд — тестовые окружения, тестовые данные, чек-листы ревью — и измеряет, стало ли меньше пропущенных дефектов. | Формирует практики качества во всей разработке, решает, где работают QA-инженеры и за что отвечают разработчики, и делает качество общей ответственностью, а не задачей одной команды. |
| Менторство и обмен знаниями | Записывает то, что узнаёт о продукте в ходе тестирования, и делится с командой полезными находками и инструментами. | Поддерживает тестовую документацию команды в актуальном состоянии, вводит новых коллег в свою часть продукта и объясняет техники тестирования разработчикам, которые об этом просят. | Целенаправленно менторит junior QA-инженеров, проводит для разработчиков сессии о подходах к тестированию и участвует в собеседованиях на позиции QA. | Развивает навыки и карьерные пути в QA-группе, определяет, как нанимают и онбордят QA-инженеров, и выращивает следующих senior- и lead-инженеров. |
Прокрутите таблицу вбок, чтобы увидеть все уровни.
Скачать в CSV Открывается в Excel, Google Таблицах и Numbers.
Junior QA-инженер: что ожидается
Тестирует чётко описанные фичи по готовым тест-кейсам и изучает продукт и его пользователей. Отдельные истории или исправления багов в одной части продукта; тест-планы проверяет кто-то опытнее.
- Тест-дизайн и анализ
- Внимательно проходит готовые тест-кейсы, пишет новые для небольших историй с основным сценарием и очевидными граничными случаями и до начала тестирования уточняет неясные требования.
- Автоматизация тестирования
- Добавляет автотесты в существующий фреймворк по принятым образцам, запускает набор локально и сообщает о непонятных падениях, а не перезапускает тесты, пока они не позеленеют.
- Поиск и описание дефектов
- Заводит баг-репорты с понятными шагами, ожидаемым и фактическим результатом и окружением, чтобы разработчик мог воспроизвести проблему без уточняющих вопросов.
- Решения о релизе и оценка рисков
- Выполняет назначенные проверки перед релизом, сообщает, что было протестировано, а что нет, и поднимает сомнения перед более опытным QA-инженером.
- Практики качества
- Следует принятому в команде определению готовности и процессу тестирования и сообщает о шагах, которые пропускаются или непонятны.
- Менторство и обмен знаниями
- Записывает то, что узнаёт о продукте в ходе тестирования, и делится с командой полезными находками и инструментами.
Middle QA-инженер: что ожидается
Отвечает за тестирование фич одной команды — от разбора требований до решения о релизе. Фичи одной продуктовой команды вместе с их ручными и автоматическими тестами.
- Тест-дизайн и анализ
- Пишет тест-план для каждой фичи команды с граничными случаями, правами доступа, состояниями данных и интеграциями и ещё до начала разработки ищет пробелы в требованиях.
- Автоматизация тестирования
- Автоматизирует регрессионные тесты для фич команды, поддерживает их стабильными и читаемыми и чинит или удаляет нестабильные тесты, а не игнорирует их.
- Поиск и описание дефектов
- Локализует баги по логам, сетевым запросам и данным в базе, оценивает их критичность по влиянию на пользователей и проверяет исправления вместе со смежными сценариями.
- Решения о релизе и оценка рисков
- Даёт ясную рекомендацию «выпускаем» или «не выпускаем» по релизам команды, объясняя известные риски и то, что осталось непроверенным, и участвует в проверках после релиза.
- Практики качества
- Участвует в груминге и обсуждении решений, чтобы заранее добавить критерии приёмки и вопросы тестируемости, и вместе с разработчиками решает, что им покрыть своими тестами.
- Менторство и обмен знаниями
- Поддерживает тестовую документацию команды в актуальном состоянии, вводит новых коллег в свою часть продукта и объясняет техники тестирования разработчикам, которые об этом просят.
Senior QA-инженер: что ожидается
Определяет, как одна–две команды встраивают качество в работу, и отвечает за стратегию тестирования крупных проектов. Стратегия тестирования, наборы автотестов и решения о релизах одной–двух команд, а также проекты на стыке команд.
- Тест-дизайн и анализ
- Разрабатывает стратегию тестирования проектов, затрагивающих несколько фич или команд, решает, что покрывать на уровне unit-, API- и end-to-end-тестов, и сосредотачивает усилия на том, что вероятнее всего сломается.
- Автоматизация тестирования
- Проектирует структуру набора автотестов, встраивает его в CI/CD-пайплайн с разумным временем прогона и ревьюит тесты, которые пишут разработчики и другие QA-инженеры.
- Поиск и описание дефектов
- Расследует плавающие и воспроизводящиеся только на продакшене проблемы на стыке сервисов, замечает закономерности в повторяющихся дефектах и превращает их в предложения, которые устраняют целый класс багов.
- Решения о релизе и оценка рисков
- Вместе с разработчиками выбирает способ выпуска рискованных изменений — фиче-флаги, поэтапную раскатку, дополнительный мониторинг — и руководит тестированием во время инцидентов и хотфиксов.
- Практики качества
- Улучшает процесс тестирования одной–двух команд — тестовые окружения, тестовые данные, чек-листы ревью — и измеряет, стало ли меньше пропущенных дефектов.
- Менторство и обмен знаниями
- Целенаправленно менторит junior QA-инженеров, проводит для разработчиков сессии о подходах к тестированию и участвует в собеседованиях на позиции QA.
Lead QA-инженер: что ожидается
Задаёт подход компании к качеству и помогает каждой команде выпускать продукт с меньшим числом пропущенных дефектов. Качество всего продукта: общая тестовая инфраструктура, стандарты релизов и то, как устроена и работает функция QA.
- Тест-дизайн и анализ
- Определяет, как в компании решают, что и насколько глубоко тестировать, исходя из рисков и данных об использовании, и следит, чтобы все команды применяли этот подход единообразно.
- Автоматизация тестирования
- Выбирает инструменты тестирования и общую инфраструктуру компании, балансирует уровни пирамиды тестирования по всем продуктам и держит весь набор достаточно быстрым, чтобы команды действительно дожидались результата.
- Поиск и описание дефектов
- Отвечает за то, как в компании учитывают и приоритизируют дефекты, докладывает руководству разработки о динамике пропущенных багов и добивается, чтобы на устранение главных источников дефектов выделялись ресурсы.
- Решения о релизе и оценка рисков
- Задаёт стандарты релизов для всех команд, определяет, когда релиз можно остановить, и именно к нему руководство приходит с вопросом, готов ли продукт к крупному запуску.
- Практики качества
- Формирует практики качества во всей разработке, решает, где работают QA-инженеры и за что отвечают разработчики, и делает качество общей ответственностью, а не задачей одной команды.
- Менторство и обмен знаниями
- Развивает навыки и карьерные пути в QA-группе, определяет, как нанимают и онбордят QA-инженеров, и выращивает следующих senior- и lead-инженеров.
Как адаптировать эту лестницу
Зафиксируйте соотношение ручного и автоматического тестирования
Если ваши QA-инженеры в основном проводят исследовательское тестирование, сократите строку «Автоматизация тестирования» и расширьте «Тест-дизайн и анализ». Если они в основном пишут автотесты, поднимите ожидания к качеству кода. В любом случае сделайте выбор явным, чтобы никого не оценивали по работе, ради которой его не нанимали.
Вводите уровень Lead, только когда это реальная работа
Когда в компании два–три QA-инженера, обычно хватает уровней junior, middle и senior. Добавляйте Lead, когда кто-то действительно задаёт стандарты качества для всех команд, а не в награду тому, кто дольше всех тестирует. В этой лестнице Lead — экспертный уровень; если ваш QA-лид ещё и руководит тестировщиками, добавьте ожидания по работе с людьми из лестницы руководителя разработки.
Сопоставьте уровни с лестницей разработчика
Привяжите каждый уровень QA к уровню разработчика с похожими масштабом и зарплатой. Когда Senior QA-инженер стоит рядом с Senior-разработчиком, переход между треками становится шагом в сторону, а не понижением или скачком.
Собирайте примеры, а не число багов
Для чек-инов и решений о повышении собирайте примеры: тест-план, который поймал дорогой дефект, нестабильный набор автотестов, ставший надёжным, решение о релизе, которое оказалось верным. Подсчёт заведённых багов поощряет шум и наказывает тестировщиков в стабильных командах.
Вопросы и ответы
Вопросы об этой лестнице
Сколько грейдов нужно QA-инженеру?
Для компании на 20–200 человек обычно хватает трёх–четырёх: QA-группы там небольшие. В этом шаблоне четыре: Junior, Middle, Senior и Lead QA-инженер. Пятый уровень стоит добавлять, только если масштаб работы действительно вырос дальше стандартов качества для всего продукта.
Нужна ли ручным тестировщикам и автоматизаторам общая карьерная лестница?
В большинстве небольших компаний — да. Суть работы — понимать риски, проектировать тесты и принимать решения о релизе — одна и та же, различаются только инструменты. Оставьте одну лестницу и договоритесь для каждого человека или команды, в какой мере к ним относится строка «Автоматизация тестирования».
Может ли QA-инженер перейти в разработку?
Да, и лучше всего, когда такой переход спланирован. Сравните человека с лестницей разработчика, договоритесь о нескольких задачах развития — например, о небольших фичах или исправлениях багов — и переводите его, когда он стабильно соответствует нужному уровню. Опыт тестирования обычно делает его сильнее как разработчика, а не слабее.
Как оценивать работу QA-инженера, не считая баги?
Смотрите на результаты и поведение: сколько дефектов в его зоне ушло в продакшен, насколько надёжны и быстры автотесты, как рано он поднимает риски и оправдались ли его решения о релизах. Обсуждайте конкретные примеры по лестнице на регулярных чек-инах, а не полагайтесь только на дашборды.
Сколько QA-инженеров нужно на команду разработчиков?
Фиксированной пропорции нет. Многие компании такого размера работают с одним QA-инженером на четыре–восемь разработчиков, но правильное число зависит от того, сколько разработчики тестируют сами и насколько дорог дефект для ваших пользователей. Следите за пропущенными дефектами и задержками релизов и нанимайте, когда какой-то из этих показателей устойчиво растёт.
Соберите эту карьерную лестницу в LadderKit — бесплатно
Задайте её уровни и навыки для своей команды, оценивайте людей по ним на чек-инах и принимайте решения о повышении по единым правилам.
Бесплатный тариф · Банковская карта не нужна
Похожие шаблоны
Разработка
DevOps-инженер
Четыре уровня от Junior до Staff DevOps-инженера и шесть компетенций — от инфраструктуры до помощи разработчикам.
- 4 уровня
- 6 компетенций
Разработка
Руководитель разработки
Четыре уровня от Engineering Manager до VP of Engineering и шесть управленческих компетенций.
- 4 уровня
- 6 компетенций