Привет! Меня зовут Владислав Миронов. Я отвечаю за внедрение LLM в процессы QA Яндекса и в этой статье расскажу, каких результатов мы достигли — от генерации тест‑кейсов и автотестов до помощи в ручном тестировании. Поделюсь не только успехами, но и тем, какие компромиссы и организационные решения понадобились, чтобы всё это заработало.
В статье покажу, как мы разрешаем противоречия между командами, уходим от «зоопарка» инструментов и строим централизованную экосистему, где качество остаётся под контролем: реальные схемы, примеры и цифры, без магии и маркетинга.
Спойлер: рассчитывать можно на многое, но и вложиться придётся основательно. Парой промптов тут, к сожалению, не обойтись.
С чего мы начинали
Нам в команде автоматизации процессов очень хотелось прощупать границы применимости генеративных нейросетей. Область QA с самого начала выглядела подходящей для оптимизации с LLM: у задач довольно чёткая структура, паттерны и гранулярность. Эксперименты, проведённые параллельно в нескольких департаментах, показали наибольшую потенциальную выгоду от LLM’изации тестирования в следующих направлениях:
генерация чек‑листов и тест‑кейсов;
написание E2E‑автотестов;
ручное (в том числе регрессионное) тестирование.
И мы решили сфокусироваться на них.
В командах стихийно стартовала разработка ИИ‑прототипов. Быстро появились MVP, которые умели писать простые автотесты и генерировать приличные чек‑листы.
Проблема вскрылась на масштабировании: чуть выходим за узкие сценарии — качество резко падает. LLM — отличный персональный помощник, который относительно просто адаптируется под нужды одного человека. А сделать хороший ИИ‑инструмент для команды из 15 человек — сложно, для тысячи тестировщиков в Яндексе — очень сложно. И это наш кейс.
«Зоопарк» технологий: как из него выбраться
Дальше закономерно появился «зоопарк» технологий: команды, недовольные качеством получившихся у коллег MVP, начали делать своих ИИ‑агентов и генераторы тест‑кейсов. С LLM прототип поднимается за пару дней — расползание неизбежно.
И это проблема. Но заключается она не в самом разнообразии, а в последствиях:
Каждый инструмент нужно поддерживать: процессы меняются, приходится крутить промпты и пайплайны данных везде.
Нет общих метрик качества на уровне компании.
«Налог на поддержку» легко съедает выгоду от автоматизации, а отсутствие сквозных метрик для нас неприемлемо.
Конечно, можно применить административное давление: назвать один инструмент правильным, а остальные запретить. Формально это работает, но полностью убивает мотивацию и инициативу команд.
Мы таким путём идти не хотели и выработали компромиссное решение: разделили зоны ответственности. Центральная команда отвечает за инфраструктуру поставки данных и измерение качества, а локальные свободно экспериментируют с промптами и агентами (как раз там — их драйв и пространство для творчества). В этом случае лучшие идеи могут прорастать сразу на уровень всей компании.
А чтобы централизация не выглядела продавливанием сверху, платформа должна давать командам ощутимую дополнительную выгоду — тогда все сами захотят к ней подключиться.
Выгода, которую мы смогли предложить инженерам описывается двумя словами: интеграции и базовое качество.
Вот схема, которая наглядно показывает, за что отвечали центральная и локальные команды (внимание на цвет):
Синим цветом обозначены компоненты, которые полностью контролируются центральной командой. Зелёным — результаты совместного творчества центральной и локальных команд. Красным — то, что поддерживается исключительно локальными командами на их личном энтузиазме. Дальше расскажу о каждом элементе по отдельности.
TMS
Как видно из диаграммы, центральным и системообразующим элементом является TMS (Test Management System). Там хранятся тест‑кейсы и оттуда QA‑инженеры запускают тест‑раны. Если мы хотим использовать ИИ‑инструменты максимально нативно (конечно же, да), то лучшего места для бесшовной интеграции не придумать.
Таким образом, TMS становится центральной точкой для оркестрации всех сценариев использования ИИ в тестировании. И это то место, где мы реально можем контролировать взаимодействие со всеми локальными командами и принести им максимальную пользу.
Рассмотрим каждую из интеграций подробнее.
Генерация тест-кейсов
Собрать базовый генератор тест‑кейсов, а тем более чек‑листов (в чём разница, подробно описано в этой статье) — это, на первый взгляд, простое упражнение. Подключаемся к Трекеру и репозиторию, забираем задачу и связанный PR, передаём контекст в LLM — на выходе получаем чек‑лист и возвращаем его в комментарий к задаче. Готово?
Отчасти да. Такого MVP генерации чек‑листов хватило, чтобы им начали пользоваться несколько десятков команд (ежедневно генерируется более 200 чек‑листов). Но дальше начинаются задачи, которые требуют заметных усилий аналитиков и разработчиков.
Куда же на самом деле уходит основная энергия:
Интеграции с источниками данных (Трекер задач, Репозиторий, Вики с документацией). Критично иметь единые «официальные» MCP‑коннекторы ко всем внутренним сервисам. Пока их нет, инженеры подключают своих ИИ‑агентов напрямую п�� API и лепят кастомные надстройки — это невозможно поддерживать на масштабе. Аппетит к новым источникам растёт — значит, растёт и количество необходимых MCP.
Интеграция с TMS. Появилась новая потребность — workflow «принять/отклонить результат генерации тест‑кейса». По умолчанию TMS исходит из того, что инженер знает, что делает, создавая тест‑кейс. С приходом генеративных нейросетей это предположение перестало работать. Добавлять тест‑кейс от модели без перепроверки нельзя: каждую запись должен валидировать человек (причём имея возможность подтвердить или отклонить каждый шаг тест‑кейса отдельно). Да, это «съедает» часть мгновенной пользы, но даёт единственный надёжный сигнал о том, насколько система действительно качественно работает.
Качество. Самая сложная часть. В предыдущем пункте я уже упоминал валидацию в TMS: по ней мы получаем честную обратную связь — насколько хорошо агент справляется с задачами сейчас. Но что делать при обновлении модели? Как убедиться, что новый релиз не сломает процессы ещё до того, как попадёт в прод?
Один из рабочих подходов — LLM‑As‑A-Judge: одна модель проверяет результат другой по набору критериев и выставляет оценки. Для этого нам пришлось собрать «золотой датасет»: тест‑кейсы, написанные опытными тестировщиками, и исходные артефакты, на основании которых они создавались. LLM‑As‑A-Judge сравнивает сгенерированные моделью кейсы с эталоном, оценивает полноту, точность, соответствие исходным данным — и на этой основе мы принимаем решение о качестве релиза.
Если MVP с чек‑листами делается за несколько дней или недель, то внедрение трёх пунктов выше — история на месяцы.
Зато результат стоил усилий. LLM‑As‑A-Judge — продукт совместной разработки центральной и локальных команд: эталонные наборы кейсов от разных департаментов позволили обучать модели, которые одинаково уверенно работают на разных типах задач. Плюс мы получили возможность безопасно подключать кастомные промпты локальных команд, прогоняя их через единый пайплайн валидации перед релизом.
В итоге у нас получилась гибкая схема: для сложных узких сценариев — специализированные модели/пресеты, для остального — базовая модель, которую развивает центральная команда.
Качество остаётся под контролем, а «зоопарк» технологий сократился. Десятки команд Яндекса уже генерируют чек‑листы и тест‑кейсы, используя ИИ‑инструменты, что экономит в среднем 50% времени.
Генерация кода E2E-автотестов
Это самая гибкая часть. Сложных инструментов, которые локальные команды хотели бы пилить сами, почти нет. Базовый инструмент — ИИ‑ассистент для кода (в Яндексе за это отвечает Yandex Code Assistant).
Главная сложность — научить инженеров работать с LLM так, чтобы они ускоряли, а не тормозили. Эту функцию взяла на себя центральная команда, но проводит обучение точечно — там, где локальные ИИ‑энтузиасты ещё не успели распространить практики на своих коллег.
Первоначальная гипотеза о том, что достаточно выложить хорошие материалы в общий доступ, оказалась неверной: она работает только для тех самых энтузиастов (их много, но далеко не 100%). У большинства банально нет времени глубоко погружаться в учебники и туториалы при высокой загрузке.
Мы перешли к формату тренингов‑хакатонов в малых группах: опытный тренер приходит к команде конкретного сервиса, работает на их кодовой базе и помогает каждому участнику писать автотесты с помощью ассистента.
Это достаточно сложно организовать в масштабе Яндекса, но эффект очевиден: доля активного использования ИИ в командах после тренинга составляет ~60% против ~30% без него, а скорость написания кода увеличивается в среднем на 30%. На момент написания статьи мы успели обучить половину QA‑инженеров компании.
Прохождение ручных тестов ИИ-агентом
А это — самая наукоёмкая (и потенциально профитная) часть. Чтобы ИИ понимал, что происходит с приложением, с которым он должен взаимодействовать, нужны очень сложные инструменты. За основу мы взяли собственного ИИ‑агента (того же, который с августа тестируется в Яндекс Браузере). Мы планируем дообучить его под сценарий функционального тестирования в вебе и затем в мобильных приложениях.
Чтобы подобные агенты качественно справлялись со своей задачей, необходимо развивать соответствующие базовые технологии, например:
VLM, которые умеют распознавать элементы UI на скриншотах/видео;
MCP для браузера и нативных приложений, которые дают доступ к текущей сессии, DOM и событиям.
Инструменты такого уровня с приемлемым качеством сложно найти даже у крупных ИИ‑вендоров — даже платно.
Чтобы не быть голословным, приведу цифры: первичный замер качества прохождения тест‑кейсов ИИ‑агента на VLM (замеряли на Яндексовой и внешних моделях) дал примерно 45% точности. То есть агент правильно выполнил действия, описанные в тест‑кейсе, в 45 случаях из 100. Чтобы система приносила нам пользу, нужно как минимум 80%.
Когда мы достигнем целевых метрик, то сможем запускать бóльшую часть регрессионных тестов на релизах без участия людей. Параллельно разработчики смогут гонять новые фичи без ожидания свободного тестировщика, что сокращает цикл обратной связи и доработки.
Для QA‑инженеров это означает меньше рутины и больше времени на сложные задачи, где нужна экспертиза и концентрация: анализ инцидентов, исследовательское тестирование, улучшение стратегии и метрик качества.
Над внутренними VLM и MCP у нас работает центральная команда: это серьёзная работа ML‑разработчиков, QA‑инженеров и заметные затраты на GPU для дооб��чения. Локальные команды поверх этих инструментов собирают ИИ‑агентов под свои сценарии. Чтобы дать им максимум свободы и удобства, мы разработали формат открытого интерфейса в TMS для запуска агентов. Выглядит это примерно так: тестировщик выбирает тест‑кейс для запуска, нажимает кнопку «Запустить на ИИ» и выбирает любого из загруженных коллегами ИИ‑агентов, реализующих этот интерфейс. Дополнительно мы предоставляем аналитику качества выполнения кейсов по каждому из агентов.
Генеративные нейросети — впечатляющая и во многом переломная технология, которая действительно способна произвести «вау‑эффект». Но при создании реальных инструментов инженеры обычно проходят две стадии:
Первая: «Я переверну свою индустрию за выходные!»
И сразу за ней вторая: «Это барахло вообще не делает то, что мне надо!»
Работа над качеством, надёжностью и масштабированием осталась столь же трудоёмкой, как и прежде. LLM открывает новые возможности, но требует не меньше системной инженерии, экспериментов и здорового скепсиса.
Мы только в начале пути, и многое ещё предстоит осмыслить, но направление определённо стоит наших усилий.
Если у вас есть свои кейсы внедрения LLM в процессы автоматизации — делитесь ими в комментариях, будет интересно обсудить.