Один и тот же тайтл "SDET" может описывать человека который кликает по веб-приложению вручную и человека который проектирует инфраструктуру тест-платформы для 200 инженеров: индустрия так и не стандартизировала что именно стоит за каждым названием. Фильтровать поиск работы по тайтлу значит тратить месяцы на неподходящие роли. Статья разбирает что каждый из трёх тайтлов реально сигнализирует в вакансиях 2026 года, в чём реальная разница по навыкам, и как читать требования вместо тайтлов при оценке позиции.
Почему QA-тайтлы окончательно сломаны
В большинстве отраслей названия должностей означают примерно одно и то же в разных компаниях. Staff accountant занимается стафф-аккаунтингом. Гражданский инженер проектирует гражданские объекты. В QA один и тот же тайтл может описывать две работы у которых почти нет пересечений в ежедневных задачах.
Хаос возник по нескольким причинам. Тестирование как дисциплина развивалось быстро: от выделенных ручных тестировщиков в 90-х, к ролям с фокусом на автоматизацию в 2000-х, к инженерно-ориентированным позициям сегодня. Тайтлы так и не стандартизировали. Компании копируют-вставляют названия с джоб-бордов не задумываясь о смысле. HR видит "QA Automation Engineer" в вакансии конкурента и постит тот же тайтл даже если реальная работа на 90% ручная. Требования к навыкам автоматизации тоже резко сместились за короткое время, а словарь рынка за этим не успел.
В итоге: "QA Engineer", "Software QA Engineer", "QA Automation Engineer", "SDET" и "Software Development Engineer in Test" могут описывать что угодно: от ручного клика по веб-приложению до проектирования инфраструктуры тест-платформы для 200 инженеров.
Тайтл не помогает понять работу. Нужно читать требования. Об этом дальше.
Что значит "QA Engineer" сегодня
Исторически QA Engineer означал ручное тестирование. Исследовательское тестирование, написание тест-кейсов в таблицах или Jira, отслеживание багов, иногда координация sign-off перед релизом. Код не нужен.
Это определение в основном устарело, но тайтл живёт и сегодня может означать широкий спектр вещей. На практике когда компания постит "QA Engineer" в 2026, они обычно хотят человека у которого ручное тестирование основная работа, а автоматизация в стороне. "Немного автоматизации" может означать запуск чужих Playwright-тестов, написание нескольких скриптов в существующем фреймворке или поддержку Postman-коллекций для API smoke-тестов.
Представь сценарий: стартап на 40 человек шипит фичи каждые две недели. Они постят "QA Engineer". Что реально нужно: кто-то кто работает в связке с разработчиками и продукт-менеджерами, ловит проблемы до шипа фич, пишет тест-кейсы которые документируют ожидаемое поведение, и ведёт разговор о качестве на спринт-планировании. Если этот человек ещё и напишет несколько автоматизированных smoke-тестов, отлично. Но роль фундаментально про суждение о качестве продукта, а не про инженерный выхлоп.
Это QA Engineer sweet spot в большинстве компаний не из tech: кто-то кто глубоко понимает продукт, чётко коммуницирует дефекты, и достаточно знаком с автоматизацией чтобы не тормозить от неё.
Зарплатный диапазон для QA Engineer в традиционном смысле самый низкий из трёх тайтлов. Разрыв отражает разницу в технических требованиях, а не оценку ценности работы.
Что означает SDET и откуда это взялось
SDET расшифровывается как Software Development Engineer in Test. Microsoft создала этот тайтл в начале 2000-х с чётким определением: SDET пишет код продакшн-качества который тестирует ПО, и оценивается по тем же инженерным стандартам что и разработчики.
В Microsoft SDET были полноценными инженерами которые фокусировались на тестируемости и инфраструктуре качества, а не на фичах продукта. Они проектировали тест-фреймворки, писали инструменты которыми пользовалась вся QA-организация, ревьюили продакшн-код на тестируемость, и отвечали за целые подсистемы тест-платформы. Сеньор SDET мог шесть месяцев строить распределённую систему выполнения тестов которая сокращала время CI с двух часов до пятнадцати минут, при этом не написав ни одного продукт-теста самостоятельно.
Это инженерно-первое определение распространилось, но размылось. Сегодня "SDET" используется непоследовательно. В компаниях вроде Amazon, Google или Meta SDET по-прежнему значит то что имел в виду Microsoft: серьёзная инженерия применённая к качеству. Планка по кодингу близка к планке разработчика. В небольших компаниях "SDET" иногда просто означает "мы хотим больше инженерной строгости чем подразумевает тайтл QA Engineer".
Пример реальной SDET-работы: компания запускает 8000 end-to-end тестов и замечает что CI-пайплайн занимает 90 минут. SDET получает задачу это решить. Он анализирует распределение тестов, строит систему шардинга которая параллелизирует выполнение на 20 контейнерах, пишет infrastructure-as-code для их динамического провижнинга, добавляет observability-инструментарий чтобы флакающие тесты автоматически определялись и карантинизировались. В итоге CI занимает 12 минут. За квартал SDET написал примерно 500 строк продукт-тестов и 3000 строк кода фреймворка и инфраструктуры.
Это не QA-работа. Это инженерная работа которая делает QA-работу возможной.
SDET-роли в компаниях которые применяют тайтл строго платят значительно больше чем QA Engineer: обычно на 20–35% больше при аналогичном сениорити в зависимости от компании и региона. В крупных tech-компаниях SDETs часто находятся на той же компенсационной полосе что и разработчики.
Что означает QA Automation Engineer
Это средняя позиция и самый распространённый тайтл в 2026 году.
QA Automation Engineer пишет автоматизированные тесты и поддерживает фреймворк в котором они запускаются. Больше ориентирован на код чем традиционный QA Engineer (автоматизация не побочная задача, это основная работа), но не строит тест-инфраструктуру с нуля как настоящий SDET. Работает в рамках существующего фреймворка: расширяет его и пишет реальное покрытие тестами.
На практике: команда использует Playwright с TypeScript, есть структура Page Object Model, тесты запускаются в GitHub Actions. QA Automation Engineer приходит и тратит 70–80% времени на написание новых тестов для фич по мере их выхода, обновление существующих тестов когда меняется UI, расследование флакающих тестов и улучшение надёжности. Может добавить вспомогательную утилиту во фреймворк, улучшить репортинг ошибок или настроить новый тест-сьют для новой части продукта. Перепроектирование архитектуры фреймворка: территория SDET.
Конкретный сценарий: разработчик шипит новый checkout flow. QA Automation Engineer читает критерии приёмки, пишет шесть Playwright-тестов покрывающих happy path и ключевые edge case, запускает их локально против staging-среды, ловит два edge case которые не были обработаны, файлит баги, мёрджит тесты в main после фикса. Рутинная работа на два дня. Никакого проектирования фреймворка, никакой инфраструктурной работы. Просто чистое, хорошо структурированное автоматизированное покрытие реальной фичи.
Это и есть работа QA Automation Engineer. Требует реального умения кодить: писать чистый, читаемый тест-код на реальном языке, понимать async-паттерны, комфортно работать с системой контроля версий, отлаживать упавшие тесты без помощи разработчика. Бэкграунд в разработке не нужен.
Зарплата между QA Engineer и SDET. Компании нанимающие QA Automation Engineer обычно готовы платить заметно больше чем за традиционный QA потому что нужен кодинг-выхлоп, но они не проводят полный инженерный интервью-луп.
Как понять что реально хочет вакансия
Игнорируй тайтл полностью. Иди прямо в раздел требований и ищи три сигнала.
Сигнал 1: какой язык и фреймворк упоминают? Если говорят "опыт с Playwright, Selenium или Cypress": хотят тест-автоматизацию. Если указывают "сильные навыки программирования на Python или Java" и потом перечисляют работу по построению фреймворка или "тест-инфраструктуре": территория SDET. Если требования упоминают Jira, TestRail или "документацию тест-кейсов", а кодинг опциональный или вторичный: ручная QA-роль. Сигнал 2: что включает ежедневная работа? "Ты будешь писать автоматизированные тесты для новых фич": работа QA Automation Engineer. "Ты будешь проектировать и поддерживать фреймворк автоматизации": ближе к SDET. "Ты будешь координировать тестирование релизов и управлять жизненным циклом дефектов": традиционный QA Engineer. Сигнал 3: с кем будешь работать? Тесная работа с "продукт-менеджерами и разработчиками" сигнализирует о фокусе на качество продукта (QA Engineer). Работа с "командой платформы по улучшению надёжности CI" или "инфраструктурными инженерами" сигнализирует о работе SDET-типа.Реальный контраст. Вакансия А: "3+ лет опыта автоматизации, Playwright или Selenium обязательны, сильные навыки TypeScript, опыт написания E2E тест-сьютов". Это роль QA Automation Engineer вне зависимости от того что написано в тайтле.
Вакансия Б: "Требуются сильные навыки кодинга, опыт построения тест-фреймворков, знание распределённых систем будет плюсом, проектирование тест-инфраструктуры для поддержки сотен инженеров". Это SDET-роль даже если в тайтле написано "QA Engineer".
Читай и раздел "nice to have". Если там перечислены Docker, Kubernetes, администрирование CI-платформ или test observability как бонусы, компания думает в SDET-терминах даже если тайтл так не говорит.
Какой путь выбрать исходя из бэкграунда
Если приходишь из полностью нетехнического бэкграунда (поддержка, проектный менеджмент, бизнес-анализ) начинай с пути QA Engineer. Строй основы тестирования, освойся с Jira и отслеживанием дефектов, добавляй базовые навыки автоматизации со временем. QA Engineer: наиболее доступная точка входа. Компаниям важнее product thinking и коммуникация, а не кодинг-выхлоп.
Если есть какой-то кодинг-бэкграунд (буткемп по веб-разработке, скриптинг, IT-работа) иди сразу на QA Automation Engineer. Ментальная модель написания кода уже есть; нужны тест-специфичные знания поверх: как структурируются тест-сьюты, Playwright, интеграция CI. Для большинства career changer'ов это самый быстрый путь к хорошо оплачиваемой QA-роли.
Если есть бэкграунд в разработке, степень по CS или несколько лет опыта в разработке, правильная цель: SDET. Разрыв в зарплате существенный, а работа на техническом уровне реально интересная. Интервью-процесс сложнее, но существующие навыки переносятся напрямую.
Большинство карьерного роста для людей входящих как QA Engineer и хотящих двигаться вверх без пивота в чистую разработку происходит именно здесь: на уровне QA Automation Engineer. Добавление навыков автоматизации к основе QA Engineer: надёжный путь к более высокой компенсации и более интересной работе.
Что это означает для поиска работы
Перестань фильтровать по тайтлу. Фильтруй по требованиям. Составляя список заявок, быстро проверяй каждую вакансию по двум критериям: описанная реальная работа соответствует моему текущему уровню навыков, и ожидание по кодингу соответствует тому что могу реально продемонстрировать на интервью?
Если целишься на роли QA Automation Engineer, портфолио должно показывать тест-код. Не описания работы по автоматизации. Реальные тест-файлы на GitHub, чисто структурированные, с README объясняющим что делают тесты и как их запустить. Нанимающий менеджер хочет видеть тест-код которым разработчик был бы доволен: читаемый, поддерживаемый, продуманно организованный.
Если целишься на SDET-роли, нужно это плюс свидетельства инженерного суждения. Решения по проектированию фреймворка которые ты принимал и почему. Инфраструктурная работа. В идеале что-то что ты построил и чем пользовались другие. SDET-интервью зондирует глубже чем "можешь ли ты написать Playwright-тест", поэтому готовься обсуждать трейдоффы в дизайне.
Если целишься на роли QA Engineer, портфолио должно показывать quality thinking: хорошо написанные баг-репорты, тест-планы для нетривиальных фич, примеры важных edge case которые ты поймал. Автоматизация бонус, а не основной питч.
Рынок платит заметно больше за роли дальше по инженерному спектру. Это не аргумент что традиционный QA менее ценен: хорошее суждение о качестве продукта найти реально сложно. Это фактическое наблюдение о том что рынок сейчас оценивает. Знание в каком направлении строишься помогает правильно инвестировать время в обучение.
Три тайтла описывают три разные работы. Хаос возникает потому что никто не договорился какой тайтл соответствует какой работе. Теперь зная что искать в требованиях, хаос перестаёт быть проблемой.
→ See also: Карьера в QA: от джуниора до сеньора | Описание вакансии QA Automation Engineer: что компании на самом деле хотят | Как создать QA-портфолио на GitHub, которое приносит офферы (Playwright) | Manual QA vs Automation QA: кто зарабатывает больше в 2026 году?
