SDET (Software Development Engineer in Test)

Также называют: Software Development Engineer in Test, Software Engineer in Test, Test Automation Engineer, Test Infrastructure Engineer, Quality Engineer.

Кто такой SDET и чем он занимается?

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

• проектирует архитектуру автотестов и пишет фреймворк, на котором их пишет вся команда;
• встраивает тесты в CI/CD и следит за скоростью и стабильностью прогонов;
• разбирается с нестабильными тестами и устраняет их причины, а не перезапускает прогон;
• строит тестовые окружения, моки и генерацию тестовых данных;
• ревьюит код разработчиков с точки зрения тестируемости и предлагает изменения в архитектуре.

Когда компании нужен SDET?

SDET нужен, когда тестирование стало узким местом релизов: прогон тестов идёт часами, тесты падают без причины, а разработчики перестали им доверять. Обычно это продуктовая компания с несколькими командами и частыми релизами, где ручная регрессия и разрозненные автотесты уже не справляются. Ещё один триггер — переход к модели, в которой разработчики сами пишут тесты, и им нужны удобные инструменты. Роль не сработает, если продукт маленький и меняется редко, а главная проблема — непродуманные сценарии и пропущенные риски: тогда нужен QA Engineer.

Чем SDET отличается от QA Automation Engineer?

SDET отличается от QA Automation Engineer тем, что проектирует саму систему тестирования, а QA Automation Engineer обычно пишет автотесты внутри готового фреймворка. SDET работает с разработчиками на равных: ревьюит их код, меняет систему, чтобы её было легко тестировать, и отвечает за скорость и стабильность прогонов. От QA Engineer его отличает то, что он идёт от кода и инфраструктуры, а не от сценариев пользователя.

Почему SDET сложно нанять?

SDET сложно нанять, потому что нужен разработчик полного уровня, который при этом выбрал тестирование своей специализацией.

• Название используют по-разному: под вакансией SDET часто скрывается обычная автоматизация тестов, поэтому кандидаты с нужным уровнем не верят таким вакансиям.
• Сильные разработчики редко уходят в тестовую инфраструктуру, а большинство людей из автоматизации тестирования не дотягивают до уровня разработки.
• SDET должен писать на языке ваших разработчиков, и это сильно сужает круг кандидатов.
• Результат работы плохо виден в резюме: «написал фреймворк» не говорит, насколько быстрее и стабильнее стали релизы.

Что выяснить до найма SDET?

• Что есть сейчас: автотестов нет, есть нестабильный набор тестов или фреймворк, который нужно масштабировать? Строить с нуля и чинить чужое — разные задачи и разные кандидаты.
• Какие уровни тестирования важнее: unit, API, UI, контрактные, нагрузочные, оценка ML-моделей? От ответа зависит, чей опыт ценнее: бэкенд, фронтенд или ML.
• Сколько сейчас идёт прогон тестов в CI и как часто он падает без причины? Это стартовая точка, по которой потом оценят работу SDET.
• На каком языке и стеке пишут ваши разработчики? SDET на другом языке не сможет ревьюить их код и встроить тесты в их работу.

Где искать SDET?

SDET чаще всего приходят из продуктовых компаний со зрелой инженерной культурой: крупных B2B- и B2C-продуктов, финтеха, инструментов для разработчиков, облачных платформ. Одни — Backend Developers, которые ушли в тестовую инфраструктуру, другие выросли из автоматизации тестирования до уровня разработки. Сильный сигнал в профиле — фреймворк или инструмент, который человек построил и который используют другие команды, а также open-source вклад в инструменты тестирования. NEWHR ищет таких кандидатов по результатам работы, а не по откликам на вакансию.

Как проверить SDET на интервью?

SDET проверяют разбором тестовой инфраструктуры, которую кандидат строил, кодинг-интервью на уровне ваших разработчиков и задачей на проектирование. В задаче кандидат решает, как тестировать конкретный ваш сервис: какие уровни, какие данные, как встроить это в CI. Со стороны компании участвуют Engineering Manager или QA Lead и разработчик из команды, которая будет пользоваться результатом.

Сильные сигналы:

• рассказывает, сколько шёл пайплайн до и после его работы и как изменилась частота ложных падений;
• предлагает изменить код продукта, чтобы его стало проще тестировать;
• объясняет, какие тесты стоит удалить, а не только какие добавить.

Красные флаги:

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

Сколько длится поиск SDET?

Первых кандидатов на роль SDET показываем через 5–7 дней после брифа.

Смежные роли

• QA Engineer — идёт от продукта и пользователя: тест-дизайн, риски, исследовательское тестирование.
• DevOps Engineer — отвечает за CI/CD и инфраструктуру в целом, а не за систему тестирования.
• Platform Engineer — строит внутреннюю платформу для разработки, а не систему тестирования.
• Evals Engineer — строит систему оценки качества AI-моделей, близкую по логике к тестовой инфраструктуре.