Всем привет! Я Марго, QA-инженер команды МС в Банки.ру. 

Этой весной мы с командой автоматизировали подготовку Acceptance Criteria (это по сути такой чек-лист, по которому команда проверяет, готова ли задача) с помощью ИИ. Это сократило рутинную работу и ускорило тестирование. Ниже расскажу, как мы это сделали.

Что такое Критерии приемки?

Критерии приемки (Acceptance Criteria или AC, как я дальше буду их называть) – это по сути чек-лист, по которому команда проверяет, готова ли задача. В нем описываются как основной пользовательский сценарий (Happy Path), так и нестандартные ситуации (Edge Cases), которые система тоже должна корректно обработать.

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

• HP (Happy Path): Клик на «Узнать рейтинг» → успешный ответ от БКИ, пользователь видит свой балл (например, 750).

• EC (Edge Case): Шлюз БКИ недоступен (таймаут) → пользователь видит заглушку «Сервис временно недоступен» и кнопку обновления.

До апреля этого года наш пайплайн выглядел так: задача проходила через этапы аналитики, дизайна макетов, груминга, разработки и код-ревью – и только после этого, в самом конце подключался QA и начинал собирать контекст, что надо было сделать и что получилось. Недавно мы решили пересмотреть процесс в рамках подхода «Встроенное качество» (Shift Left), который активно внедряется у нас в компании. После перехода на Shift Left, QA стал подключаться еще до груминга и успевает заранее разобраться в требованиях.

Однако подготовка AС по-прежнему оставалась самой трудоемкой частью процесса:

• Вспомнить обсуждение на груминге;

• Перечитать описание задачи в Jira;

• Просмотреть Confluence и макеты в Figma;

• Найти важные уточнения в комментариях;

• Сформулировать Happy Path и Edge Cases.

Эту рутинную часть мы решили автоматизировать. Моя коллега Марина Арутюнян написала скилл, который формирует список AC и отдает QA на валидацию.

Алгоритм работы скилла

Весь процесс можно поделить на 4 этапа.  

1 этап – сбор контекста

В Jira и Confluence скилл подключается через другие скиллы: мы выбрали такой вариант потому что он позволяет корректно читать данные – MCP-сервера грешат тем, что иногда ломают верстку. К Figma он подключается через Desktop MCP, потому что в нем нет ограничений на количество запросов в минуту. 

В этих источниках он читает все описания, обсуждения и собирает релевантные данные. 

2 этап – подготовка Acceptance Criteria

ИИ анализирует полученные данные, выделяет важное, помечает устаревший контекст, задает вопросы. К каждому AC добавляет обоснование, почему он добавил эти критерии. 

Это выглядит вот так:

3 этап – валидация у QA

ИИ не публикует результат автоматически, а передает QA на ревью список, где указывает тип критерия (Happy Path или Edge Case), описание и вид артефакта: 

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

4 этап – сохранение в задаче

 После утверждения AC публикуются в нужном формате в Jira нативно через REST API.

Генерация AC выполняется на Claude Sonnet. Средняя стоимость обработки одной задачи составляет около $1.

Что мы получили на практике

Новый подход внедрили в апреле, и уже увидели измеримые результаты.

• Очередь на тестирование движется быстрее: время ожидания сократилось с 14,3 часов до 2,6 (в 5,5 раз).

• Время тестирования сократилось с 13 до 2 часов (в 6,5 раза).

• Благодаря четким ТЗ, которые разработчики получают на старте, число задач с лейблом no_test выросло в 2 раза (разработчики тестируют задачи сами, опираясь на критерии).

• 78% задач покрыты ИИ-сгенерированными AC. Остальные 22% – это задачи без изменения бизнес-логики, которые не требуют AC. На них ставится лейбл skip_AC, чтобы скилл их пропустил. 

Мы не собираемся на этом останавливаться и планируем и дальше улучшать процесс. В частности, в вопросе автоматизации АС. Сейчас скилл запускается QA-инженером локально. Мы планируем встроить его в платформы автоматизации (n8n или Dify), чтобы AC генерировались автоматически до груминга.

Выводы

Подводя итог, можно сказать, что главным результатом для меня, как для QA, стало освобождение времени. Раньше я тратила его на механическое перечитывание Jira, Confluence и комментариев, пытаясь просто вспомнить контекст. Теперь это время я трачу на то, что проверяю, не упустил ли ИИ неочевидный Edge Case, и дорабатываю логику там, где без человеческого опыта не обойтись.

И чтобы высвободить еще больше ресурсов, мы уже заглядываем в будущее: внедрить систему лейблов на основе матрицы рисков, используя подход БЭМ (Блок-Элемент-Модификатор) из верстки. Идея в том, чтобы скилл при формировании AC сам анализировал необходимые данные, определял, какие блоки и элементы продукта затронуты, и проставлял соответствующие метки. Тогда QA с первого взгляда будет видеть зоны повышенного внимания и понимать, что необходимо обязательно проверить самостоятельно.

На текущем этапе я уверена в одном: Shift Left с поддержкой ИИ – это тот самый роскошный максимум, о котором мы раньше только мечтали, а теперь он наша реальность! Это делает работу не просто быстрее, а правда осмысленнее, интереснее и легче! ?