Как мы научили AI разбирать упавшие автотесты и заводить баги в Трекере

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

Проблема: автотесты упали, а что дальше?

Когда автотесты падают, сам факт красного запуска еще почти ничего не говорит. Нужно понять, что именно произошло:

• это реальный баг в продукте;

• сломался сам автотест;

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

• упало окружение или инфраструктура;

• изменился контракт, но Swagger или тесты еще не обновили;

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

Если каждый раз смотреть только список failed/broken тестов, команда быстро начинает тратить время на повторный разбор одних и тех же падений. Сегодня QA уже понял, что три теста падают из-за одной ошибки на бэке, завтра другой QA снова открывает те же тесты и снова проходит тот же путь.

Поэтому после запуска автотестов у нас есть простое правило: все упавшие результаты должны быть разобраны и привязаны к дефектам. В идеале после разбора в запуске не остается неразобранных failed/broken результатов.

Зачем нужны дефекты в TestOps

Дефект в TestOps для нас — это не просто еще одна сущность рядом с тест-кейсом и запуском. Это способ превратить хаотичный список падений в понятную базу причин.

Один дефект должен описывать одну причину падения. Не просто «404», «500» или «AssertionError», а конкретную проблему: например, endpoint получения изображений начал отдавать 404 для группы сценариев, где по контракту ожидается 200.

Это дает несколько практичных плюсов.

• Меньше дублей. Перед созданием нового дефекта QA проверяет, нет ли уже открытого дефекта с такой же причиной.

• Быстрее повторные запуски. Если такая же ошибка повторится в следующем прогоне, TestOps сможет автоматически привязать падение к уже существующему дефекту.

• Понятнее релизные риски. Перед релизом видно, какие критичные дефекты еще открыты, а какие падения уже известны и не блокируют выкатку.

• Есть связь с разработкой. Если причина — продуктовый баг, дефект связан с задачей в Яндекс Трекере.

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

Главная мысль: дефекты помогают не разбирать одно и то же падение заново после каждого запуска.

Как выглядит ручной процесс

Регламент разбора устроен достаточно прямолинейно.

1. Открываем запуск и смотрим неразобранные результаты

После запуска автотестов переходим в результаты прогона в TestOps и открываем обзор. Если в запуске есть неразобранные результаты, это значит, что на упавшие тесты еще не заведены дефекты или дефекты есть, но конкретные test results к ним не привязаны.

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

2. Анализируем ошибку в упавшем тесте

Дальше открываем упавший тест и смотрим причину падения. Например, тест мог упасть с ошибкой:

Expected status code <200> but was <404>.

Одного текста ошибки обычно недостаточно. Нужно раскрыть stack trace и найти строку, которая относится именно к нашему автотесту: класс и метод, где произошло падение.

Например:

IntegrationsRegressTests.getIntegrationsProductsAllImagesWithLimitTest

Теперь у нас есть две важные части:

• текст ошибки: Expected status code <200> but was <404>.;

• место падения в автотестах: IntegrationsRegressTests.getIntegrationsProductsAllImagesWithLimitTest.

После этого нужно понять причину. Не каждое падение автотеста равно продуктовому багу. Иногда проблема в host, токене, тестовых данных, setup, cleanup, Swagger-контракте или локальной десериализации ответа в generated model.

3. Создаем новый дефект или переиспользуем существующий

Если подходящий открытый дефект уже есть, связываем упавший тест с ним. Но важно не остановиться на простой ручной привязке. Если просто привязать текущий test result к дефекту, это сработает только для текущего запуска.

Чтобы TestOps сам привязывал похожие падения в следующих прогонах, у дефекта должно быть правило автоматизации.

Если такой причины раньше не было, создаем новый дефект. Заголовок на первом шаге не нужно делать слишком сложным, но он должен отражать суть ошибки. Описание можно доработать так, чтобы разработчику было понятно:

• какой endpoint или сценарий падает;

• какой запрос выполнялся;

• какой ответ ожидали;

• какой ответ получили;

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

4. Создаем или связываем задачу в Яндекс Трекере

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

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

5. Настраиваем правило автоматизации

Правило автоматизации — это то, из-за чего дефекты начинают реально экономить время.

В простом случае в matcher добавляется текст ошибки:

Expected status code <200> but was <404>.

Но такой шаблон может быть слишком широким. Ошибка 404 может появиться в разных местах и по разным причинам. Поэтому правило лучше ограничить еще и stack trace:

IntegrationsRegressTests.getIntegrationsProductsAllImages*

Такое правило говорит TestOps: если в новом запуске снова встретится ошибка «ожидали 200, получили 404» и она произошла в группе тестов про получение изображений, нужно автоматически привязать это падение к этому дефекту.

Это не просто ловит любой 404. Это ловит конкретную повторяющуюся причину падения.

Matcher не всегда нужно настраивать до конкретного тестового метода. Если проблема относится ко всему классу тестов, можно ограничиться классом в stack trace.

Если ошибка уникальная и сама по себе достаточно специфичная, иногда хватает matcher только по сообщению об ошибке.

6. Проверяем результат

После создания дефекта нужно проверить, что:

• дефект привязан к нужным упавшим test results;

• у дефекта есть правило автоматизации;

• если это продуктовый баг, создана или привязана задача в Яндекс Трекере;

• в обзоре запуска стало меньше неразобранных результатов;

• matcher не слишком широкий и не будет скрывать новые независимые ошибки.

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

Какие правила мы для себя зафиксировали

Чтобы база дефектов не превратилась в свалку, мы придерживаемся нескольких правил.

• Один дефект — одна причина падения.

• Перед созданием нового дефекта проверяем, нет ли уже подходящего открытого дефекта.

• Не объединяем в один дефект продуктовый баг, проблему инфраструктуры, проблему тестовых данных и ошибку автотеста.

• Любой новый дефект создаем с правилом автоматизации.

• Matcher не должен быть слишком широким: общий 404, 500 или AssertionError без ограничения по stack trace почти всегда плохая идея.

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

Отдельно важно классифицировать падения. Если причина в автотесте, тестовых данных, авторизации, окружении или Swagger mismatch без backend-багa, не нужно заводить продуктовый дефект в Tracker. Иначе команда разработки получает шум, а доверие к автотестам падает.

Где здесь появляется AI

Ручной процесс работает, но он все равно занимает время. Нужно открыть запуск, получить все failed/broken результаты, посмотреть детали, сгруппировать похожие ошибки, проверить существующие дефекты, создать matcher, связать test results, создать или проверить задачу в Яндекс Трекере и убедиться, что все поля заполнены правильно.

Поэтому для ускорения разбора мы подключили AI + MCP.

Про наш MCP TestOps я уже рассказывал в статье «Cursor AI для ревью ручных тест-кейсов в TestOps». Если коротко, MCP позволяет Cursor/Claude Code ходить в TestOps, получать нужные сущности и записывать результат обратно. Для этой задачи мы используем MCP TestOps вместе с MCP Яндекс Трекера.

Поверх этого я написал skill /testops-run-defects. На вход ему передаются три параметра:

/testops-run-defects <ссылка на launch/run в TestOps> <team> <component>

Например:

/testops-run-defects https://allure.svc.vkusvill.ru/launch/67737 red loylt-gifts

Дальше AI-агент делает примерно то же, что делал бы QA по регламенту, только быстрее и более системно:

• достает launch id из ссылки;

• получает неразобранные failed/broken test results из TestOps;

• запрашивает детали падений, а stack trace берет только там, где без него нельзя построить нормальный matcher;

• группирует падения по одной причине;

• проверяет открытые дефекты и их matcher-правила, чтобы не плодить дубли;

• отделяет продуктовые баги от проблем тестов, данных, окружения, авторизации и Swagger mismatch;

• создает дефекты в TestOps с matcher-правилами;

• создает связанную задачу в Яндекс Трекере через интеграцию TestOps;

• явно привязывает каждый упавший test result к своему дефекту;

• через MCP Яндекс Трекера проверяет и донастраивает поля задачи: команду, компонент, тип, приоритет и тег;

• в конце делает контрольную проверку: matcher есть, test results привязаны, Tracker-задачи созданы, неразобранных результатов не осталось.

Важно, что AI не должен просто создавать дефекты на все красное подряд. В skill зашиты правила защиты от ложных дефектов: если причина похожа на проблему тестовых данных, неверный host, неправильную авторизацию, сломанный setup или ошибку автотеста, такой результат не должен превращаться в backend-баг.

Как это выглядит на практике

Ниже пример запуска skill. Передали ссылку на launch, команду red и компонент loylt-gifts. Агент получил список падений, разобрал их, создал дефекты, связал их с задачами в Tracker и проверил результат.

На выходе получаем короткий отчет: сколько результатов обработано, какие дефекты созданы, какие задачи в Яндекс Трекере связаны и остались ли неразобранные падения.

В этом примере результат получился такой:

• обработано failed/broken unresolved: 29;

• созданы дефекты: 1279-1287;

• созданы и связаны задачи: CMA-9551 - CMA-9559;

• неразобранных результатов осталось: 0;

• у дефектов есть matcher;

• все 29 test results привязаны к своим дефектам;

• задачи в Tracker получили нужные поля: команда, компонент, тип, приоритет и тег autoapi.

Что дальше

Сейчас я активно дорабатываю skill, чтобы он подходил под разные команды и разные компоненты, а не только под один заранее описанный маппинг.

Следующий логичный шаг — сделать AI-агента, который будет проходиться по упавшим автотестам всех команд, разбирать результаты, заводить дефекты и задачи, настраивать matcher-правила и оставлять человеку только проверку спорных случаев.

Идеальная картина для меня выглядит так: автотесты упали, агент сам разобрал запуск, сгруппировал причины, отделил продуктовые баги от проблем тестов и данных, создал нужные дефекты и Tracker-задачи, а QA утром видит уже не хаос из красных тестов, а понятный список причин и действий.

Полностью убирать человека из этого процесса нельзя. Но снять большую часть рутины — уже вполне реально.

Короткий итог

Дефекты в TestOps нужны не для галочки. Они помогают сделать базу падений управляемой, не плодить дубли и не разбирать одни и те же ошибки после каждого запуска.

Matcher-правила превращают дефект из ручной отметки в механизм автоматической привязки повторяющихся падений. Интеграция с Яндекс Трекером связывает автотесты с разработкой. А MCP + Cursor AI / Claude Code позволяют автоматизировать большую часть рутины вокруг failed/broken результатов.

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

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