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