Вступление

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

Цель статьи — разобраться, как сегодня чувствует себя направление QA, куда развивается рынок и какие новые требования предъявляются к специалистам. С приходом новых технологий, включая искусственный интеллект, ручной труд становится всё менее востребованным, и всё больше компаний стремятся к автоматизации тестирования.

Важно! Эта статья не обесценивает ручное тестирование и не говорит, что «Manual QA не нужны». Ручное тестирование по‑прежнему важно, особенно там, где автоматизация не окупается или невозможна. Здесь я делаю аналитику текущего состояния рынка: как меняются роли, требования и ожидания от QA-специалистов, и что это значит для тех, кто планирует своё развитие.

История

Когда я пришёл в QA 9 лет назад, моя первая задача была — пройти 300 тест-кейсов по Excel за два дня. Автотесты тогда считались чем-то из мира магии. И это не было чем-то необычным — так работала большая часть индустрии.

Ещё 5–10 лет назад профессия QA выглядела совершенно иначе. В компаниях было абсолютно нормальной практикой иметь 5–10 ручных тестировщиков на продукт. При этом автотестов либо не было вовсе, либо они существовали в зачаточном виде. Основная работа выполнялась вручную: тестировщики проверяли новые фичи руками, выполняли регрессии на основе больших наборов тест-кейсов, хранившихся в Excel или специализированных системах вроде TestRail.

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

И надо признать: автоматизация тогда была гораздо сложнее и дороже. Основным инструментом для UI-тестирования был Selenium, с которым приходилось бороться: нестабильные тесты, постоянные StaleElementReferenceException, сложная настройка окружений, костыли для интеграции со скриншотами и видео. Написание автотестов было долгим и болезненным процессом, который не всегда приносил ощутимую бизнес-ценность.

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

Эта модель существовала годами, и ещё 5 лет назад была абсолютно нормой. Да, все «хотели автотесты», но чаще на уровне деклараций: автоматизация была сложной, дорогой и далёкой от идеала. В итоге основную рабочую силу составляли Manual QA, которые тестировали продукт полностью руками и обеспечивали стабильность релизов.

А что случилось потом?

Время шло, проекты становились сложнее, а требования к скорости релизов — выше. Manual QA продолжали выполнять свою работу, но параллельно происходила тихая революция — автоматизация постепенно выходила из статуса «эксперимента» и становилась стандартом.

Новые инструменты и технологии

Огромную роль сыграли инструменты. Появились решения вроде Playwright, которые сделали автоматизацию проще и стабильнее.

Помню, как первые тесты на Selenium, которые я видел, падали чаще, чем запускались. Сбоку к ним был приделан костыль, который делал скриншоты на протяжении всего теста и потом собирал их в видео «на минималках». Получалось что-то вроде слайдшоу, но тогда это считалось вау‑функционалом. Про мобильные автотесты тогда вообще никто не говорил — это считалось чем-то «за гранью». А теперь Playwright делает видео и скриншоты из коробки, да ещё и с trace viewer в подарок.

Кроме того:

• больше не нужно бороться с вечными StaleElementReferenceException;

• диагностика и отладка тестов стала быстрее и удобнее;

• появились встроенные возможности записи и анализа выполнения тестов без костылей.

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

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

Архитектурные изменения

Изменения происходили не только на уровне инструментов. IT-индустрия начала массово уходить от монолитных архитектур. Если раньше крупные продукты строились, например, на Django или других фреймворках «всё в одном», то теперь всё чаще их переписывают на микросервисы. Появились Golang, FastAPI, gRPC, Docker, Kubernetes — технологии, которые изначально предполагают независимые, изолированные сервисы.

Когда компании начали переписывать свои огромные монолиты на микросервисы, стало понятно, что гигантские E2E‑тесты, покрывающие половину функциональности за раз, больше не нужны. Их место заняли интеграционные и изоляционные автотесты под каждый отдельный сервис. Всё чаще начали использоваться тесты на моках, и само понятие “мок” перестало быть чем‑то редким и непонятным — оно стало частью стандартного процесса. Это одновременно упростило автоматизацию и сделало её более продвинутой.

Эти изменения отразились и на тестировании:

• Вместо одного огромного отдела QA появилась сеть маленьких фича-команд.

• Каждая команда отвечает за свой кусочек функциональности и может самостоятельно автоматизировать тестирование.

• Экспертиза «по всему продукту» перестала быть необходимой, а вот умение писать быстрые и надёжные автотесты стало базовым требованием.

Подходы и роли

Наряду с архитектурой менялись и сами подходы:

• Shift-left testing стал нормой: тестирование смещается на ранние этапы разработки, а значит, автотесты нужно писать одновременно с кодом или даже до него.

• Появилось и укрепилось направление SDET (Software Development Engineer in Test), когда QA-инженер одновременно является разработчиком инфраструктуры и фреймворков для тестирования.

• Стали востребованы Fullstack QA — специалисты, которые совмещают ручное тестирование, автоматизацию и анализ качества продукта. Всё чаще встречается модель «30% ручного, 70% автоматизированного тестирования».

Всё плавно двигалось в сторону автотестов. Хотите релизить быстрее? Нужно тестировать быстрее. А чтобы тестировать быстрее — нужны быстрые и атомарные автотесты. Тут на помощь пришёл подход Shift-left testing: тесты начали писать параллельно с кодом, а иногда даже раньше. Но одно дело — накидать несколько тестов, и совсем другое — сделать это масштабируемо и стабильно. Понадобились люди, которые умеют не просто писать тесты, а строить целые платформы и инфраструктуру. Так в индустрии закрепилась роль SDET — специалистов, которые соединяют навыки разработчиков и тестировщиков и создают основу для действительно массового и надёжного автотестирования.

Новые акценты: нагрузка и производительность

Свой первый нагрузочный тест я написал ещё в 2018 году, и тогда это казалось чем‑то невероятно крутым. Хотя, по сути, тест сводился к отправке HTTP‑запросов к одному GET‑эндпоинту, и делал я его в хардкорном интерфейсе Apache JMeter. Сегодня всё выглядит совсем иначе: появилось много инструментов, которые позволяют писать нагрузочные тесты на привычных языках программирования и сразу получать удобные и наглядные отчёты.

В целом индустрия тоже изменилась. Крупные компании переписали свои продукты на микросервисы, и потребность в нагрузочном тестировании резко выросла: нужно проверять, как вся эта распределённая архитектура ведёт себя под нагрузкой. Рынок стал активно требовать экспертизы не только в функциональном тестировании, но и в нагрузочном. Если раньше этим занимались специализированные команды или внешние подрядчики, то сегодня это ожидаемый навык самого QA-инженера. Нагрузочное тестирование и смежные направления (SRE‑практики, мониторинг, анализ метрик) всё чаще воспринимаются не просто как “бонус”, а как реальное конкурентное преимущество при найме.

Итог изменений

Все эти факторы постепенно изменили рынок:

• Держать большой штат ручных тестировщиков стало экономически невыгодно.

• Инвестировать в автотесты и регулярно их запускать стало проще, быстрее и дешевле.

Эти изменения заняли годы — 5–10 лет. Они не произошли за одну ночь, но сегодня тренд очевиден: автоматизация из «опции» превратилась в стандарт.

Будет ли жить QA?

Если коротко — да, QA как профессия никуда не исчезнет. Тестирование по‑прежнему нужно и будет нужно всегда, потому что пользователи хотят получать качественные продукты. Однако меняется сама роль тестировщика и требования рынка.

Сдвиг фокуса: от Manual QA к AQA

В последние годы наблюдается чёткий тренд:

• количество вакансий для автоматизаторов (AQA, SDET) растёт,

• а вакансий для чисто ручных тестировщиков становится всё меньше.

Если вы сегодня активно ищете работу, это наверняка заметно: всё больше предложений требуют либо опыт автоматизации, либо как минимум готовность в неё развиваться. Иногда даже специалисты с 5–6 годами опыта в ручном тестировании сталкиваются с тем, что не могут найти подходящую работу, потому что рынок требует навыков написания автотестов.

Это не просто «локальное ощущение». Достаточно открыть любой популярный сайт с вакансиями и сравнить количество предложений для Manual QA и AQA — перевес будет очевиден в пользу автоматизаторов.

Почему так происходит?

Причины этого тренда мы уже разобрали выше: автоматизация стала проще, дешевле и надёжнее, а бизнесу нужно выпускать обновления всё быстрее. В таких условиях компании заинтересованы в людях, которые умеют не только проверять продукт вручную, но и строить инфраструктуру для тестов, писать сценарии и интегрировать их в CI/CD.

Ручное тестирование остаётся, но чаще как дополнение, а не как основной процесс. Компании хотят «гибридных» специалистов, которые могут покрыть критические проверки руками, но при этом обеспечивают стабильный автоматизированный регресс.

Подтверждение тренда: данные с курсов

Я провожу обучение по автоматизации тестирования, и на моих курсах есть интересная статистика: около 80% студентов приходят из ручного тестирования. Причины у всех примерно одинаковые:

• на текущей работе требуют писать автотесты;

• хочется сменить работу, но почти везде в требованиях — автоматизация;

• есть страх остаться без работы, если не освоить новые навыки.

Этот тренд говорит о простом факте: рынок диктует свои правила, и они меняются в сторону автоматизации.

Что с этим делать?

IT-сфера похожа на эскалатор, который движется вниз. Если вы просто стоите на месте, то постепенно скатываетесь вниз вместе с ним. Чтобы хотя бы оставаться на текущем уровне — нужно идти, а чтобы двигаться вперёд — придётся бежать. Главное, конечно, не доводить себя до выгорания.

Этот принцип особенно актуален для QA. Мы видим очевидный тренд: сдвиг в сторону автоматизации продолжается и будет только усиливаться.

Какие шаги стоит предпринять?

1. Начать осваивать автоматизацию. Даже если вы «чистый» Manual QA, начните постепенно учиться писать автотесты. Это не значит, что нужно сразу бросить текущую работу и уйти в «кодеры». Достаточно понять основы: как пишутся тесты на Python или Java, как работают фреймворки вроде Pytest или JUnit, как устроены инструменты типа Playwright, Cypress или REST Assured.

2. Разобраться в CI/CD и процессах разработки. Современное тестирование тесно связано с DevOps-практиками: тесты должны автоматически запускаться в CI/CD при каждом изменении кода, результаты должны быть видны всей команде, а их стабильность — контролироваться. Даже базовое понимание Jenkins, GitLab CI или GitHub Actions уже даёт преимущество на рынке.

3. Изучать смежные области. Всё чаще компании ждут от QA более широкой экспертизы: понимания основ нагрузочного тестирования, мониторинга (Grafana, Prometheus), анализа логов, работы с API и микросервисами. Это не значит, что вы должны сразу стать SDET или DevOps-инженером, но базовые знания помогут оставаться конкурентоспособным.

4. Не забывать про софт-скиллы. QA — это не только кнопки и тесты, это ещё и общение с разработчиками, аналитиками, продуктовой командой. Умение правильно формулировать баг-репорты, аргументировать необходимость тестов или инфраструктуры — важная часть профессии.

Профессия QA не исчезает, но трансформируется. Рынок хочет видеть специалистов, которые понимают процессы разработки и умеют автоматизировать тестирование. Если вы сегодня Manual QA — это не повод для паники, а повод для движения. Начните изучать новые инструменты, погружайтесь в автоматизацию, и вы не просто сохраните свои позиции, но и откроете новые карьерные возможности.

А что если?

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

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

Но важно понимать: такие вакансии встречаются не только в тестировании. Есть работодатели, которые хотят взять разработчика, который и фронт пишет, и бэкенд пилит, и инфраструктуру поднимает, и по ночам дежурит как SRE. Поэтому здесь важно одно — понимать, куда вы идёте, и если условия не устраивают — вовремя уходить.

И да, сфера QA действительно движется к автоматизации. Если у вас 15 лет опыта ручного тестирования, но вы не хотите работать рядом с коллегой, у которого 2 года опыта и та же зарплата, стоит задать себе вопрос: «Почему за 15 лет я не освоил автоматизацию или не ушёл в разработку?» Работодатель платит за навыки, а не за количество лет в резюме. И главное: сидеть и жаловаться на рынок — не лучший вариант. Если не устраивает текущее направление, всегда есть возможность переобучиться: в автоматизацию, разработку, DevOps или куда-то ещё.

Любая профессия в IT меняется. Разработчики учат новые языки и фреймворки, DevOps уходят в платформенные решения, аналитики осваивают Data Science. QA — не исключение: раньше мы вручную щёлкали сотни тест-кейсов, теперь автоматизируем, строим фреймворки и анализируем метрики. Это не "деградация", это взросление профессии.

Да, есть работодатели, которые хотят "человека-оркестра", но есть и компании, где роль QA встроена в архитектуру качества: там тестирование — часть CI/CD, а QA участвует в архитектурных решениях. На рынке полно примеров, когда QA становятся платформенными инженерами, лидят команды или уходят в SDET, и их зарплаты сравнимы с разработчиками.

Можно воспринимать всё происходящее как катастрофу и писать пессимистичные комментарии, статьи, а можно — как вызов и возможность для роста. QA-инженер с современными навыками востребован не меньше разработчика. Вопрос только в том, готовы ли вы меняться вместе с индустрией или будете ждать, что индустрия замрёт ради вашего комфорта.

QA не умерло — оно взрослеет и становится сильнее

Мы больше не просто «нажимаем кнопки», а строим сложные экосистемы тестов, внедряем их в CI/CD, анализируем метрики, управляем качеством на уровне архитектуры. Да, эпоха, когда на проекте сидела команда из десяти ручных тестировщиков, уходит в прошлое. Но это не конец профессии — это её новая глава.

QA стало ближе к разработке, умнее и технологичнее. И это даёт каждому из нас шанс вырасти — стать автоматизатором, инженером по качеству, экспертом по нагрузке или fullstack QA.