Работа QA после поддержки с ИИ-агентомИсследование, описание и документирование через MCP и скиллы
Оптимизируем один шаг цепочки: QA после поддержки. Агент через MCP воспроизводит баг из Jira на тестовом стенде, сжимает путь, описывает и документирует, скилл делает шаги повторяемым процессом, QA проверяет руками. Поддержка и разработка не меняются.
Баг от клиента проходит поддержку и попадает к QA. Здесь вручную исследуют, описывают и документируют, поэтому оптимизируем именно этот шаг. Агент с подключением к Jira и тестовому стенду через MCP и скилл с записанными шагами берут рутину на себя. QA проверяет результат руками. Поддержка и разработка работают как раньше.
В этом примереМеняется только шаг QA: раньше всё время уходило на выполнение задач, теперь агенты выполняют, а QA принимает результат и управляет агентами.
В общем случаеАгентов можно запускать много, время QA на одну задачу падает.
агент · PAY-142агент · PAY-143агент · PAY-144время QA уходит на управление и приёмку
Каждая из трёх частей идёт у агента по каждому багу отдельно, а QA запускает их сразу несколько.
Вывод
В этом примереИсследование, описание и документирование идут подряд и проходят через агента. У QA остаётся проверка итога и спорные места.
В общем случаеВсе три части — повторяемые действия с понятным результатом, поэтому их можно записать и отдать. Решение «это баг или нет, и насколько он важен» остаётся за человеком.
Что сделатьРазделите свою работу над багом на эти три части и отметьте, какая отнимает больше всего времени.
MCP: агент работает там же, где работает QA
MCP (Model Context Protocol) — способ подключить агента к рабочим системам, чтобы он читал и писал в них сам, а не получал пересказ.
В этом примереЧерез MCP агент читает PAY-142 в Jira, идёт на тестовый стенд, пишет туда же результат. QA не копирует ничего между окнами.
В общем случаеБез подключения к системам агенту приходится давать пересказ, а пересказ теряет детали. Тестовый стенд нужен как место, где агент может пробовать и ломать, не задевая прод.
Что сделатьНачните с двух подключений: Jira и тестовый стенд. Остальное добавляйте по мере надобности.
Скилл: записанный процесс вместо повторения руками
Скилл — записанный для агента способ работать: шаги, шаблон отчёта, правила. Его повторит другой человек и другой агент.
агент · PAY-142агент · PAY-143агент · PAY-144время QA уходит на управление и приёмку
Скилл один, запусков много: по агенту на каждый баг. Записанный процесс не требует, чтобы QA повторял его сам.
одни шаги каждый разединый шаблон отчётапередаётся коллегамдорабатывается по ошибкам
Вывод
В этом примереШесть шагов записаны один раз. Любой QA запускает скилл на новой задаче и получает отчёт в том же формате.
В общем случаеСкилл превращает «как я обычно делаю» в процесс, который не зависит от того, кто сегодня на смене. Ошибка агента попадает в скилл как новое правило, и в следующий раз её нет.
Что сделатьЗапишите свои шаги над одним типом багов как скилл и прогоните на трёх закрытых задачах.
Один QA — несколько агентов: время уходит на управление и приёмку
Воспроизводить баги можно разными каналами, и каждый агент берёт свой.
В этом примереQA запускает агентов на PAY-142, PAY-143 и PAY-144 сразу. Пока они работают, QA не сидит над одним багом, а по очереди проверяет готовые результаты.
В общем случаеРаньше время QA складывалось из всех багов подряд. Теперь за каждый баг отвечает свой агент: браузерный, по коду или через API, а у QA остаётся только короткая проверка. Чем больше агентов запущено, тем больше времени QA уходит на управление ими и проверку, а не на рутину.
Что сделатьНаращивайте число агентов постепенно: оно упирается в число стендов, тестовых данных и лимитов. Время, которое QA больше не тратит на рутину, направляйте на управление агентами, проверку и доработку скилла.
Пример: PAY-142 от задачи до отчёта
Задача в Jira · обращение клиента, переданное поддержкой в QA
PAY-142 · Не проходит оплата картой, если ввести промокод
от клиентапередана поддержкойбез шаговскриншот ошибки
Исследование: было 6 действий → осталось 3
входкаталогадрескорзинапромокодоплата картой
Сжатие: агент по одному убирает действия и после каждого проверяет, воспроизводится ли баг. Без чего баг остаётся, то вычёркивается.
Схема по запросу · sequence
Описание и запись в Jira · комментарий к PAY-142
Шагикорзина → промокод → оплата картой
Ожидалосьплатёж проходит со скидкой
Получилось«платёж не прошёл», у сервиса промокодов ошибка 500
Где искатьвызов сервиса промокодов из оплаты (см. схему)
Один QA — несколько агентов сразу
агент · PAY-142агент · PAY-143агент · PAY-144время QA уходит на управление и приёмку
Пока агент разбирает PAY-142, другие агенты берут PAY-143 и PAY-144, а QA проверяет то, что уже готово.
Задача и все названия выдуманы для примера.
Вывод
В этом примереИз одной строки клиента получились короткий путь из трёх действий, схема и готовый отчёт в Jira. QA сам этого не делал, он смотрит результат.
В общем случаеКаждая из трёх частей работы QA оставила видимый след: сжатый путь, схему, запись. Так результат можно проверить за минуты, а не восстанавливать по памяти.
Что сделатьПопросите агента показать сжатый путь и запись: по ним сразу видно, пошёл ли он не туда.
агент · PAY-142агент · PAY-143агент · PAY-144время QA уходит на управление и приёмку
Время, которое QA больше не тратит на рутину по каждому багу, уходит на управление агентами, проверку, приоритеты и улучшение скилла.
Вывод
В этом примереQA открывает стенд, повторяет шаги из отчёта сам и подтверждает, что баг тот, о котором писал клиент. Потом задача уходит разработчику как раньше; если не получилось, отчёт возвращается агенту.
В общем случаеМодель охотно подтверждает саму себя, а выдуманное выглядит как найденное. Поэтому последнее слово остаётся за человеком, который смотрит глазами. Работа QA смещается от выполнения рутины к проверке и улучшению процесса.
Что сделатьДоговоритесь: отчёт, который QA не смог повторить руками, не уходит разработчику.