Краткая предыстория: как я вкатился в QA после завода с дипломом металлурга
По образованию я металлург. Закончил учебное заведение в 2019 году, а в 2021 уже получил работу в ИТ. Во время учебы я не мечтал о том, чтобы «поскорее получить диплом металлурга и устроиться тестировщиком», а хотел приносить пользу, работать на благо индустрии и расти по карьерной лестнице именно в профессии. Но всё вышло иначе.
Не считая того, что поиск работы после университета заканчивается тем, что тебе нужен опыт работы, чтобы получить работу, тяжело удержать желание удерживаться на работе, которую ты каким-то чудом смог получить:
Первую работу я нашёл через полтора месяца поисков — на авиационном заводе. Впервые увидел огромные самолёты вживую, участвовал в составлении планов разборки и сборки. Однако бытовые условия оказались тяжёлыми: в цехах не было отопления, и зимой приходилось работать в верхней одежде. Почти полгода я проработал стажером, без перспектив перевода в штат.
На втором заводе (шарикоподшипников) было чище, теплее и мне сразу дали должность «инженер-технолог первой категории». Но я попал в бюрократическое лимбо — выявлял брак подшипников и для оформления партии на доработку требовалось несколько подписей начальников, которые приходилось тащить клещами. Именно там я познакомился с человеком, который стал для меня «мостом» в IT. От него я впервые узнал о тестировании. Тема настолько меня заинтересовала, что я начал изучать требования к QA-специалистам и осваивать материалы параллельно с основной работой.
Третий завод казался самым перспективным: зарплата 27 000 рублей, стабильность, возможности роста. Но после разговоров с ведущими инженерами быстро стало ясно, что всё это иллюзия — при стаже 5-15 лет доход более опытных коллег выше моего всего на 15-20 тысяч рублей, а без поддержки «мохнатых рук» карьерный рост не светит. В то же время токарь и рабочие получали больше меня в 3 раза. И для чего нужно было столько лет учиться? Выгорание и разочарование постучались в дверь мгновенно.
Тогда я начал изучать требования к QA-специалистам параллельно с основной работой и грезил мечтой однажды устроиться тестировщиком в хорошую компанию. А после осознания того, что профессиональный рост нереален, достал свои конспекты по требованиям QA и начал учиться дальше.
Но если бы 2026 я планировал бы перейти с завода в QA, то мой план действий был бы иным, потому что окружающая обстановка изменилась. И вот, что бы я делал:
№1. Не пытаться войти в профессию через «ручное тестирование»
Мой первый оффер был именно «ручным» и звучал как-то так — «Специалист по федеральному тестированию в МегаФоне». Функциональное, регрессионное и интеграционное тестирование телекоммуникационных систем, тарифы, роуминг, USSD, SMS и всё такое. Никакого кода, никакой автоматизации, только хардкор. Кстати, в «МегаФоне» я впервые увидел IT-офис: светлый, живой, без производственного шума. Можно сказать, что я испытал культурный шок.
Скажу честно — я испугался оффера. Но не потому, что не знал инструментов — изучить их не сложно — а потому, что на заводе я был «инженером», человеком с понятной идентичностью, и хотя бы что-то понимал и знал, а в IT становился новичком.
Здесь могла бы быть мотивационная речь, но скажу без шуток — это самый сложный момент за весь путь. Не изучение Java, Kafka, фундаментальной теории тестирования или прогоны технических собеседований, а простое решение войти в неизвестность.
Но решение оказалось правильным. Я прошел школу дисциплины, научившись всему с нуля: составлять чек-листы, тест-кейсы, работать с требованиями.
Однако…
В 2021 году вход через ручное тестирование ещё работал и был самой короткой дорогой из желтого кирпича в мир IT — рынок принимал новичков с любовью, заботой и снисхождением к отсутствующим навыкам.
Сейчас если и существуют в дикой природе вакансии ручных тестировщиков, то там либо платят мало, либо нужно иметь коммерческий бэкграунд за спиной. К тому же желающих стало больше (невероятно много) благодаря рекламе курсов «Тестирования и вката в IT», а у компаний появилась возможность выбирать лучших из лучших.
Например, уже в 2024 году, когда я (снова) вышел на рынок в поисках более подходящей команды, и просматривал десятки вакансий, то ни разу(!) не видел, чтобы где-то было написано «требуется ручной тестировщик». Всем были нужны:
QA Engineer со знанием автоматизации.
Опыт в финтехе, знание CI/CD, Docker, Kubernetes.
Углубленное понимание API и т.д.
Большинство компаний уже хотели себе не просто «ручного тестировщика», а требования стали жестче и самих требований стало больше.
Что делать сегодня?
Если вы сейчас планируете заходить через ручное тестирование — не могу вас отговорить, но не рекомендую. Я бы начинал с фундамента, который позволит двигаться дальше с первого дня. О том, что входит в этот фундамент — далее.
№2. Изучать архитектуру
После МегаФона я перешёл в Эвотор — продуктовую компанию с e-commerce платформой «Магазин приложений». Впервые я поработал с REST API через Postman и Swagger, PostgreSQL, DevTools, кроссбраузерное тестирование, разбор логов в Kibana. Никаких USSD и тарифных планов — только веб-приложение с базой данных и API.
Слово «архитектура» я тогда понимал смутно. Знал, что есть «бэкенд» и «фронтенд», но слабо представлял что между ними. Первые месяцы тестировал «поверхностно»: нажал кнопку, посмотрел результат. Когда что-то шло не так, я мог сказать «баг есть», но не мог объяснить почему.
Мне повезло, что команда была сплоченной и все были готовы мне помогать и обучать по ходу процесса работы. Также я прошел от компании курсы по автоматизации для написания тестов и ускорения процесса.
Первые автотесты на Java, с использованием Selenide для UI и RestAssured для API написал именно здесь. Первые тесты были ужасны: медленные, нестабильные, падали «без причины». Хотя, на самом деле, причина была в том, что я не понимал, как части системы связаны между собой, не понимал архитектуру того, что тестировал, поэтому просто копировал примеры.
Постепенно, чем больше я работал с кодом, тем больше я начинал разбираться что и для чего используется и как это можно починить, автотесты работали стабильнее.
Пока я работал в Эвоторе, рынок незаметно менялся. В 2022 году компании начали массово сокращать команды, пересматривать состав ролей, сокращать вакансии «мануал тестировщиков» и добавлять в требованиях к QA-инженерам строки «Желательно знание автоматизации», «Опыт с API», «Базовый и средний SQL».
«Желательно» в 2022-м — это «обязательно» в 2024-м. Рынок давал сигнал заранее, просто его было легко не заметить, когда находишься, так сказать, внутри компании (или индустрии).
Тот, кто за два года в продуктовой компании освоил автоматизацию и понял архитектуру, в 2023 году выходил на рынок с совсем другим предложением, чем тот, кто два года кликал по чек-листам.
Что значит «понимать архитектуру»?
Проектировать системы не нужно, это работа архитектора, но нужно понимать:
как сервисы взаимодействуют— синхронно через HTTP или асинхронно через очередь сообщений;
где хранятся данные и как к ним обращаются разные компоненты;
что происходит при сбое одного из компонентов - кто из соседних сервисов это заметит;
уак данные трансформируются на каждом этапе пути от запроса до ответа.
Если бы сейчас я начинал свой путь в QA, то начал бы с практики: развернуть простое микросервисное приложение локально и посмотреть, как сервисы «разговаривают». Но для начала прочитал бы книгу «Designing Data-Intensive Applications» Мартина Клеппмана (есть русская версия «Высоконагруженные приложения») — это лучшее, что есть по теме для технического человека без опыта в IT. Там нет кода, зато есть объяснение того, как системы устроены изнутри. Для QA это важнее, чем уметь самому писать сервисы.
Следующий шаг — готовые демо-проекты на GitHub с низким порогом вхождения. Эти проекты поднимаются одной командой через Docker Compose. Соответственно, там не нужно копаться в коде, нужно исследовать: отправить запрос через Postman, посмотреть в логах как он прошёл по цепочке сервисов, намеренно «сломать» один из них (остановить контейнер) и посмотреть что происходит с остальными.
Рекомендую два репозитория такого формата:
Microservice Kafka Sample — здесь можно посмотреть как Kafka использутеся для обмена данными между микросервисами. Пример минималистичный: есть три сервиса (заказы, доставка, выставление счёта), Kafka между ними, PostgreSQL, поднимается через docker-compose up. Создаёте заказ в одном приложении, через некоторое время накладная и статус доставки появляются в других. Kafka используется для общения между сервисами, Postgres — у каждого сервиса своя база. Такая схема встречает QA в реальных проектах. Смотрите логи, трассируйте запрос, находите где «застряло».
Microservices with Spring Boot and Kafka Demo Project — проект чуть сложнее: три сервиса (заказы, платежи, склад), распределённые транзакции через паттерн SAGA, поддержка Docker Compose и Testcontainers. Хорошо показывает, что бывает, когда транзакция проходит через несколько сервисов и один из них «падает».
О том как работает Docker и для чего он нужен есть целые курсы и отдельные статьи, некоторые из них оставлю здесь:
Если бы начал изучить теорию и практикой совместно, то на Stepik есть курс «Microservices — паттерны и практика построения микросервисов». Русскоязычный, охватывает паттерны взаимодействия, асинхронные системы, RabbitMQ. Подходит именно для понимания концепций, а не для написания продакшн-кода.
Также оставлю ссылку на учебный проект для аналитиков — переходите, запускайте проект, изучайте, как работают микросервисы:
Главное предупреждение:
QA не нужно уметь писать эти сервисы самостоятельно. Цель — понять, что происходит внутри, когда данные «идут» от одного сервиса к другому. Поднял, потыкал Postman, почитал логи, остановил контейнер и посмотрел что случилось - этого уже достаточно, чтобы разговаривать с командой на одном языке.
№3: Изучать 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 |
№4: Учиться читать логи
В ГНИВЦ я работал на критически важном государственном контракте — сайт ЕРН для ФНС, обмен данными между госструктурами. Высокая регуляторная значимость, постоянные инциденты с продакшена, высокий темп.
Именно здесь я понял, что способность читать логи не «полезный навык в резюме», а основной инструмент диагностики в боевых условиях, потому что когда что-то падает в продакшене и нет времени воспроизводить баг вручную, есть только логи. Мы работали с Kibana для анализа логов и Grafana + Prometheus для мониторинга метрик и, для примера, типичный процесс диагностики выглядел так:
Получаем алерт: сервис X начал возвращать 500 ошибки.
Открываем Kibana, фильтруем по временному интервалу и имени сервиса.
Находим трейс запроса — от входящего HTTP-вызова до ответа базы данных.
Видим stacktrace: исключение в конкретном классе с конкретным сообщением.
Находим корневую причину — например, таймаут при обращении к внешнему сервису.
Здесь же я освоил Kotlin для написания автотестов и «смежный» стек: Kotest, JUnit5, Spring Test, Shift-left подход.
Когда в конце 2025 года я вышел на поиск новой команды, картина отличалась от 2024-го ещё сильнее. В объявлениях мелькали:
«Fullstack QA от 2-х лет».
«AQA от 2-х лет».
«QA Engineer со знанием автоматизации».
«Опыт в финтехе, знание CI/CD, Docker, Kubernetes».
Опыт работы с ИИ/LLM/Агентами.
Несколько раз я доходил до финальных этапов, но компании выбирали кандидатов с более узкой и глубокой специализацией. Оффер от Альфа-Банка я получил спустя полгода усердных поисков и прохождений интервью, потому что к тому моменту за плечами был полный набор: автоматизация, распределённые системы, опыт с Kafka, несколько доменов.
В 2025 компании искали не «хорошего тестировщика», а инженера, который умеет работать с распределёнными системами и может автоматизировать критичные сценарии, рутинные задачи. А навык работы с ИИ для решения вопросов в своих задачах для тестирования и автоматизации стал играть немаловажную роль при поиске кандидатов.
№5: Осваивать язык программирования
Шаг за шагом наполнялся мой стек инструментов и языков программирования для автотестов:
Java, Selenide, RestAssured, JUnit, Jenkins в Эвотор.
RestAssured, IntelliJ IDEA, Bitbucket, Jenkins, Kubernetes в СберТех.
В ГНИВЦ добавил Kotlin: Kotest, JUnit5, Spring Test, BDD подход (синтаксис стал лаконичнее, тестовые сценарии читались чище).
В Альфа-Банке стек автоматизации стал полноценным: Selenium, Selenide, RestAssured, Retrofit, JUnit5, Cucumber, Allure. UI, API, база данных и Kafka в одном проекте (часть фреймворка строится с нуля) + код ревью автотестов команды.
Зачем QA нужен язык программирования?
Писать автотесты. Ручной регресс из 500 тест-кейсов нереалистичен при еженедельных релизах. И это не предел, есть проекты где регресс порядка 5000 тестов.
Единый технологический стек для команды. Если QA пишет автотесты на том же языке, что и разработчик весь продукт, то QA и разработчики говорят на одном языке: можно обсудить проблему на уровне кода, быстро получить консультацию, а иногда разработчики сами запускают тесты для проверки фичи, вносят точечные правки в тестовый код, помогают диагностировать причины нестабильности.
Тестирование API — написать авторизацию, отправить запрос, проверить JSON-схему ответа.
Генерация тестовых данных — создать тысячи записей с разными параметрами.
Верификация данных в базе — SQL-запросы для проверки корректности записей.
Shift-left testing — писать тесты параллельно с разработкой, на этапе требований.
Java или Python — хорошие первые языки. Но я бы учил язык в контексте задач тестирования, а не в вакууме: написали бы первый тест через Selenium, сделал бы HTTP-запрос через RestAssured или requests, написал бы SQL-запрос к реальной базе данных.
№6: Развивать инженерное мышление
Сейчас я работаю ведущим специалистом по тестированию в дирекции разработки технологических продуктов на базе искусственного интеллекта в Альфа-Банке. Проект — 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, новая БД и использование всех актуальных инструментов на рынке — здесь я каждый день развиваюсь и приношу свои идеи и видение продукта.
Мне как никогда пригодился заводской бэкграунд. На заводе нельзя сказать «кнопка не работает», нужно найти причину в процессе, измерить, воспроизвести и исправить. Нужно подключать инженерное мышление. Что это такое? Инженерное мышление в моей версии означает:
Задавать вопрос «Почему?», а не только «Что?»: не «Кнопка не работает», а «Почему запрос возвращает 403 именно для этой роли»
Думать о системе в целом: как изменение в одном сервисе влияет на другие через Kafka-события, общую базу, API-контракты.
Оценивать риски: что сломается первым при нагрузке, какие граничные случаи наиболее опасны.
Участвовать в проектировании: дефект, найденный на этапе требований, стоит в 10 раз дешевле, чем найденный в продакшене.
Измерять время регресса, покрытие тестами, количество инцидентов — это цифры, за которые отвечает QA.
Если у вас техническая специальность, то и инженерное мышление у вас уже есть. Физики, химики, инженеры привыкли работать с причинно-следственными связями и системами. Это ценный багаж, который нужно лишь переложить на специфику программных систем.
Итого: реально ли войти в айти через QA и сколько это стоит?
Подытожу:
Не заходил бы через ручное тестирование.
Изучал бы архитектуру, стремился понять, как взаимодействуют части системы.
Разобрался бы с HTTP, SQL и брокерами сообщений, потому что это рабочие инструменты QA.
Навык чтения логов отличает хорошего QA от среднего.
Осваивал бы язык программирования, ибо автоматизация теперь не опция, а требование.
Развивайте инженерное мышление, потому что надо думать системами, а не кнопками.
Пять лет назад я решил войти в неизвестность. Рынок менялся у меня на глазах. В 2021 все еще работала стратегия «войти через ручное тестирование», в 2022–2023 автоматизация из «плюса» превратилась в требование, в 2024–2025 без понимания распределённых систем и полного стека почти нет вариантов получить оффер.
Путь от завода до распределенных систем в Альфа-Банке у меня занял пять лет. Не так уж быстро, но каждый шаг был в правильном направлении, потому что с самого начала я целился не в «войти в IT», а в «стать инженером».
У вас тоже все получится. Я в вас верю!
Я не добавил в статью список теоретических материалов, статьи, ссылки на обучающие ресурсы, курсы и тренажеры, потому что такой материал, дополняющий мой, уже написала моя коллега. Переходите в статью «Быстрый старт в QA Fullstack: чем вооружиться будущему стажеру в Альфа-Банке», где вы найдете базу по трудоустройству в QA: план обучения, материалы, статьи и прочие наработки. После прочтения у вас будет четкий чек-лист с ссылками и примерами, что сделать и изучить, чтобы вероятность устроиться на работу QA была максимальна.
