Роадмап в QA в 2026: что нужно знать, чтобы получить оффер

Пять лет назад в тестирование заходили через ручное: кликаешь по чек-листу, смотришь результат, рынок прощает тебе отсутствие навыков. Сейчас на том же месте в вакансиях стоят Kafka, Kubernetes и автотесты на Java.

Ручное тестирование как вход больше не работает

В 2021-м стратегия «вкатиться через мануальное тестирование» ещё работала. Рынок принимал новичков: знаешь, что такое чек-лист и тест-кейс — уже кандидат. Можно было прийти без кода, без понимания API, без SQL и получить оффер на функциональное тестирование, дальше доучиваясь по ходу.

Дальше рынок начал двигаться, и двигался он быстрее, чем кажется внутри компании. В 2022-м в вакансиях QA появились приписки: «желательно знание автоматизации», «опыт с API», «базовый SQL». Слово «желательно» сбивает с толку — звучит как бонус, а на деле это знак, куда поедут требования через пару лет. И они поехали: то, что в 2022-м было «желательно», к 2024-му стало обязательным условием.

К 2024 году ситуация выглядит уже так: смотришь вакансии и ни в одной не встречаешь формулировку «требуется ручной тестировщик». Вместо неё везде QA Engineer со знанием автоматизации, опыт в финтехе, CI/CD, Docker, Kubernetes, углублённое понимание API. К концу 2025-го добавляется ещё и опыт работы с ИИ и LLM.

Вакансии чисто ручного тестирования из дикой природы не исчезли совсем, но их осталось мало, и условия там соответствующие: либо платят немного, либо требуют коммерческий бэкграунд за плечами. Параллельно реклама курсов «вкатись в IT за три месяца» нагнала на рынок толпу таких же новичков, и у компаний появилась роскошь выбирать.

Вывод для тех, кто планирует вход в 2026-м: начинать с чек-листов смысла мало, потому что это тупиковая ветка, с которой потом всё равно придётся переучиваться. Логичнее сразу собирать ту базу, которая позволит работать с первого дня и не упираться в потолок. Что в эту базу входит, дальше по разделам.

Научиться понимать архитектуру

Проектировать системы вам не придётся, это работа архитектора. Задача тестировщика — представлять, как устроено то, что он тестирует, чтобы видеть всю цепочку, а не отдельную кнопку.

На практике это четыре вещи:

1. Как сервисы общаются между собой: синхронно через HTTP, когда один ждёт ответа другого, или асинхронно через очередь сообщений, когда событие кладётся в брокер и подбирается, когда получатель готов.
2. Где хранятся данные и как к ним обращаются разные компоненты.
3. Что произойдёт, если один из сервисов упадёт, и кто из соседних это заметит.
4. Как запрос трансформируется на каждом шаге пути от клиента до ответа.

Зачем это тестировщику. Пока вы тестируете поверхностно — нажал, посмотрел результат, — вы можете зафиксировать, что баг есть, но не объясните почему. На вопрос «где сломалось» ответа нет, потому что система для вас непонятная. Как только появляется понимание потоков данных, сразу становится лучше. Вместо «кнопка не работает» вы говорите: запрос пришёл в Gateway, прошёл в Core-сервис, событие легло в Kafka, консьюмер его прочитал, но в базе нужной записи нет — значит, ищем разрыв на участке между консьюмером и базой. Это уже баг, с которым можно идти к разработчику.

Лучший способ это уложить в голову — поднять микросервисное приложение локально и посмотреть, как сервисы взаимодействуют. Перед практикой имеет смысл прочитать «Designing Data-Intensive Applications» Мартина Клеппмана (на русском вышла как «Высоконагруженные приложения»). Кода там нет, зато подробно разобрано, как системы устроены изнутри, — для QA это полезнее, чем уметь самому писать сервисы.

Дальше берём готовые демо-проекты с низким порогом входа. Они поднимаются одной командой через Docker Compose, так что копаться в коде не нужно, нужно исследовать: отправить запрос через Postman, проследить по логам, как он прошёл по цепочке, намеренно остановить один контейнер и посмотреть, что станет с остальными. Два репозитория подходящего формата:

• Microservice Kafka Sample — три сервиса (заказы, доставка, выставление счёта), между ними Kafka, у каждого своя база PostgreSQL, поднимается через docker-compose up. Создаёте заказ в одном сервисе, через какое-то время накладная и статус доставки появляются в других. Удобно трассировать запрос и искать, где он застрял.
• Microservices with Spring Boot and Kafka Demo Project — посложнее: заказы, платежи, склад, распределённые транзакции по паттерну SAGA, поддержка Docker Compose и Testcontainers. Хорошо показывает, что происходит с транзакцией, когда она идёт через несколько сервисов и один из них падает.

Если хочется теории вместе с практикой, на Stepik есть курс «Microservices — паттерны и практика построения микросервисов»: русскоязычный, разбирает паттерны взаимодействия, асинхронные системы, RabbitMQ. Он заточен под понимание концепций, а не под написание продакшн-кода, — то, что нужно.

Три технологии, которые спрашивают всегда

1. HTTP и REST API. REST — это договорённость между клиентом и сервером о том, как они общаются. Клиент просит: дай данные о пользователе с ID 42. Сервер отвечает JSON-ом и кодом: 200 — всё нашлось, 404 — такого пользователя нет, 403 — прав не хватает. Тестировщик, который умеет вызывать API через Postman, curl или код, проверяет логику системы мимо интерфейса — раньше и точнее, чем через клики по экрану. Базовый минимум: методы (GET, POST, PUT, DELETE), коды ответов (2xx, 4xx, 5xx), заголовки, структура JSON, аутентификация.
2. Базы данных и SQL. Почти каждый дефект оставляет след в базе: либо лежит некорректная запись, либо записи нет вообще. Написать SELECT с джойнами, проверить результат агрегации, отловить дубли — ежедневная работа QA-инженера. На собесе это спрашивают как данность, а не как редкий бонус.
3. Брокеры сообщений и Kafka. Kafka даёт сервисам общаться асинхронно: один кладёт событие в топик, другой забирает его, и никто не висит в ожидании. В распределённых системах это стандарт. Если данные не появились там, где их ждали, возможно, они застряли в очереди, а не пропали из базы. Это две разных ситуации, и путать их дорого для бизнеса.

Важное предупреждение, чтобы не отпугнуть: писать эти сервисы самому QA не нужно. Цель — понять, что происходит внутри, когда данные идут от одного сервиса к другому. Поднял проект, посмотрел Postman, почитал логи, остановил контейнер, посмотрел на последствия — этого достаточно, чтобы общаться с командой разработки.

Научиться читать логи

Когда сервис падает в продакшене, времени воспроизводить баг руками нет, и единственное, что у вас есть, — это логи. Особенно это нужно на критичной инфраструктуре вроде государственных контрактов, где инциденты идут потоком, а каждая минута простоя стоит денег.

Выглядит типичная диагностика так:

• Прилетает алерт: сервис X начал возвращать 500-е ошибки.
• Открываете Kibana, фильтруете по временному интервалу и имени сервиса, чтобы отсечь лишний шум.
• Находите трейс конкретного запроса — от входящего HTTP-вызова до ответа базы данных.
• В трейсе видите stacktrace с исключением в определённом классе и конкретным сообщением.
• Дальше тянете за эту нитку до корневой причины: например, оказывается, что упал не сам сервис, а внешний, к которому он обращался, и причина — таймаут.

Помимо Kibana для разбора логов в работе пригодится связка Grafana и Prometheus для мониторинга метрик. Логи отвечают на вопрос «что именно сломалось в этом запросе», метрики показывают картину шире: когда началась деградация, какой сервис первым ушёл в красное, как менялась нагрузка перед инцидентом. Вместе они дают и точку отказа, и контекст вокруг неё.

Этот навык как раз отличает среднего тестировщика от хорошего. Средний по факту падения скажет «не работает» и пойдёт заводить тикет. Хороший откроет логи, пройдёт по трейсу и принесёт разработчику не жалобу, а готовую гипотезу о том, где и почему сломалось. Вторые на рынке зарабатывают больше, и тренируется это ровно на тех же демо-проектах: подняли, сломали контейнер, полезли в логи смотреть, что система об этом написала.

Зачем QA язык программирования

Помимо скорости код даёт понимание работы команды разработки. Когда QA пишет автотесты на том же языке, на котором разработчики пишут продукт, стирается граница между «вашим» и «нашим» кодом. Проблему можно обсудить на уровне реализации, быстро получить консультацию, а иногда разработчик и сам запускает ваши тесты, чтобы проверить свою фичу, или вносит правку в тестовый код, когда видит, в чём причина нестабильности.

Конкретно код у QA уходит на несколько вещей:

• Автотесты — заменяют ручной прогон регресса, гоняются хоть каждую ночь.
• Тестирование API — написать авторизацию, отправить запрос, проверить JSON-схему ответа.
• Генерация тестовых данных — создать тысячи записей с разными параметрами под нагрузочные и граничные сценарии.
• Верификация в базе — SQL-запросы, которые проверяют, что в данных лежит именно то, что должно.
• Shift-left — писать тесты параллельно с разработкой, ещё на этапе требований, чтобы дефекты ловились раньше.

С чего начинать. Java или Python — хорошие первые языки, оба распространены в автоматизации и под оба полно вакансий. Но учить язык лучше в контексте задач тестирования, а не абстрактно по учебнику: сразу написать первый UI-тест через Selenium, сделать HTTP-запрос через RestAssured или requests, дёрнуть SQL-запросом реальную базу.

Инженерное мышление вместо «кнопка не работает»

Все навыки из предыдущих разделов держатся на одной привычке думать определённым образом. На заводе фраза «деталь бракованная» не закрывает вопрос: нужно найти причину в процессе, измерить отклонение, воспроизвести и устранить. Та же логика переносится на программные системы, и именно она отличает инженера от человека, который кликает по экрану и пишет «не работает».

Складывается это мышление из нескольких рабочих привычек:

1. Спрашивать «почему», а не только «что». Не «кнопка не нажимается», а «почему запрос возвращает 403 именно для этой роли».
2. Держать в голове систему целиком: как правка в одном сервисе аукнется в соседних через Kafka-события, общую базу или контракты API. 
3. Заранее прикидывать риски: что сломается первым под нагрузкой, какие граничные случаи опаснее остальных. Сюда же относится участие в проектировании: дефект, пойманный на этапе требований, обходится примерно в десять раз дешевле, чем тот же дефект, найденный в продакшене. 
4. Оперировать цифрами: время прогона регресса, покрытие тестами, количество инцидентов. 

Хорошая новость для тех, кто приходит в тестирование из технической специальности. Физики, химики, инженеры с производства уже умеют работать с причинно-следственными связями и видеть систему как набор связанных процессов. Этот навык никуда не девается при смене сферы, его остаётся переложить на специфику софта: вместо станков и допусков — сервисы, запросы и базы данных. База, за которую в IT доплачивают, у вас по факту уже есть.

Итого

Если собрать роадмап в один список, маршрут получается такой:

• Разбираться в архитектуре и поднимать демо-микросервисы локально; 
• Знать HTTP с REST, SQL и брокеры вроде Kafka; 
• Уметь читать логи, потому что в проде это ваш основной инструмент; 
• Освоить язык под автоматизацию; 
• И приучать себя думать потоками данных, а не кнопками.

Архитектура объясняет, зачем нужны API, базы и брокеры. Понимание этих технологий делает осмысленным чтение логов. Логи и автоматизация вместе подводят к коду.

И ещё одно наблюдение, ради которого статья была написана. Рынок QA за пять лет переписал требования дважды и продолжит переписывать. Гнаться за конкретной строчкой в вакансии бессмысленно — она устареет к следующему собесу. Работает другая установка: целиться не в «войти в IT через тестирование», а в «стать инженером, который умеет тестировать». Первое даёт оффер на год, второе — профессию, которая переживёт любую следующую волну требований.