Кодинг-агенты и LLM-ассистенты действительно меняют скорость разработки. Разработчик с подпиской на ИИ-инструмент за 20 долларов в месяц может за день сгенерировать объём кода, на который раньше уходила неделя. Но ускорение создания кода обнажает другую проблему: тестирование не успевает за этим потоком. В результате именно QA-специалисты становятся тем самым узким горлышком, из-за которого фичи не доходят до продакшена. Компании видят это и начинают сокращать тестировщиков — не потому, что качество больше не нужно, а потому, что старый формат работы перестал масштабироваться.

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

Почему тестировщики стали узким горлышком

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

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

Что автоматизируется в первую очередь

Компании сокращают не тестирование как функцию, а ручные и повторяющиеся задачи. Вот что уходит в автоматику быстрее всего:

  • Регрессионные прогоны. Если у вас есть стабильные автотесты, их можно запускать на каждый коммит без участия человека.
  • Проверка API и контрактов. Схемы, статус-коды, валидация полей — всё это хорошо покрывается автотестами.
  • Генерация тестовых данных и сценариев. LLM помогают быстро набросать кейсы, но их всё равно нужно проверять.
  • Смоук-тесты после деплоя. Базовые проверки доступности и ключевых сценариев можно автоматизировать полностью.

Остаются задачи, где нужен человек: исследовательское тестирование, оценка рисков, работа со сложными пользовательскими сценариями, анализ причин дефектов. Именно туда смещается ценность QA.

Как перестроиться инженеру по качеству

Если вы тестировщик и видите, что объём ручной работы растёт, а времени не прибавляется, действовать нужно по шагам.

  • Шаг 1. Оцените, сколько времени уходит на рутину. Выпишите задачи за неделю и отметьте те, что повторяются из релиза в релиз. Это кандидаты на автоматизацию.
  • Шаг 2. Освойте базовую автоматизацию. Начните с API-тестов и смоук-проверок. Не пытайтесь сразу покрыть всё — выберите один критический сценарий и автоматизируйте его.
  • Шаг 3. Встройтесь в процесс разработки. Участвуйте в обсуждении требований, проверяйте код на этапе ревью, предлагайте тестовые сценарии до того, как код написан.
  • Шаг 4. Научитесь работать с ИИ-инструментами. Используйте LLM для генерации черновиков тест-кейсов, анализа логов и поиска причин падений. Но проверяйте результаты — ИИ ошибается.
  • Шаг 5. Прокачайте системное мышление. Учитесь видеть, где в процессе возникают риски, и предлагайте решения на уровне архитектуры тестирования, а не отдельных проверок.

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

Типичные ошибки и примеры

Ошибка первая — пытаться автоматизировать всё подряд. В итоге автотесты становятся хрупкими, их поддержка съедает больше времени, чем ручное тестирование. Пример: команда написала сотни UI-тестов, которые падают при каждом изменении вёрстки, и теперь чинит их вместо проверки новых фич.

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

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

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

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