Группировка ошибок и анализ причин падений (RCA) с помощью ИИ

Последние годы стали серьёзным испытанием для тестирования.

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

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

В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.

1. Анализ падений с playwright-ai/auto-debug

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

Чтобы это увидеть, запущу несколько тестов на JS-Playwright и проанализирую их с помощью Playwright-ai/auto-debug (инструкция по настройке инструмента здесь, сам пример — тут).

Тестировать буду простой компонент — баннер:

<div class="promo-banner" data-testid="promo-banner"><span>Я - тестовый баннер. Приятно познакомиться!</span><button data-testid="promo-banner-quit" aria-label="Close">&times;</button></div>

К нему будет два теста: на то, что кнопка закрытия баннера видна, и на то, что она работает. Оба теста обязательно будут падать:

test("the banner close button on the home page is visible", async ({ page }) => {  await page.goto(new URL("./fixtures/home.html", import.meta.url).href);  await expect(page.locator('[data-testid="promo-banner-close"]')).toBeVisible();});test("the banner on the homepage can be closed", async ({ page }) => {  await page.goto(new URL("./fixtures/home.html", import.meta.url).href);  await page.locator('[data-testid="promo-banner-close"]').click();  await expect(page.locator('[data-testid="promo-banner"]')).toBeHidden();});

Падать они будут из-за того, что я поменял имя локатора с promo-banner-close на promo-banner-quit, а исправить тесты «забыл». Что скажет нейросеть?

Запускаю тесты:

npm test

Запускаю ИИ-анализ:

npx playwright-ai debug

Получаю два разных отчёта. По тесту на закрытие:

Локатор [data-testid="promo-banner-close"] не найден на странице. Возможные причины: 1. Баннер не отображается сразу после загрузки страницы (нужно ждать его появления) 2. Неправильный data-testid в HTML 3. Баннер скрыт по умолчанию (например, через CSS)

Гипотез много — одна из них даже оказалась правильной. Теперь по тесту на видимость:

Причина ошибки: Локатор [data-testid="promo-banner-close"] не найден в DOM за 5 секунд. По снимку видно, что кнопка закрытия баннера имеет текст «×» и атрибут [cursor=pointer], но не имеет data-testid.

Проблемы: 1. Локатор по data-testid неверен (отсутствует в HTML). 2. Лучше использовать уникальный селектор по тексту кнопки или другим атрибутам.

Здесь нейросеть почти попала в точку (data-testid у кнопки есть, просто неправильный). Посидев немного, я бы разобрался, в чём причина.

Чего не дал здесь ИИ? У него не было возможности сгруппировать разные падения вокруг одной причины; в результате, как и при ручном разборе, время анализа приходится умножать вдвое. На эту проблему обращают внимание в современных исследованиях на тему анализа причин ошибок (RCA, root cause analysis).

2. Существующие эксперименты по группировке падений

Сейчас ставится множество экспериментов по RCA с нейросетями, и один из важных этапов в таких пайплайнах — группировка падений.

Иногда эта группировка проводится с помощью ИИ:

• GPTrace: в этой статье нейросеть оценивает сходство данных об ошибках, используя их векторное представление.

• FlakyCat: это — старый (2022) эксперимент по категоризации флаки-тестов.

• Есть и коммерческие решения, выполняющие классификацию падений.

Однако обычно нейросети подключают уже на этапе анализа обнаруженного кластера багов; собирают же баги в кластер более классическими методами.

• [BuildSheriff]: интересный подход, сопоставляющий падения с недавними изменениями в коде. Сходство падений рассчитывается по заданным исследователями критериям.

• LogSage: академический прототип, внедрённый в ByteDance. Здесь на подготовительном этапе (сравнение и очистка логов) также используются алгоритмы, основанные на сходстве.

Можно предположить, что при переходе от экспериментов к коммерческим решениям особенно яркими красками заиграет фактор цены, и выполнять подготовку данных нейросетями обычно дороже, чем алгоритмически. Например, в упомянутом GPTrace (созданном в этом году) создание векторов на 300 тысяч результатов с помощью модели от OpenAI заняло около 10 часов.

Кроме того, нужно учитывать, что при переходе к реальным решениям модели будут работать не с одним набором данных, а со множеством итераций (для каждого запуска). И один из ключевых вопросов при анализе — является ли падение новым или с этой проблемой уже сталкивались раньше, то есть каждый раз нужно будет поднимать исторические данные. Чтобы контекстное окно модели не было перегружено, обязательно нужны дедупликация, сортировка и сокращение данных.

3. Существующая инфраструктура по подготовке тестовых данных

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

В статье 2026 года проводится анализ причин падения (RCA) на основе логов, сообщений об ошибках и стек-трейсах, извлечённых из json-файлов Allure Report. Авторы пишут:

Структурированный характер данных Allure Report сильно упрощает задачи на этапе предварительной обработки, поэтому этот инструмент — прекрасный источник данных для ML-моделей.

Что здесь важно:

• В Allure данные из разных фреймворков приведены к единому формату, поэтому обрабатывать их гораздо проще

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

  Благодаря интеграции структурированных (XML и JSON) и частично структурированных (логи и сообщения) данных Allure Report — отличный выбор для обучения ИИ-моделей.

• В отчётах записан не только текущий, но и прошлый запуск.

Помимо этого, в Allure Report есть свой механизм автоматической группировки падений. По умолчанию он сортирует падения по сообщениям об ошибках. Конечно, если сообщения об ошибках одинаковые, это ещё не значит, что причины падений одинаковые. Тем не менее, такая группировка облегчает дальнейший анализ — и человеку, и нейросети.

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

4. Вывод

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

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