Учёт регрессий QA

Что это за сервис

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

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

Что он делает

Сводит падения в структурированную таблицу. Каждое падение записывается с сервисом, тестом, серьёзностью и коммитом, по нему можно фильтровать и искать, а не листать лог.
Связывает регрессию с релизом. По хешу коммита регрессия привязывается к релизу, который её принёс, и к релизу с исправлением.
Контролирует, что исправление удержалось. Регрессия закрывается только после того, как тест проходит несколько релизов подряд, например два.
Назначает владельца автоматически. Новая регрессия уходит владельцу сервиса из каталога; сменить статус без владельца нельзя.
Блокирует релиз при критичных регрессиях. Пока связанная критичная регрессия открыта, релиз не получает статус «Одобрен».

Нюансы и особенности

Трекер не заменяет отчёты о тестах. Allure, отчёт CI или TestRail продолжают показывать результаты прогона. Трекер подключается к тем же данным и добавляет владельцев, сроки и связь с релизами. Если команда одна и каждое падение сразу становится задачей в трекере, отдельное приложение не нужно.
Нестабильный тест — не приговор. Тесту, помеченному нестабильным, дают отдельный статус и срок перепроверки, а не отключают навсегда. Анализ нестабильности как такового живёт в отдельном дашборде; здесь важно, чтобы метка «нестабильный» не прятала настоящую регрессию.
Результаты из CI, а не вручную. Шаг пайплайна после прогона отправляет результаты в JUnit XML или JSON. Повторная отправка того же прогона не создаёт дублей.
Зависшие регрессии эскалируют. Регрессия без движения больше пяти дней подсвечивается, критичная без обновления владельца дольше 48 часов уходит тимлиду. Пороги задают в конфиге.
Масштаб — через сохранённые представления. При сотнях наборов тестов у каждой команды своё представление по своим сервисам, общий список нужен только QA-лиду.
Блокировка релиза — правило, а не договорённость. Переход релиза в «Одобрен» проверяется на сервере. Исключение возможно только с причиной и записью в журнал.
Доступ. Разработчик меняет регрессии своих сервисов, QA-лид и релиз-менеджер — все.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

1. Данные и модели

Создай модели и миграции для учёта регрессий: Service (название,
владелец), TestCase (сервис, набор, имя), TestRun (прогон CI, коммит,
релиз, время), TestFailure (прогон, тест, сообщение), Regression (тест,
сервис, серьёзность, статус: новая, в работе, исправлена, подтверждена,
нестабильный тест; владелец, релиз появления, релиз исправления, число
успешных релизов после исправления), Release (версия, статус). Добавь
фабрики.

2. Таблица регрессий

Сгенерируй Filament-ресурс для Regression. В таблице покажи сервис, тест,
серьёзность, статус, владельца, релиз появления и дни без движения;
фильтры по сервису, серьёзности, владельцу и статусу, сохранённые
представления для команд. В карточке выведи историю падений теста
и связанные релизы.

3. Приём результатов из CI

Добавь эндпоинт для загрузки результатов прогона в формате JUnit XML
с проверкой токена. Сохраняй прогон идемпотентно по идентификатору
пайплайна. Новое падение ранее проходившего теста создаёт регрессию
с владельцем сервиса. Если тест с регрессией в статусе «исправлена»
проходит в двух релизах подряд, переводи её в «подтверждена».

Проверьте, что повторная загрузка того же прогона не создаёт новых регрессий.

4. Блокировка релиза и эскалации

Запрети переход Release в «Одобрен», пока есть связанная открытая
регрессия с серьёзностью «критичная»; исключение — только с причиной
и записью в журнал. Сделай задачу по расписанию: регрессии без движения
5 дней — уведомить владельца, критичные без обновления 48 часов —
уведомить тимлида.

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

5. Роли и сводка

Настрой роли: разработчик меняет регрессии своих сервисов, QA-лид
и релиз-менеджер — все. Добавь виджеты: открытые регрессии по сервисам
и серьёзности, повторно открытые за квартал и экспорт списка для
релизного совещания.