Если хотите глубже разобраться в теме, посмотрите также материал про вход в QA Automation с нуля и зарплаты на рынке и почему Playwright + TypeScript сейчас стал базовым стеком для роста в SDET.
Если вы сейчас работаете в ручном тестировании (Manual QA) и чувствуете, что упёрлись в потолок, вы не одиноки. В 2026 году рынок стал жёстче: компании всё реже готовы долго держать людей, которые умеют только кликать по интерфейсу и писать стандартные чек-листы.
Требования к квалификации выросли, ожидания по скорости релизов тоже, а зарплаты в ручном тестировании во многих командах почти перестали расти. Да, manual QA никуда полностью не исчезнет. Но если оставаться только в manual QA, расти становится всё сложнее.
Если вы хотите двигаться дальше, для выхода из Manual QA сейчас особенно логичны два направления: SDET и кибербезопасность веб-приложений и API.
Почему ручное тестирование постепенно сдаёт позиции
Давайте смотреть на рынок честно. Ручное тестирование не исчезает полностью, потому что человеческий взгляд всё ещё нужен: для оценки UX, сложной бизнес-логики и нестандартных сценариев на стыке систем. Но доля таких задач уже не выглядит так, как 5–7 лет назад.
- Скорость релизов. Компании хотят выкатывать изменения несколько раз в день. Руками невозможно быстро и качественно прогонять большой регресс на каждом изменении.
- Финансовый потолок. Как только вы научились уверенно писать тест-кейсы, заводить баги и поддерживать базовый regression pack, рост в доходе часто резко замедляется.
- Сдвиг требований в сторону техники. На рынке всё чаще нужны люди, которые умеют не только находить баг, но и встроить проверку в процесс: в код, API, CI/CD, безопасность.
- Давление со стороны автоматических инструментов. Простые рутинные проверки уже закрываются автотестами, контрактными проверками, health-check'ами и ИИ-инструментами, которые умеют быстро генерировать базовые сценарии.
Итог простой: manual QA без технического углубления всё чаще воспринимается как промежуточная роль, а не как конечная сильная специализация.
Что у Manual QA уже есть как сильная база
Самый ценный актив ручного тестировщика при переходе — это QA-мышление. Вы уже умеете искать слабые места в логике приложения, понимаете, где система ломается, и знаете, как устроен реальный процесс разработки.
Это очень сильная база, потому что:
- вы умеете задавать неудобные вопросы к продукту;
- у вас есть привычка мыслить негативными сценариями;
- вы понимаете жизненный цикл бага и ценность воспроизводимости;
- вы знаете, как говорить с разработкой, аналитикой и менеджментом.
Именно поэтому Manual QA обычно осваивает SDET или AppSec быстрее, чем человек без опыта в продуктовой среде.
Направление 1: SDET (Software Development Engineer in Test)
SDET — это уже не «просто автоматизатор». Это инженер, который строит инфраструктуру тестирования: проектирует фреймворки, пишет код, автоматизирует API и UI, интегрирует всё в CI/CD и думает о стабильности тестового контура как о полноценной инженерной системе.
Если обычный QA Automation часто ограничивается написанием тестов по готовым сценариям, то SDET работает глубже: он строит фундамент, на котором держится качество релизов.
Чем конкретно занимается SDET
- Разрабатывает фреймворки автоматизации на JavaScript/TypeScript, Python или Java.
- Пишет API-тесты для REST, GraphQL, gRPC и WebSocket, а не только гоняет UI.
- Интегрирует тесты в CI/CD через GitHub Actions, GitLab CI или Jenkins.
- Строит окружение: Docker, тестовые данные, фикстуры, отчёты, retry-стратегии.
- Работает со стабильностью: flaky tests, timeouts, race conditions, наблюдаемость и дебаг.
Актуальный стек SDET в 2026
- Язык: JavaScript / TypeScript или Python.
- UI и API automation: Playwright как основной современный инструмент; реже Cypress.
- Работа с API: Postman для исследования, кодовые запросы через fetch / axios / request-клиенты.
- Инфраструктура: Git, Docker, CI/CD.
- Плюс: базовая архитектура, паттерны, работа с логами и отчётами.
Плюсы перехода в SDET
- Высокий спрос на людей, которые умеют строить процессы, а не просто писать отдельные скрипты.
- Понятный трек роста для QA: вы не меняете полностью сферу, а углубляетесь в инженерную сторону качества.
- Сильные зарплаты: senior SDET во многих командах зарабатывает на уровне сильного backend/full-stack инженера.
Минусы
- Придётся реально учиться кодить: ООП, структура проекта, работа с асинхронностью, архитектурные решения.
- Если автоматизация построена плохо, много времени уходит на разбор нестабильных тестов и инфраструктурной боли.
- Работа подходит тем, кому нравится именно строить системы и приводить хаос к предсказуемости.
Если вам близко программирование, вы любите порядок и вам нравится видеть, как ваши инженерные решения ускоряют релизы, SDET — очень сильный и логичный путь. Подробно про этот вектор у меня есть отдельная страница QA Automation SDET.
Направление 2: кибербезопасность (Application Security / API Security)
Кибербезопасность — широкая область, но для человека из QA особенно понятен путь в Application Security и API Security. Здесь вы проверяете не только «работает ли функция», а «можно ли заставить её работать так, как разработчики не планировали».
Именно тут QA-мышление даёт сильный буст: вы уже умеете искать пограничные состояния, неконсистентность и дыры в логике. Просто теперь цена ошибки выше, а сценарии становятся более атакующими.
Чем занимается специалист по безопасности веба и API
- Ищет уязвимости в веб-приложениях и API в grey-box и black-box формате.
- Проверяет контроль доступа: BOLA / IDOR, Broken Function Level Authorization, privilege escalation.
- Ищет проблемы в бизнес-логике: обход оплаты, бесплатный доступ, подмена параметров, нарушение ограничений.
- Проверяет авторизацию и аутентификацию: JWT, OAuth, cookies, сессии, reset flow.
- Интегрирует security checks в процессы: сканеры, SAST/DAST, policy checks, CI gates.
Стек для старта в AppSec / API Security
- Инструменты анализа трафика: Burp Suite, OWASP ZAP.
- Сканеры и автоматизация: Nuclei, security linters, базовые кастомные скрипты.
- Протоколы: REST, GraphQL, SOAP, WebSocket.
- Методологии: OWASP Top 10 и OWASP API Security Top 10.
- Автоматизация: JavaScript или Python для повторяемых security-проверок, включая Playwright.
Плюсы перехода в кибербезопасность
- На рынке ощутимо меньше сильных специалистов, чем в классической автоматизации.
- Работа очень исследовательская: каждый продукт — это новый ребус, а не однотипный регресс.
- Высокий чек на B2B и консалтинг: внешние аудиты безопасности, API reviews, security сопровождение.
Минусы
- Порог входа выше по кругозору: сети, HTTP, архитектура, авторизация, типовые ошибки разработки.
- Нужна аккуратность и зрелость: ошибка в security-аудите может стоить бизнесу очень дорого.
- Подходит тем, кому действительно интересна исследовательская работа и анализ чужой логики.
Если вам скучно писать однотипные автотесты, а больше драйвит разбор логики, прав доступа, цепочек запросов и скрытых лазеек, то логичнее смотреть в сторону Application Security Engineer.
Сравнительная таблица: SDET против кибербезопасности
| Критерий | SDET | Кибербезопасность (API & AppSec) |
|---|---|---|
| Что нужно любить | Писать чистый код, строить системы, настраивать инфраструктуру | Разбираться в чужой логике, искать лазейки, ломать модель доверия |
| Сложность старта | Средняя: нужен один язык, Playwright/API и CI | Выше средней: нужен широкий кругозор по сетям, HTTP, auth и архитектуре |
| Главные инструменты | VS Code, Playwright, GitHub Actions / GitLab CI, Docker | Burp Suite, OWASP API Top 10, ZAP, Nuclei, скрипты автоматизации |
| Тип мышления | Мышление строителя: как сделать надёжно, быстро и автоматизированно | Мышление исследователя: как обойти правила и заставить систему выдать лишнее |
| B2B / консалтинг | Чаще штатная роль или долгие контракты на процессы автоматизации | Сильный потенциал для внешних аудитов и независимой экспертизы |
| Что проще использовать из опыта QA | API, regression thinking, баг-репорты, reproducibility | Negative mindset, анализ логики, доступов, злоупотреблений и edge cases |
Как перестроить своё резюме и стек уже сейчас
Переход не случится просто потому, что вы поменяли заголовок в LinkedIn. Нужна практическая перестройка профиля и артефактов.
Шаг 1: прокачайте API до реального рабочего уровня
И для SDET, и для кибербезопасности API — фундамент. Уже недостаточно просто отправлять запросы в Postman по готовой документации. Нужно понимать:
- чем отличается REST от GraphQL в архитектуре и в рисках;
- как работают headers, cookies, tokens, JWT и sessions;
- как перехватывать и модифицировать трафик на лету через proxy-инструменты;
- как проверять не только happy path, но и доступы, валидацию и границы типов.
Шаг 2: учите код, но привязывайте его к практике
Не учите язык «в вакууме». Привязывайте код к своим текущим задачам.
- Если хотите в SDET — автоматизируйте рутину: создание данных, API checks, smoke/regression через Playwright.
- Если хотите в безопасность — пишите простые скрипты для проверок прав доступа, чужих ID, некорректных типов данных и обходов в API.
Шаг 3: перестаньте мыслить только позитивными сценариями
Одна из главных причин, почему Manual QA застревает, — привычка проверять только то, что написано в ТЗ.
Для роста этого мало.
- Для SDET: думайте, что будет, если API ответит через 5 секунд, если данные не подготовились, если в пайплайне поменялась среда.
- Для AppSec: игнорируйте «красивый UI» и смотрите прямо в запросы. Что будет, если отправить отрицательное число? массив вместо строки? чужой ID? запрос без токена? запрос с токеном не того уровня?
Шаг 4: меняйте резюме не по названию, а по артефактам
В резюме должны появиться вещи, которые считываются рынком как переход в новую роль:
- репозиторий с автотестами или security-проверками;
- README с понятной архитектурой и инструкцией запуска;
- CI-пайплайн с артефактами;
- описание кейсов: API automation, negative scenarios, auth / access control / regression of security logic.
Главная идея: рынок верит не словам «я изучаю», а видимым инженерным артефактам.
Резюме: что выбрать именно вам
Выбирайте SDET, если вам нравится программирование, вы любите порядок, хотите видеть, как ваши автотесты и инженерные решения ускоряют поставку продукта, и планируете развиваться внутри продуктовых IT-команд.
Выбирайте кибербезопасность (AppSec / API Security), если вам скучно писать однотипные автотесты, у вас есть азарт исследователя, вам нравится ковырять чужую логику и вы хотите в будущем выйти на высокий чек, включая B2B-аудиты и независимую экспертизу.
Оба пути выводят вас из роли «просто ручного тестировщика» и переносят в более редкий, технический и высокооплачиваемый сегмент рынка. Вопрос только в том, что вам ближе по типу мышления: строить или исследовать.
Но в обоих случаях есть одно общее правило: начинать нужно не с бесконечного потребления теории, а с практики, которая уже сейчас меняет ваш стек и ваше резюме.
Как продолжение этой темы, рекомендую ещё как выглядит путь в Application Security с поддержкой ментора и вариант перехода в DevSecOps для тех, кому ближе CI/CD и инфраструктура.
Если хотите перейти из Manual QA в SDET или кибербезопасность не вслепую, а по внятному плану — приходите ко мне на обучение.
Я помогу понять, какой путь вам подходит, что именно добрать по стеку, как собрать сильные артефакты и как быстрее выйти в рынок с новой ролью.
