Какие навыки QA становятся ценнее в эпоху AI и автоматизации

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

В выборке Russia Quality Report 2025–2026 только 15% компаний сообщили об активном использовании AI в продуктивных QA-процессах. Ещё 21% ведут пилоты, 30% изучают сценарии. Причём ожидания трёхлетней давности оказались заметно бодрее реальности: в 2023 году распространение AI/ML в тестировании прогнозировали на уровне 38%, фактически соответствующую практику отметили 23% участников нового исследования.

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

Но направление уже видно и автоматизация заономерно растёт. Исполнение ускоряется. Однако решать и брать ответственность всё равно кому-то надо.

---

Автоматизируют действие. Ответственность — пока нет

Рассмотрим как в мире приживается такая философия. У Toyota для похожей инженерной логики давно существует термин jidoka — «автоматизация с человеческим участием». В методологии, базирующей Toyota Production System оборудование обнаруживает отклонение и может остановить процесс само. Смысл не в том, чтобы убрать человека из системы. Наоборот: человеку больше не нужно стоять рядом ради наблюдения за нормальной работой. Он подключается там, где возникло отклонение, нужно понять причину или улучшить сам процесс.

На сферу QA это масштабируется почти тем же образом. CI запускает тесты, система объединяет падения по группам, а модель первой анализирует логи. Она же подготовит черновик тест-кейса. Но ключевые решения по-прежнему остаются за человеком: определить уровень риска, понять, достаточно ли полученного результата, решить, можно ли доверять успешному прогону и как действовать после сбоя. Машине можно поручить повторяющиеся операции, но не принятие решений.

Автоматизация не отменяет инженерную экспертизу — она смещает её в область задач, где заранее нет однозначного ответа.

Почему тест-дизайн не заканчивается на генерации тест-кейса

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

В World Quality Report 2025–2026 проектирование тест-кейсов и уточнение требований уже относятся к ведущим сценариям применения GenAI. При этом только 15% участников сообщили о масштабировании технологии на весь enterprise, 43% остаются на экспериментальной стадии, а проблемы надёжности и валидации AI входят в число основных ограничений. Генерация пришла раньше доверия.

Показателен и кейс Яндекса. Для оценки сгенерированных тестовых артефактов команда использует эталонные наборы, подготовленные опытными специалистами, и отдельные механизмы оценки. В эксперименте с VLM-агентом первичный замер прохождения тест-кейсов дал около 45% корректно выполненных сценариев. Для практического использования команда обозначила планку не ниже 80%. Сам процент здесь не универсальный норматив. Интереснее устройство задачи.

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

Системное мышление становится рабочим инструментом, а не красивым soft skill

Современный дефект редко обязан жить там, где его видно. Так, кнопка не сработала из-за frontend. Или backend. Или просроченного токена. Или очереди. Или кеша. Или старых данных. Или соседний сервис ответил позже и система уже успела перейти в другое состояние.

Поэтому под системным мышлением в QA полезнее понимать вполне приземлённые вещи:

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

В RQR 32% участников сообщили, что уже обнаруживают большинство потенциальных инцидентов с помощью мониторинга и алертинга. Это не делает OpenTelemetry обязательным пунктом резюме любого тестировщика. Но граница между «тест выполнился» и «система действительно ведёт себя правильно» становится всё важнее.

Для backend, автоматизации и распределённых систем отсюда растёт ценность диагностики: читать лог как след события, сопоставлять запросы между сервисами, понимать trace, видеть разницу между дефектом продукта и проблемой данных или окружения.

Та же логика работает после релиза. Производственный инцидент полезен QA не самим фактом падения, а новой информацией о риске. Дальше её можно превратить в защитную меру и, если это оправдано, в новую или изменённую регрессионную проверку. Этот контур подробнее разобран в статье «Инцидент в проде: как превратить его в регрессионный тест».

Для Junior-спецов это не новая точка входа в профессию. Не нужно смешивать грейды . Но идти дальше по специализации без понимания системы становится трудно.

В автоматизации дорожает не скрипт, а всё вокруг него

Автоматизация в российском QA уже выглядит не экспериментом, а базовой инженерной практикой. В RQR её фокусным направлением назвали 67% компаний.

При этом основные сложности находятся уже не в вопросе «как написать ещё один UI-тест». 37% участников называют дефицит компетенций, 31% — нестабильность тестовой среды, по 23% — интеграцию инструментов и качество тестовых данных. Главным измеримым эффектом автоматизации 68% считают сокращение времени регрессионного тестирования.

Эта совокупность трудностей очень характерна. Исходный код автоматизированного теста — лишь центральная часть процесса. Прежде чем его написать, необходимо определить, что именно автоматизировать и на каком уровне проводить проверку. Затем возникают вопросы тестовых данных, конфигурации окружения, параллельного запуска, интеграции с CI/CD, механизмов повторного выполнения, изоляции проблемных тестов, анализа результатов, поддержки фреймворка и выявления причин нестабильности. Искусственный интеллект эффективно уменьшает затраты на отдельные рутинные задачи: создание клиента для API, написание стандартных проверок, адаптацию типовых сценариев, разработку компонентов Page Object.

Архитектуру тестового контура он за команду не наследует. Поэтому программирование не исчезает из набора навыков QA. Меняется то, за что оно ценится. Просто написать работающий скрипт становится легче. Выбрать правильный уровень автоматизации, встроить проверку в поставку и сохранить достоверность сигнала — нет. Как ручные и автоматизированные результаты собираются вместе с контекстом выполнения, отдельно разобрано в материале о тестовых запусках в ТестОпс.

Результат AI сам становится объектом тестирования

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

• evaluation dataset — набор примеров для оценки;
• golden dataset — проверенный эталон;
• LLM-as-a-Judge — модель, оценивающая результат другой модели по заданным критериям;
• проверка tool calls — вызовов инструментов;
• контроль побочных действий;
• regression evaluation после изменения модели, инструкции или контекста;
• фиксация версии модели и условий эксперимента.

Но и здесь не получается красивой рекурсии «AI проверит AI — человек свободен». Критерии для judge-модели тоже кто-то задаёт. Эталон собирает человек. Ошибки оценщика приходится искать отдельно. Именно поэтому полезный AI-навык для QA шире prompt engineering. Важно уметь поставить задачу модели, подобрать достаточный контекст, ограничить доступные действия и проверить результат независимым способом.

В статье о подготовке QA-контекста для AI Ассистента мы разбирали первую половину этой задачи: требования, тест-кейсы, результаты, окружения и дефекты становятся полезны модели, только когда между ними есть понятные связи. Доступ к внешним данным и инструментам через MCP добавляет следующий слой — управляемые действия. Его архитектура отдельно разобрана в материале про MCP для QA-команд.

Контекст нужен в основном для AI, а людей интеерсуют результаты проверки.

Анализ результатов становится важнее самого факта запуска

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

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

Тут особенно заметно, почему статус passed/failed сам по себе слабый сигнал. Он отвечает, чем закончилось выполнение. Не объясняет почему.

В ТестОпс контекст запуска связывает результаты с историей, тест-кейсами, ошибками и другими данными проекта. Сам по себе такой объём данных решения не принимает. Зато даёт материал для него.

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

AI заставляет измерять работу точнее, а не меньше

У AI есть неприятное свойство. Он хорошо создаёт ощущение скорости. Не всегда саму скорость. В эксперименте METR 16 опытных open-source-разработчиков выполняли 246 реальных задач в знакомых им репозиториях. Перед экспериментом они ожидали, что AI сократит время работы на 24%. После были уверены, что получили ускорение примерно на 20%. Фактически задачи с разрешёнными AI-инструментами заняли в среднем на 19% больше времени.

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

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

На Heisenbug 2026 Spring Яндекс посвятил этому отдельный доклад об измерении эффекта LLM в команде из 1000+ QA-инженеров. Вопрос там поставлен ровно инженерно: как отделить реальный эффект от вау-ощущения. Токены посчитали. Промпты тоже. Пользы от этого пока может быть ноль.

Продуктовый и риск-ориентированный взгляд становится дороже механического покрытия

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

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

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

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

Что тогда действительно теряет самостоятельную ценность

Повторяемое ручное исполнение стабильного сценария автоматизировалось задолго до LLM. AI просто расширил фронт.

Быстрее становятся:

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

Эти операции не исчезают. Но всё сложнее строить профессиональную ценность только на способности выполнить их вручную.

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

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

Какие навыки QA развивать в 2026 году

Это не общий чек-лист, а про разные QA-роли и рост по направлению. Senior-требования не подходят новичку — лучше смотреть, куда развиваться дальше.

Общий вектор не предполагает один и тот же карьерный путь. Кто-то останется сильным исследовательским тестировщиком. Кто-то глубже уйдёт в автоматизацию, платформенную инженерию, performance или security. Кому-то понадобится больше продуктового контекста. Меняется другое: чем выше цена ошибки и чем сложнее система, тем меньше ценится выполнение задач без понимания причин и последствий.

Умение пользоваться AI — уже навык. Но не тот, о котором чаще говорят

PwC в Global AI Jobs Barometer 2025 проанализировала почти миллиард вакансий на шести континентах. В профессиях, сильнее затронутых AI, набор требуемых навыков менялся на 66% быстрее. В той же глобальной выборке вакансии и сотрудники с AI-навыками были связаны в среднем с 56-процентной зарплатной премией относительно аналогичных ролей без них.

Это не статистика российского QA. Поэтому нельзя взять 56%, приписать их тестировщику с ChatGPT и строить карьерный план. Полезен здесь другой вывод: AI-грамотность достаточно быстро перестаёт быть экзотической специализацией. Она становится частью обычной профессиональной грамотности там, где инструмент уже вошёл в процесс. Для QA этот навык выглядит не как «умею писать длинный промпт». Скорее так:

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

AI на базе слабой предметной экспертизы просто быстрее выдаёт слабый результат. Иногда он выглядит даже лучше. В этом и вся магия.

---

Главный навык после очередной волны автоматизации

Toyota стала известна не потому, что поставила на завод больше машин. В Toyota Production System автоматизация встроена в цикл, где отклонение нужно обнаружить, процесс можно остановить, причину надо понять, а затем изменить сам способ работы. Именно так jidoka соседствует с kaizen — постоянным улучшением процесса.

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