Кем являются SDET специалисты и чем они занимаются

Что проверяют

Понимаете ли вы, чем SDET отличается от ручного тестировщика и от автоматизатора, который пишет тесты по готовым шаблонам. Следом часто просят описать, как бы вы построили тестовый фреймворк на Python с нуля или встроили тесты в CI.

Как отвечать

SDET (Software Development Engineer in Test) это разработчик, у которого предметная область это качество. Он пишет код того же уровня, что и продуктовые разработчики, только этот код проверяет систему и ускоряет обратную связь. Основные задачи:

• тестовая инфраструктура: фреймворк на pytest с фикстурами в conftest.py, параметризацией через @pytest.mark.parametrize, фабриками тестовых данных и читаемыми отчётами, например в Allure;
• автотесты на разных уровнях: API через httpx или requests, UI через Playwright или Selenium, интеграционные тесты с настоящей базой в контейнере через testcontainers, контрактные тесты между сервисами;
• CI/CD: тесты гоняются на каждом merge request в GitLab CI или GitHub Actions, параллелятся через pytest-xdist, а нестабильные тесты чинятся, а не перезапускаются до зелёного;
• тестируемость: SDET участвует в ревью кода и дизайна, просит нужные хуки, флаги и тестовые окружения;
• нефункциональные проверки: нагрузочные сценарии на Locust, базовые проверки безопасности.

Отличие от автоматизатора в широте ответственности. SDET отвечает за то, чтобы проверки были быстрыми, стабильными и встроенными в процесс, и держит в голове пирамиду тестирования: много дешёвых unit и API тестов, мало медленных UI.

Хорошо, если добавите пример из своего опыта: какой фреймворк собрали, сколько в нём тестов, насколько сократили время прогона.

Где спотыкаются

Сводят роль к «пишу автотесты на Selenium». Это часть работы, но от SDET ждут инженерного подхода к архитектуре тестового кода и к процессу в целом.

Пишут тестовый код хуже продуктового: копипаста, time.sleep() вместо явных ожиданий, общие данные между тестами. Вопросы про паттерны вроде Page Object и про ревью тестов почти гарантированы.

Не думают о стабильности. Набор, в котором каждый пятый прогон красный без причины, команда перестаёт читать, и тесты теряют смысл.