Как начать создание структуры отдела тестирования и какие инструменты применить
Что проверяют
Умеете ли вы начинать с процесса и рисков, а не с покупки инструментов. Вопрос задают кандидатам в лиды или первому QA в компании. Следом уточняют, что конкретно вы сделаете в первый месяц и по каким метрикам поймёте, что стало лучше.
Как отвечать
Стройте ответ как план по этапам:
- аудит: как выпускается продукт, кто и когда тестирует, сколько дефектов доходит до прода и где их находят, есть ли стенды и тестовые данные. Разговоры с разработкой, продактами и поддержкой дадут больше, чем схема из книги;
- модель команды: чаще всего QA-инженеры сидят в продуктовых командах, а общий цех (chapter, гильдия) держит стандарты, шаблоны и инфраструктуру автотестов. Отдельный отдел «в конце конвейера» быстро становится узким местом;
- процесс: тестовая стратегия, критерии готовности задачи, участие QA в разборе требований до разработки, пирамида тестов с упором на unit и API и небольшим числом UI-сценариев;
- инструменты: трекер (Jira, YouTrack), тест-кейсы (TestRail, Qase, Allure TestOps), UI-автотесты на Playwright или Selenium, API на REST Assured или pytest с
requests, мобильные на Appium, нагрузка на k6, JMeter или Gatling, отчёты в Allure, запуск в GitLab CI или Jenkins; - метрики: дефекты, ушедшие в прод, время от готовности задачи до релиза, доля нестабильных автотестов, покрытие критичных пользовательских сценариев.
Инструменты подбирайте под стек и людей: если разработка пишет на TypeScript, автотесты на Playwright с TypeScript смогут поддерживать и разработчики. Если отдел с нуля вы не строили, так и скажите, опирайтесь на опыт работы внутри такой структуры и назовите, что сделали бы иначе.
Где спотыкаются
Начинают со списка инструментов. Инструмент без процесса автоматизирует хаос, и через полгода команда поддерживает сотни падающих тестов, которым никто не верит.
Автоматизируют всё подряд, включая нестабильные фичи. Автотесты окупаются на регрессе стабильных сценариев, а не на экранах, которые переделывают каждый спринт.
Меряют тестировщиков числом заведённых багов. Такая метрика поощряет дробить дефекты и воевать с разработкой, а не снижать число проблем у пользователей.