🔧 Пять практических советов для тех, кто думает о переходе в QA в 2026 году

В 2019 году я получил диплом металлурга и был уверен, что впереди стабильная инженерная карьера. В феврале 2021-го сидел на первом собеседовании в IT на позицию мануального тестировщика. В 2026 году я работаю Fullstack QA Engineer в Альфа-Банке: тестирую аналитическую HTAP-систему, пишу автотесты на Java, разбираю Kafka-потоки и трассирую запросы через микросервисную архитектуру. Путь был непростым и тернистым. Но если бы в 2026 я пытался перейти из инженера в QA, то поступил бы иначе: например, сразу бы перескочил через ручное тестирование. Заходите в статью — я расскажу, что нужно рынку QA в 2026 году, и поделюсь практическими советами для тех, кто думает о переходе в QA сегодня.

Краткая предыстория: как я вкатился в QA после завода с дипломом металлурга

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

Не считая того, что поиск работы после университета заканчивается тем, что тебе нужен опыт работы, чтобы получить работу, тяжело удержать желание задерживаться на работе, которую ты каким-то чудом смог получить:

1. На первом заводе я получил бесценный опыт, но там не было отопления и приходилось работать в верхней одежде. А шестимесячная стажировка без перевода в штат окончательно выбила меня из колеи. Ради этого я столько учился?
2. На втором заводе (шарикоподшипников) было чище, теплее и мне сразу дали должность «инженер-технолог первой категории». Но я попал в бюрократическое лимбо — выявлял брак подшипников и для оформления партии на доработку требовалось несколько подписей начальников, которые приходилось тащить клещами.
3. Третий завод казался самым перспективным: зарплата 27 000 рублей, стабильность, возможности роста. Но после разговоров с ведущими инженерами быстро стало ясно, что всё это иллюзия — при стаже 5-15 лет доход более опытных коллег выше моего всего на 15-20 тысяч рублей, а без поддержки «мохнатых рук» карьерный рост не светит. В то же время токарь и рабочие получали больше меня в 3 раза. И для чего нужно было столько лет учиться? Выгорание и разочарование постучались в дверь мгновенно.

Где-то в процессе получения рабочего опыта я впервые услышал про тестирование. Тема меня так зацепила, что я начал изучать требования к QA-специалистам параллельно с основной работой и грезил о том, чтобы однажды устроиться тестировщиком в хорошую компанию. А после осознания того, что профессиональный рост нереален, достал свои конспекты по требованиям QA и начал учиться дальше.

Если узнали себя, то следующая часть статьи будет для вас. Я собрал шесть (действительно) рабочих советов для тех, кто планирует перейти в айти через QA в 2026 или около того.

Совет №0. Не заходите в профессию через «ручное тестирование»

Мой первый оффер был именно «ручным» и назывался «Специалист по федеральному тестированию в МегаФоне». Функциональное, регрессионное и интеграционное тестирование телекоммуникационных систем, тарифы, роуминг, USSD, SMS и всё такое. Никакого кода, никакой автоматизации, только хардкор.

Скажу честно — я испугался оффера. Но не потому, что не знал инструментов — изучить их не сложно — а потому, что на заводе я был «инженером», человеком с понятной идентичностью, и хотя бы что-то понимал и знал. В IT же я становился новичком.

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

Но решение оказалось правильным. Я прошел школу дисциплины, научившись всему с нуля: составлять чек-листы, тест-кейсы, работать с требованиями.

Однако…

В 2021 году вход через ручное тестирование ещё работал и был самой короткой дорогой из желтого кирпича в мир IT — рынок принимал новичков с любовью, заботой и снисхождением к отсутствующим навыкам.

Сейчас если и существуют в дикой природе вакансии ручных тестировщиков (а их нет), то там либо платят копейки, либо нужно иметь коммерческий бэкграунд за спиной. К тому же желающих стало больше (невероятно много) благодаря рекламе курсов «Тестирования и вката в IT», а у компаний появилась возможность выбирать лучших из лучших.

Например, уже в 2024 году, когда я (снова) вышел на рынок в поисках более подходящей команды, и просматривал десятки вакансий, то ни разу (!) не видел, чтобы где-то было написано «требуется ручной тестировщик». Всем были нужны:

1. QA Engineer со знанием автоматизации.
2. Опыт в финтехе, знание CI/CD, Docker, Kubernetes.
3. Углубленное понимание API и т.д.

Большинство компаний уже хотели себе не просто «ручного тестировщика», а требования стали жестче и самих требований стало больше.

Что делать сегодня?

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

Совет №1. Учите архитектуру

После МегаФон я перешёл в Эвотор — продуктовую компанию с e-commerce платформой «Магазин приложений». Впервые я поработал с REST API через Postman и Swagger, PostgreSQL, DevTools, кроссбраузерное тестирование, разбор логов в Kibana. Никаких USSD и тарифных планов — только веб-приложение с базой данных и API.

Слово «архитектура» я тогда понимал смутно. Знал, что есть «бэкенд» и «фронтенд», но слабо представлял разницу между ними. Первые месяцы тестировал «поверхностно»: нажал кнопку, посмотрел результат. Когда что-то шло не так, я мог сказать «баг есть», но не мог объяснить почему.

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

Первые автотесты на Java, с использованием Selenide для UI и RestAssured для API написал именно здесь. Первые тесты были ужасны: медленные, нестабильные, падали «без причины». Хотя, на самом деле, причина была одна — не считая того, что плохо знал Java Core, не понимал архитектуру того, что тестировал: копировал примеры, не понимая, как части системы связаны между собой.

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

Пока я работал в Эвоторе, рынок незаметно менялся. В 2022 году компании начали массово сокращать команды, пересматривать состав ролей, сокращать вакансии «мануал тестировщиков» и добавлять в требованиях к QA-инженерам строки «Желательно знание автоматизации», «Опыт с API», «Базовый и средний SQL».

«Желательно» в 2022-м — это «обязательно» в 2024-м. Рынок давал сигнал заранее, просто его было легко не заметить, когда находишься, так сказать, внутри компании (или индустрии).

Тот, кто за два года в продуктовой компании освоил автоматизацию и понял архитектуру, в 2023 году выходил на рынок с совсем другим предложением, чем тот, кто два года кликал по чек-листам.

Что значит «понимать архитектуру»?

Проектировать системы не нужно, это работа архитектора, но нужно понимать:

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

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

Следующий шаг — готовые демо-проекты на GitHub.

Здесь самый низкий порог вхождения — проекты, которые поднимаются одной командой через Docker Compose. Вам не нужно понимать код, нужно увидеть, как сервисы взаимодействуют. О том как работает Docker и для чего он нужен есть отдельные статьи и даже целые курсы, вот некоторые полезные статьи:

1. Изучаем Docker, часть 1: основы.
2. Путеводитель по Docker. От основ контейнеризации до создания собственного Докера.
3. Docker для начинающих: простое развертывание приложения за несколько шагов.

Два конкретных репозитория, которые я бы рекомендовал:

1. github.com/ewolff/microservice-kafka — минималистичный пример: три сервиса (заказы, доставка, выставление счёта), Kafka между ними, PostgreSQL, поднимается через docker-compose up. Создаёте заказ в одном приложении и через некоторое время накладная, статус доставки появляются в других. Kafka используется для общения между сервисами, Postgres, у каждого сервиса своя база. Это именно та схема, которую QA встречает в реальных проектах. Смотрите логи, трассируйте запрос, находите где «застряло».
2. github.com/piomin/sample-spring-kafka-microservices — чуть сложнее: три сервиса (заказы, платежи, склад), распределённые транзакции через паттерн SAGA, поддержка Docker Compose и Testcontainers. Хорошо показывает, что бывает, когда транзакция проходит через несколько сервисов и один из них «падает».

Что делать с этими проектами? Естественно, запустить, а потом поисследовать: отправить запрос через Postman, посмотреть в логах как он прошёл по цепочке сервисов, намеренно «сломать» один из них (остановить контейнер) и посмотреть что происходит с остальными.

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

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

Совет №2. Изучайте HTTP, базы данных, брокеры сообщений

Первая по-настоящему сложная инфраструктура мне попалась в СберТех, куда я попал на проект backend-сервиса шардирования для высоконагруженных систем. Стек: REST API через Insomnia, асинхронные взаимодействия через Kafka, верификация данных через SQL в PostgreSQL, деплой на Kubernetes и OpenShift, автотесты на Java с RestAssured, запуск через Jenkins.

Фичи «нажать кнопку и посмотреть, как работает переход по кнопке» уже не было, а тестовую документацию я строил с нуля: тест-планы, чек-листы, детальные тест-кейсы в Zephyr Jira.

Работы было много, но был и плюс — я начал мыслить не тест-кейсами, а потоками данных. Раньше я мог задать вопрос «Почему кнопка не работает?», а теперь думаю: «Запрос пришёл в Gateway, прошёл в Core-сервис, событие легло в Kafka, Consumer прочитал, но в базе нужной записи нет. Где в этой цепочке произошёл сбой?» Без понимания HTTP, SQL и работы брокеров сообщений этот вопрос просто не придёт на ум.

Когда проект в СберТехе закончился и я долго мониторил рынок, картина была уже другой по сравнению с 2021-м. Слова «желательно» в вакансиях исчезли. Никто уже не желал, все требовали — появились конкретные требования: знать CI/CD, опыт с Kubernetes, понимание Kafka, умение работать с распределенными системами.

Скидок на «готов учиться» я уже не видел. Все спрашивали «Что ты умеешь прямо сейчас? Конкретный стек, конкретные задачи, конкретный опыт».

К середине 2024 года QA без понимания асинхронных систем и без опыта работы с базами данных выглядел на рынке так же, как QA без знания Jira выглядел в 2019-м — неполноценно.

Три технологии, без которых сегодня нет QA

№1. HTTP и REST API. REST API — это «договор» между клиентом и сервером о том, как они общаются. Клиент отправляет запрос: «Дай мне данные о пользователе с ID 42». Сервер отвечает: JSON с данными и код 200 – всё хорошо, или 404 – такого пользователя нет, или 403 – у вас нет прав.

QA-инженер, который умеет тестировать API через Postman, curl или код, проверяет логику системы независимо от интерфейса. Быстрее, надёжнее, на более раннем этапе. Базовый минимум знаний: HTTP-методы (GET/POST/PUT/DELETE), коды ответов (2xx, 4xx, 5xx), заголовки, структура JSON, аутентификация.

№2. Базы данных и SQL. Практически каждый дефект оставляет след в базе данных: либо есть некорректная запись, либо записи нет вообще. Способность написать SELECT с JOIN-ами, проверить результат агрегации, найти дублирующиеся записи — это ежедневная работа QA-инженера, а не экзотика.

№3. Брокеры сообщений: Kafka и асинхронность. Kafka позволяет сервисам «общаться» асинхронно: один сервис кладёт событие в топик, другой подбирает его, когда готов. Никто не ждёт друг друга в режиме реального времени. В современных распределённых системах это стандартный паттерн. Если данные не появились там, где ожидались — возможно, они застряли в очереди, а не «потерялись» в базе. Это принципиально разные диагнозы.

Совет №3. Учитесь читать логи

В ГНИВЦ я работал на критически важном государственном контракте — сайт ЕРН для ФНС, обмен данными между госструктурами. Высокая регуляторная значимость, постоянные инциденты с продакшена, высокий темп.

Именно здесь я понял, что способность читать логи не «полезный навык в резюме», а основной инструмент диагностики в боевых условиях. Когда что-то падает в продакшене и нет времени воспроизводить баг вручную, есть только логи. Мы работали с Kibana для анализа логов и Grafana + Prometheus для мониторинга метрик и, для примера, типичный процесс диагностики выглядел так:

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

Здесь же я освоил Kotlin для написания автотестов и «смежный» стек: Kotest, JUnit5, Spring Test, Shift-left подход.

Когда в конце 2025 года я вышел на поиск новой команды, картина отличалась от 2024-го ещё сильнее. В объявлениях мелькали:

1. «Fullstack QA от 2-х лет».
2. «AQA от 2-х лет».
3. «QA Engineer со знанием автоматизации».
4. «Опыт в финтехе, знание CI/CD, Docker, Kubernetes».
5. «Опыт работы с ИИ/LLM/Агентами».

Несколько раз я доходил до финальных этапов, но компании выбирали кандидатов с более узкой и глубокой специализацией. Оффер от Альфа-Банка я получил спустя полгода усердных поисков и прохождений интервью, потому что к тому моменту за плечами был полный набор: автоматизация, распределённые системы, опыт с Kafka, несколько доменов.

В 2025 компании не ищут «хорошего тестировщика». Они ищут инженера, который умеет работать с распределёнными системами и может автоматизировать критичные сценарии, рутинные задачи. А навык работы с ИИ для решения вопросов в своих задачах для тестирования и автоматизации стал играть немаловажную роль при поиске кандидатов.

Совет №4. Осваивайте язык программирования

Шаг за шагом наполнялся мой стек инструментов и языков программирования для автотестов:

1. Java, Selenide, RestAssured, JUnit, Jenkins в Эвотор.
2. RestAssured, IntelliJ IDEA, Bitbucket, Jenkins, Kubernetes в СберТех.
3. В ГНИВЦ добавил Kotlin: Kotest, JUnit5, Spring Test, BDD подход (синтаксис стал лаконичнее, тестовые сценарии читались чище).
4. В Альфа-Банке стек автоматизации стал полноценным: Selenium, Selenide, RestAssured, Retrofit, JUnit5, Cucumber, Allure. UI, API, база данных и Kafka в одном проекте (часть фреймворка строится с нуля) + код ревью автотестов команды.

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

1. Писать автотесты. Ручной регресс из 500 тест-кейсов нереалистичен при еженедельных релизах. И это не предел, есть проекты где регресс порядка 5000 тестов.
2. Единый технологический стек для команды. Если QA пишет автотесты на том же языке, что и разработчик весь продукт, то QA и разработчики говорят на одном языке: можно обсудить проблему на уровне кода, быстро получить консультацию, а иногда разработчики сами запускают тесты для проверки фичи, вносят точечные правки в тестовый код, помогают диагностировать причины нестабильности.
3. Тестирование API — написать авторизацию, отправить запрос, проверить JSON-схему ответа.
4. Генерация тестовых данных — создать тысячи записей с разными параметрами
5. Верификация данных в базе – SQL-запросы для проверки корректности записей
6. Shift-left testing – писать тесты параллельно с разработкой, на этапе требований

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

Совет №5. Развивайте инженерное мышление

Сейчас я работаю ведущим специалистом по тестированию в дирекции разработки технологических продуктов на базе искусственного интеллекта в Альфа-Банке. Проект – Hot Cache: аналитическая NRT-система (near real-time) класса HTAP для сбора, агрегирования и предоставления данных в режиме, близком к реальному времени.

Система обслуживает несколько критичных направлений: агрегацию остатков по инвестиционным счетам клиентов, хранение предвычисленных фич для ML-моделей, оперативную аналитику для скоринга и антифрода. Тестирование охватывает весь стек: UI, REST API, SQL/JDBC-интерфейсы, две базы данных с разной архитектурой — Tarantool Column Store для аналитических запросов и Tarantool Database для транзакций, — Kafka-потоки и CDC-события, E2E-сценарии от источников до потребителей.

Плюс отдельное направление — тестирование внутреннего ИИ банка для автоматизации рутинных QA-задач: валидация качества ответов AI-моделей, тестирование промптов, проверка генерации тест-кейсов, генерация кода с помощью ИИ и тестирование код ревью у LLM моделей.

Я словно сорвал джек-пот, когда согласился на оффер в текущую команду. Здесь все профессионалы своего дела, каждый готов помочь и объяснить как можно сделать лучше. Каждый прислушивается к мнению и учитывает его при разработке. Много автоматизации, нагрузочное тестирование, API, UI, новая БД и использование всех актуальных инструментов на рынке — здесь я каждый день развиваюсь и приношу свои идеи и видение продукта.

Мне как никогда пригодился заводской бэкграунд. На заводе нельзя сказать «кнопка не работает», нужно найти причину в процессе, измерить, воспроизвести и исправить. Нужно подключать инженерное мышление. Что это такое? Инженерное мышление в моей версии означает:

1. Задавать вопрос «Почему?», а не только «Что?»: не «Кнопка не работает», а «Почему запрос возвращает 403 именно для этой роли»
2. Думать о системе в целом: как изменение в одном сервисе влияет на другие через Kafka-события, общую базу, API-контракты.
3. Оценивать риски: что сломается первым при нагрузке, какие граничные случаи наиболее опасны.
4. Участвовать в проектировании: дефект, найденный на этапе требований, стоит в 10 раз дешевле, чем найденный в продакшене.
5. Измерять время регресса, покрытие тестами, количество инцидентов — это цифры, за которые отвечает QA.

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

Итого: реально ли войти в айти через QA и сколько это стоит?

Подытожу:

1. Не заходите через ручное тестирование — это уже тени прошлого.
2. Учите архитектуру, понимайте, как части системы взаимодействуют
3. Разберитесь с HTTP, SQL и брокерами сообщений — это ваши рабочие инструменты
4. Навык чтения логов отличает хорошего QA от среднего
5. Освойте язык программирования, ибо автоматизация теперь не опция, а требование.
6. Развивайте инженерное мышление — думайте системами, а не кнопками

Пять лет назад я решил войти в неизвестность. Рынок менялся у меня на глазах. В 2021 все еще работала стратегия «войти через ручное тестирование», в 2022–2023 автоматизация из «плюса» превратилась в требование, в 2024–2025 без понимания распределённых систем и полного стека почти нет вариантов получить оффер.

Если готовы инвестировать 1-2 года в серьезный технический рост — переход реален. Путь от завода до распределенных систем в Альфа-Банке у меня занял пять лет. Не так уж быстро, но каждый шаг был в правильном направлении, потому что с самого начала я целился не в «войти в IT», а в «стать инженером».

У вас тоже все получится. Я в вас верю!

Примечание. Не стал перегружать материал списком теоретических материалов, статьями, ссылками на обучающие ресурсы, курсы и тренажеры, потому что у статьи другая цель — разъяснить принципы. Если же нужны теоретические материалы или пошаговый план обучения с ссылками, то читайте статью коллеги — «Быстрый старт в QA Fullstack: чем вооружиться будущему стажеру в Альфа-Банке». В статье уже есть база по трудоустройству в QA: план обучения, материалы, статьи и прочие наработки. После прочтения у вас будет четкий чек-лист с ссылками и примерами, что сделать и изучить, чтобы вероятность устроиться на работу QA была максимальна.