mirror of
https://github.com/avito-tech/playbook.git
synced 2026-03-14 06:02:56 +03:00
70 lines
7.8 KiB
Markdown
70 lines
7.8 KiB
Markdown
# Профили QA-инженеров
|
||
|
||
Профили QA-инженеров нужны, чтобы оценивать коллег в соответствии с их уровнем на [performance review](https://github.com/avito-tech/playbook/blob/master/goal-setting.md#performance-review). Это делает продвижение по карьерной лестнице понятным и прозрачным.
|
||
|
||
## Карьерная лестница
|
||
Карьерная лестница — это возможный путь развития сотрудника в Авито. Он зависит от того, какие задачи решает специалист и какие основные навыки использует в работе.
|
||
|
||
Сейчас в Авито существуют такие уровни QA-инженеров:
|
||
|
||
- [Е1](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е1)
|
||
- [Е2](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е2)
|
||
- [Е3](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е3)
|
||
- [Е4](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е4)
|
||
- [Е5](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е5)
|
||
- [Е6](https://github.com/avito-tech/playbook/blob/master/QA-profile.md#е6)
|
||
|
||
Двигаться ли по карьерной лестнице — это решение самого сотрудника. Многое зависит от его проактивности и желания учиться. Задача менеджера — помочь специалисту в развитии. Например, подключать к новым задачам, давать возможность для участия в кросс-функциональных проектах.
|
||
|
||
## Как работают профили
|
||
- Ожидания каждого следующего уровня добавляются к ожиданиям предыдущих. Например, E4-инженер должен уметь делать всё то же самое, что E1, E2 и E3.
|
||
- Сотрудник должен проявить навыки и компетенции своего или следующего профиля на деле. Просто уметь или хотеть делать недостаточно.
|
||
- Если менеджер считает, что специалисту в команде не нужен какой-то навык, то его можно не учитывать.
|
||
|
||
### Е1
|
||
- Тестирует отдельные задачи ad hoc, то есть без подготовки тестовой документации и без ожидаемого результата.
|
||
- Пишет чек-листы и тест-кейсы на позитивные и негативные сценарии.
|
||
- Перепроверяет закрытые баги и пишет понятные баг-репорты.
|
||
|
||
### Е2
|
||
- Составляет тестовые модели для части функциональности продукта.
|
||
- Может в любой момент рассказать о качестве фич, с которыми работает.
|
||
- Разрабатывает и поддерживает тест-кейсы и интеграционные и е2е-автотесты.
|
||
- Применяет основные техники тест-дизайна, например классы эквивалентности.
|
||
- Следит за полнотой покрытия тестами, например учитывает негативные сценарии, граничные значения, проверяет все возможные ветви бизнес-процессов.
|
||
- Разбирает отчёты автотестов, перепроверяет ошибки.
|
||
- Использует подход risk-based testing или другую методологию, чтобы оценить риски по задачам.
|
||
|
||
### Е3
|
||
- Владеет тестовой моделью всей функциональности продукта, следит, чтобы покрытие кода было полным.
|
||
- Тестирует продукт на разных уровнях, например UI и API.
|
||
- Разрабатывает, поддерживает и улучшает интеграционные, компонентные, е2е-автотесты.
|
||
- Применяет шаблон проектирования PageObjects.
|
||
- Следит, чтобы команда придерживалась пирамиды тестирования.
|
||
- Составляет тест-кейсы и обсуждает с разработчиками, как автоматизация распределена по пирамиде тестирования.
|
||
- Ведёт процессы SPT/ZBP в команде, обеспечивает SLO для решения проблем пользователей и багов.
|
||
- Вместе с владельцем продукта составляет критерии приёмки по процессу ATDD.
|
||
- Отслеживает достижение baseline по team maturity model в QA-секции.
|
||
- Обучает коллег по команде лучшим практикам тестирования.
|
||
|
||
### Е4
|
||
- В любой момент может рассказать команде о качестве всех фич и продукта в целом.
|
||
- Фокусирует команду на улучшении качества продукта.
|
||
- Разрабатывает тесты на backend и client-side, чтобы обеспечивать покрытие на всех уровнях системы.
|
||
- Прорабатывает юнит-тесты вместе с разработчиками.
|
||
- Проверяет качество покрытия юнит-тестами через код-ревью или с помощью мутационного тестирования.
|
||
- Исследует проблемы flaky-тестов и самостоятельно устраняет причины.
|
||
- Меняет процессы, если видит баги от команды.
|
||
|
||
### Е5
|
||
- В любой момент может показать качество продукта с помощью объективных метрик.
|
||
- Оценивает риски в больших проектах. Объясняет, что, где и почему может пойти не так.
|
||
- Разрабатывает автотесты больше чем на трёх разных платформах.
|
||
- Может настроить тестовый контур для интеграционного тестирования фич в юните и добавить дополнительные Quality Gates в CI/CD команды.
|
||
- Улучшает инструменты тестирования в команде и экосистеме тестирования Авито.
|
||
- Проводит нефункциональные тесты, например performance и security, привлекает для этого экспертов.
|
||
|
||
### Е6
|
||
- Создаёт новые инструменты для обеспечения качества. Например, фреймворк для интеграционного тестирования автозагрузки или скрипты сравнения диффов в системе управления метаданными Авито.
|
||
- Проводит исследования, чтобы оценить качество продукта в целом. Например, проверяет гипотезы качества на пользователях. Проводит сравнительное тестирование с продуктами конкурентов.
|