Вход в QA в 2026: не одна профессия — 6 треков, куда реально берут
Вступление
QA в 2026 году — это уже не одна профессия и не один очевидный путь. Формула «я иду в тестирование» больше не описывает реальность рынка. Ролей стало больше, требования — жёстче, а ожидания от QA заметно выросли. Именно поэтому у многих на старте возникает путаница: обещаний вокруг много, а понять, куда реально стоит двигаться, всё сложнее.
В этой статье я разберу, какие направления внутри QA действительно существуют сегодня и куда рынок реально нанимает. Без лозунгов и крайностей — просто посмотрим на то, как рынок устроен на практике и какие роли в нём востребованы.
Все выводы основаны на аналитике рынка QA за последний год: вакансиях, требованиях и зарплатах. Подробные разборы есть в отдельных материалах:
Здесь я соберу ключевые выводы и разложу QA по конкретным трекам — в порядке приоритета, от наиболее рациональных для старта до направлений с повышенными рисками и конкуренцией.
Дальше разберём каждый из них и посмотрим, что за ними стоит на самом деле.
1. QA Automation Engineer — рекомендую
Если вы только начинаете путь в QA и пытаетесь понять, куда рациональнее всего смотреть в 2026 году, то направление QA Automation Engineer — первое, на которое действительно стоит обратить внимание.
QA Automation Engineer — это инженер, который проверяет продукт не вручную, а с помощью кода. Он автоматизирует тестовые сценарии и встраивает их в процесс разработки так, чтобы ошибки находились быстрее, а регресс не съедал время команды. На практике автоматизация чаще всего делится на несколько направлений: UI-тесты, backend/API-тесты, mobile-тесты. В более редких и нишевых случаях это могут быть автотесты для CLI-утилит, внутренних сервисов или SDK — но суть роли от этого не меняется.
Почему именно AQA выглядит самым рациональным вариантом на старте?
Не потому, что это «проще» или «меньше нужно знать». Наоборот — требований здесь обычно больше. Но если смотреть на рынок трезво, спрос на QA Automation Engineer стабильно выше, вакансий больше, а средняя зарплата — заметно выше, чем у manual QA. В условиях, когда общее количество вакансий сокращается, это даёт простой статистический эффект: у автоматизаторов банально больше шансов выйти на рынок и получить оффер.
Важно понимать и ещё одну вещь. Компании всё реже ищут людей, которые просто «проверяют руками». Бизнесу нужно быстрее выпускать изменения, чаще деплоить и меньше ломать прод. Автоматизация — один из ключевых инструментов, который это позволяет. Именно поэтому рынок постепенно смещается в сторону AQA, а не потому, что кто-то решил «убить manual».
Технологии и стек: как это выглядит на практике
Если говорить про технологии, важно сразу снять ещё одну иллюзию. У QA Automation Engineer нет одного “правильного” инструмента. Есть стек, который складывается вокруг выбранного языка и типа тестирования, и именно его чаще всего ждут на рынке.
В 2026 году ядро автоматизации почти всегда строится вокруг одного из трёх языков: Python, Java или JavaScript / TypeScript. Дальше к языку постепенно добавляются инструменты — не “все подряд”, а ровно те, которые закрывают реальные задачи.
Примерно это выглядит так:
| Язык | UI-тесты | API / backend | Тестовый фреймворк | Вспомогательный стек |
|---|---|---|---|---|
| Python | Playwright / Selenium | requests / httpx | pytest | Git, Allure, CI/CD, SQL, Faker, Pydantic |
| Java | Playwright / Selenium | RestAssured | JUnit / TestNG | Git, Allure, CI/CD, SQL |
| JS / TS | Playwright / Cypress | supertest / Playwright | Jest / Mocha | Git, Allure, CI/CD, SQL |
Это не список «обязательных технологий» и не попытка охватить всё сразу. Это отражение того, что чаще всего реально встречается в вакансиях. Обычно от AQA ждут уверенной работы с одним языком и понимания, как вокруг него выстраивается автоматизация: UI, API, отчёты, интеграция в пайплайн.
Важно зафиксировать ключевую мысль. QA Automation Engineer ценят не за знание конкретных инструментов, а за умение собрать из них рабочую систему. Инструменты меняются, а принципы — нет. Если вы понимаете, как устроена автотестовая архитектура, вы спокойно адаптируетесь к новому стеку.
И здесь стоит сразу снять одну иллюзию. AQA — это не «писать автотесты вместо ручных тестов». Это работа с кодом, архитектурой тестов, стабильностью, инфраструктурой, логами и окружением. Автотесты нужно не только написать, но и поддерживать, анализировать их падения и понимать, где проблема в продукте, а где — в тесте. Именно за эту инженерную часть рынок и готов платить.
Я уже подробно разбирал, какие технологии и стек имеет смысл учить для QA Automation Engineer, в отдельной статье — «Как вырасти из Manual QA в Automation: пошаговый план». Здесь же важно зафиксировать главное: если смотреть на рынок в 2026 году без розовых очков, то AQA — это самый устойчивый и логичный трек для входа и дальнейшего роста.
Дальше логично посмотреть на роль, с которой сегодня связано больше всего путаницы и маркетинговых ожиданий, — Fullstack QA, и разобраться, что она на самом деле означает и почему к ней стоит приходить не сразу.
2. Fullstack QA — рекомендую, но осторожно
Fullstack QA — это не отдельная «новая профессия» и не магический гибрид, который внезапно делает вас вдвое ценнее на рынке. В реальности под этим названием чаще всего понимают QA-инженера, который умеет и автоматизировать тесты, и при необходимости тестировать руками, закрывая весь цикл проверки продукта.
Важно сразу зафиксировать: Fullstack QA — это не 50% manual и 50% automation в арифметическом смысле. На реальных проектах вес почти всегда смещён в сторону автоматизации. Ручное тестирование здесь выступает как дополнение: для исследовательских проверок, сложных сценариев, приёмки фич или работы с нестандартными кейсами. Базой же остаётся код.
И здесь возникает ключевой момент, который часто упускают. Автоматизатор может стать Fullstack QA довольно естественно. Если вы уже умеете писать автотесты, разбираться в системе и работать с инфраструктурой, ручное тестирование для вас — вопрос контекста и желания. Это навык, который достраивается поверх уже существующей инженерной базы.
А вот обратный путь работает гораздо хуже. Ручной QA, который не пишет автотесты, не становится Fullstack QA автоматически. Умение тестировать руками не превращается само по себе в умение строить автотестовую архитектуру, интегрировать её в CI/CD и поддерживать код. Именно поэтому иллюзия «я ручник, но немного automation — и я fullstack» чаще всего не совпадает с ожиданиями компаний.
На собеседованиях это видно особенно хорошо. Когда компания ищет Fullstack QA, она в первую очередь смотрит на автоматизацию: как вы пишете тесты, как думаете про стабильность, как работаете с падениями, логами и окружением. Ручные навыки важны, но они почти никогда не являются решающими.
При этом стоит понимать, почему эта роль вообще стала популярной. Во многих командах сегодня просто нет чёткого разделения на manual и automation. QA-инженер пишет автотесты, а при необходимости подключается к ручным проверкам — и это нормально. В таких условиях Fullstack QA — не отдельная карьерная цель, а скорее формат работы, к которому приходят по мере роста.
Есть и ещё одна причина, почему этот трек сейчас стабильно держится в числе наиболее востребованных. Рынок постепенно смещается в сторону универсальности. Компаниям всё реже нужны специалисты «под один инструмент» и всё чаще — инженеры, которые понимают систему целиком: могут написать автотесты, разобраться в логике приложения, провести ручную проверку сложного кейса и помочь команде быстрее выпустить фичу. Такой подход снижает издержки и делает команды устойчивее — и рынок это поощряет.
Поэтому Fullstack QA находится так высоко в приоритете. Спрос на таких специалистов уже есть и, по всей видимости, будет расти дальше. Но при этом это не роль, с которой имеет смысл начинать.
При этом к Fullstack QA стоит относиться осторожно. Это хорошее направление, но не как стартовая точка. Самый устойчивый путь к нему — через QA Automation Engineer, когда автоматизация уже стала базовым навыком, а ручное тестирование лишь расширяет ваш инструментарий.
Дальше имеет смысл поговорить о ролях, где автоматизация уходит ещё глубже в инженерную часть, — например, о SDET, и понять, почему туда обычно приходят уже с опытом, а не с нуля.
3. SDET — рекомендую, но только после опыта
SDET (Software Development Engineer in Test) — это роль, которая чаще всего вызывает больше всего вопросов и ожиданий. Формально это QA, но по факту — инженер-разработчик, который занимается не тестированием конкретных фич, а созданием и поддержкой тестовой инфраструктуры для всей команды.
SDET пишет код, но не продуктовый. Его зона ответственности — инструменты и системы, которые позволяют другим QA и AQA работать быстрее и стабильнее. Это могут быть мок-сервера, генераторы тестовых данных, внутренние утилиты, библиотеки для автотестов, собственные фреймворки, интеграции с CI/CD, инфраструктура для запуска и анализа тестов. Проще говоря, SDET отвечает за то, чтобы тестирование как процесс было инженерно выстроено.
Именно поэтому к этой роли почти никогда не приходят сразу. Junior-вакансий для SDET на рынке очень мало — и это не случайность. Чтобы разрабатывать полезные фреймворки и инструменты, нужно чётко понимать, какие проблемы они должны решать. А это понимание появляется только после реальной работы в тестировании.
Без опыта в роли QA Automation Engineer невозможно заранее угадать, где автотесты начинают болеть, что чаще всего ломается в пайплайне, какие абстракции действительно упрощают жизнь команде, а какие — только добавляют сложности. Именно этот контекст и отличает SDET от просто «разработчика, который пишет тесты».
С технической точки зрения требования здесь заметно выше. От SDET ждут уверенного владения языком, понимания архитектуры, принципов проектирования, работы с инфраструктурой и пайплайнами. Написать библиотеку или фреймворк — это не про «чтобы заработало», а про то, чтобы этим могли пользоваться другие, расширять, поддерживать и не бояться трогать код.
Поэтому самый устойчивый путь в SDET — это несколько лет в роли QA Automation Engineer, где вы сначала сталкиваетесь с реальными проблемами тестирования, а уже потом начинаете решать их на уровне инструментов и архитектуры. В таком случае переход в SDET выглядит естественно и органично, а не как резкий прыжок «на уровень выше».
Если убрать маркетинг, SDET — это не следующая ступень после курсов и не цель «как можно быстрее». Это роль для тех, кто уже разобрался в автоматизации и хочет уйти глубже в инженерную часть, влияя не на отдельные тесты, а на весь процесс качества в команде.
Дальше имеет смысл поговорить о более узких и специализированных ролях — например, о QA Performance Engineer, и понять, почему туда приходят ещё реже, но при этом рынок ценит такие навыки особенно высоко.
4. QA Performance Engineer — редко, но метко
QA Performance Engineer — это роль, которая встречается на рынке заметно реже, чем AQA или Fullstack QA, но почти всегда появляется не случайно. Это инженер, который отвечает не за корректность работы системы, а за то, как система ведёт себя под нагрузкой: когда пользователей много, запросы приходят одновременно, а цена ошибки становится высокой.
Зона ответственности здесь шире, чем просто «запустить нагрузочный тест». QA Performance Engineer проектирует сценарии нагрузки, выбирает профиль тестирования, подготавливает тестовое окружение, анализирует как клиентские, так и серверные метрики и помогает команде понять, где именно система упирается в пределы. Это может быть код, база данных, сеть, конфигурация инфраструктуры или архитектурные решения — и задача инженера по нагрузке в том, чтобы это обнаружить и объяснить.
Очень часто в эту роль входит работа с моками и тестовыми данными, настройка окружений, интеграция нагрузочных тестов в пайплайны и участие в прогнозировании нагрузки на продакшене. Также написание нагрузочных сценариев используя один из инструментов: Locust, K6, Gatling, JMeter, Artillery. По сути, QA Performance Engineer помогает ответить на вопросы, которые невозможно закрыть обычным функциональным тестированием: сколько пользователей выдержит система, что произойдёт в пике и где именно она начнёт ломаться.
Почему этот трек встречается реже? Потому что он нужен не всем. Компании приходят к нагрузочному тестированию тогда, когда у них уже есть заметный трафик, реальная аудитория и риск потери денег или пользователей из-за проблем с производительностью. Это, как правило, уже не стартап «вчера запустились», а продукт с масштабом и ответственностью.
При этом требования к QA Performance Engineer выше среднего. Здесь недостаточно знать один инструмент. Нужно понимать, как работает система в целом: HTTP, базы данных, очереди, инфраструктура, метрики, логи. Нужно уметь не просто запускать тест, а интерпретировать результаты и связывать цифры с реальными проблемами в продукте.
Зато рынок это ценит. Вакансий меньше, но специалисты по нагрузке обычно хорошо оплачиваются именно потому, что их работа напрямую влияет на стабильность бизнеса.
Важно отметить и ещё одну вещь. Навыки нагрузочного тестирования почти никогда не бывают лишними. Даже если вы не планируете становиться QA Performance Engineer, знания в нагрузке сильно усиливают профиль QA Automation Engineer или SDET. Понимание производительности помогает лучше проектировать автотесты, глубже разбираться в системе и выглядеть заметно сильнее на собеседованиях.
Поэтому нагрузка — это не обязательно отдельный карьерный трек, но почти всегда мощный буст. Для кого-то она становится основной специализацией, для кого-то — дополнительным инструментом, который открывает новые возможности на рынке. И в обоих случаях это знание, которое редко оказывается бесполезным.
Дальше имеет смысл поговорить о ролях, которые выглядят как «следующий шаг» для многих QA, — QA Lead и QA Manager, и разобраться, почему эти позиции часто понимают совсем не так, как они устроены на практике.
5. QA Lead / QA Manager — часто переоценивают
QA Lead и QA Manager — это роли, вокруг которых накопилось много ожиданий и не меньше недопонимания. Формально это позиции, отвечающие за качество на уровне команды или проекта: релизы, процессы тестирования, приоритеты, подходы к автоматизации и взаимодействие с другими ролями.
На практике же важно сразу разделить понятия. QA Lead — это, как правило, управленческая роль, а не следующая техническая ступень после senior QA. Её часто путают с QA Tech Lead, но это разные вещи. QA Tech Lead — про архитектуру, инструменты и технические решения. QA Lead — про людей, процессы и ответственность за результат.
И здесь возникает первый важный момент. Во многих командах роль QA Lead просто не формализована. Если вы единственный QA на проекте, пишете автотесты, следите за релизами и качеством — по факту вы уже выполняете функции QA Lead, просто без соответствующего тайтла и зарплаты. Никакой магии в этом нет: ответственность появляется раньше, чем должность.
Часто бывает и другой сценарий. Вы пришли на проект как junior или middle QA, со временем команда выросла, появились ещё несколько QA, и вы стали самым опытным человеком в контексте. В этот момент вы естественным образом начинаете координировать других, принимать решения и отвечать за качество. Формально вы всё ещё QA Engineer, но по факту — уже QA Lead. И далеко не всегда компания считает нужным выделять под это отдельную роль.
Из-за этого роль QA Lead часто переоценивают. Её воспринимают как обязательный карьерный рост или цель «по умолчанию», хотя на деле это смена фокуса, а не повышение уровня. Вместо работы с кодом появляется всё больше коммуникаций: митинги, синки, one-to-one, согласования, объяснения, защита решений. В крупных компаниях это может означать по 6–10 встреч в день и минимум времени на техническую работу.
И вот здесь важно быть честным с собой. Если вам нравится писать код, строить автотесты, разбираться в системах и инфраструктуре, роль QA Lead может оказаться не тем, чего вы ожидаете. Технические задачи никуда не исчезают, но они постепенно отходят на второй план, уступая место менеджерской нагрузке.
Есть и ещё одна особенность. В некоторых компаниях обязанности QA Lead описаны очень размыто. Вы вроде бы отвечаете «за всё качество», но при этом не всегда имеете реальные рычаги влияния: решения принимаются выше, приоритеты меняются, ресурсы ограничены. В итоге появляется много ответственности и мало контроля — и это один из самых сложных сценариев для этой роли.
Если убрать красивые формулировки, QA Lead / QA Manager — это не универсальная цель и не обязательный шаг для каждого QA. Это отдельный трек, который хорошо подходит тем, кому интересны процессы, координация и управление, но может не подойти тем, кто хочет оставаться в инженерной части профессии.
Дальше логично поговорить о роли, с которой всё ещё связано больше всего мифов и устаревших ожиданий, — Manual QA, и разобраться, почему в 2026 году она выглядит совсем иначе, чем несколько лет назад.
6. Manual QA — не рекомендую
Про Manual QA до сих пор существует устойчивая иллюзия: что это простой и надёжный способ войти в IT. Эта идея родом из 2020–2021 годов, когда рынок был перегрет, компаний было много, а требования к входным позициям — минимальными. Тогда ручное тестирование действительно часто становилось первым шагом в индустрию.
Но рынок с тех пор сильно изменился.
Сегодня спрос на Manual QA заметно ниже, чем несколько лет назад, а конкуренция — наоборот, выше. При этом сама роль почти не стала проще. Компании ждут от ручных тестировщиков понимания системы, процессов, документации, взаимодействия с командой — но при этом вакансий становится меньше, особенно на уровне junior.
Почему же миф о «лёгком входе» до сих пор живёт? Потому что он удобен. Его выгодно поддерживать тем, кто продаёт быстрые и простые решения: курсы «с нуля», обещания быстрого трудоустройства, истории про вход за пару месяцев. В реальности же рынок давно ушёл вперёд, а эта картинка осталась в прошлом.
Я дополнительно видел это и на практике. По моей собственной статистике, около 70% студентов, которые приходят изучать автоматизацию, — это действующие Manual QA. И приходят они не из любопытства, а потому что рынок вынуждает. В среднем это специалисты с 3–5 годами опыта, уровнем middle или middle+, которым всё сложнее находить новые проекты или менять работу, оставаясь в ручном тестировании.
Если даже для опытных ручных QA ситуация выглядит напряжённо, то для junior она ещё сложнее. На одну вакансию начального уровня сегодня может приходиться полторы–две тысячи откликов и больше. В таких условиях речь уже идёт не о «проще войти», а о лотерее с крайне низкими шансами.
Важно подчеркнуть: дело не в том, что ручное тестирование «плохое» или «ненужное». Оно никуда не исчезло и по-прежнему используется. Проблема в другом — как стартовая точка в 2026 году Manual QA почти не даёт устойчивости. Рост упирается в потолок довольно быстро, а дальнейшее развитие всё равно ведёт к автоматизации или смене трека.
Именно поэтому, выбирая роль Manual QA как единственный путь входа в профессию сегодня, вы фактически выбираете тупиковую ветвь. Не потому что «нельзя», а потому что рынок предлагает слишком мало возможностей и слишком много конкуренции.
О том, как формируются эти иллюзии входа и почему они так хорошо продаются, я подробно писал в статье «Как продают иллюзию входа в QA в 2026 году». Здесь же достаточно зафиксировать простой вывод: если вы только начинаете и смотрите на рынок трезво, ручное тестирование — самый рискованный вариант старта из всех рассмотренных.
Заключение
QA в 2026 году — это не одна профессия и не один «правильный» путь. Рынок давно перестал быть плоским: внутри тестирования есть разные треки с разным уровнем спроса, входа и устойчивости. И именно понимание этой структуры сегодня даёт больше преимуществ, чем любой универсальный курс или громкое обещание.
Важно помнить и ещё одну вещь. Помимо рассмотренных направлений, существуют и другие роли — вроде pentest, QA Architect, QA Staff и похожих. Это реальные и интересные специализации, но они нишевые: встречаются не в каждой компании, требуют серьёзного бэкграунда и редко подходят как стартовая точка. Поэтому в рамках этой статьи я сознательно не рассматривал их как массовые направления входа в профессию.
Главная идея здесь простая. В 2026 году выигрывают не те, кто ищет самый быстрый вход, а те, кто сначала понимает рынок и только потом строит под него свой путь. Когда вы отталкиваетесь от реального спроса, требования перестают быть неожиданностью, а решения — импульсивными.
Эта логика не делает путь лёгким. Но делает его осознанным.