SavePearlHarbor

Отдали рутину боту: работа с тест-кейсами теперь на n8n

—

от автора

admin

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Недавно мы вчетвером с QA-командой  нашли способ оптимизировать нашу работу и сэкономить время на написание тест-кейсов и чек-листов с помощью автоматизирующего рутину бота. На всю разработку у нас ушло около двух недель, а в продакшене бот живёт с апреля 2026 года. Расскажу, как мы это сделали и какие результаты получили в итоге. 

Почему мы решили делегировать свою работу бездушной железке?

Как вообще выглядит работа тестировщиков в нашей команде – а конкретно написание тест-кейсов? 

Когда прилетает новая задача, тестировщику нужно вручную перелопатить документацию в Confluence, продумать возможные сценарии проверки, описать их по регламенту в Allure TestOps, добавить чек-листы и в конце все это прилинковать к Jira. 

Это нудная, рутинная работа, отнимающая много времени. Еще и человеческий фактор сказывается: человек устал, забыл, выпал из контекста – может у него пятница или голова кругом после десятого митапа за день. В итоге на один тест-кейс уходило до 1,5 часов, которые можно было бы использовать с большей пользой. 

И вот мы подумали, почему бы не отдать эту работу ИИ. Так и решили написать бота для автогенерации тест-кейсов и чек-листов на n8n.

Бот изнутри: архитектура сервиса и скиллы

Для формирования ТК, бот обращается к 4 сервисам:

  • в Jira берет задачи и комментарии, 

  • в Confluence – документацию, которая дает контекст для ИИ,

  • Claude AI (через LiteLLM) генерирует сами ТК и чеклисты,  

  • в Allure TestOps импортирует результат. 

Чтобы связать это все воедино, нам понадобилось составить в n8n воркфлоу из 68 нод – так много, потому что на каждом этапе можно столкнуться с каким-то багом, ошибкой, отсутствием ссылок, просроченным токеном для Claude, отвалившимся Allure… В общем, проблем может быть очень много. Они все вынесены в ветки, которые эти проблемы решают.

Это сложная структура, и кода в ней очень много – почти 2000 строк. Чтобы сэкономить время и быстро получить адекватный, рабочий воркфлоу, мы подключили модель Claude Sonnet 4.6 и работали через OpenCode. Конечно, для такой большой задачи одним промптом «напиши мне воркфлоу как спец с 80-летним стажем» не ограничишься, поэтому мы использовали готовые скиллы (https://github.com/czlonkowski/n8n-skills):  

  • n8n-skills – базовый гайд по созданию нод, 

  • n8n-workflow-patterns регулирует архитектурные паттерны и формирует структуру воркфлоу целиком,

  • n8n-node-configuration отвечает за точную настройка параметров нод: Jira, HTTP, Schedule,

  • n8n-code-javascript – за весь синтаксис JS внутри воркфлоу,

  • n8n-expression-syntax – за выражения {{ }}, регулирующие передачу данных между нодами

  • n8n-validation-expert – за разбор багов и ошибок валидации JSON и конфигурации нод.

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

Как научить Claude писать, как QA?

Самое интересное во всём этом – даже не воркфлоу, а промпт для Claude. Если просто попросить «напиши тест-кейсы по этой задаче», получится академический мусор: «проверить корректность работы метода», «убедиться в валидности данных». Толку от такого тест-кейса – ноль, его всё равно придётся переписывать с нуля.

 Чтобы Claude писал, как наш QA, мы пошли через подход few-shot prompting. Если по-простому – даём модели не свод правил, а несколько живых примеров из прода. Глядя на них, она понимает, чего от неё хотят, и повторяет наш стиль практически без отклонений.

Внутри промпта для тест-кейсов 7 блоков:

1. Стандарт названия – формат /endpoint — [Сценарий] плюс примеры из реальных ТК.
2. Стандарт описания – что писать, зачем нужна ссылка на Confluence, готовый шаблон.
3. Стандарт предусловий – какие данные в БД, тоглы, статусы клиента.
4. Стандарт шагов – формат «действие → ожидаемый результат».
5. Правила генерации – сколько ТК (8-12), какие типы (happy / negative / validation / edge), в каких пропорциях.
6. Три полных production-примера – happy path, negative, validation в JSON.
7. Выходной формат – строго JSON, без markdown-обёрток.

Вот как выглядит блок «Стандарт названия»:

СТАНДАРТ НАЗВАНИЯ

Формат для API: /endpoint - [Описание сценария]
Примеры из продакшена:
✅ "/applicationProcessDeposit - Обработка зависших заявок на депозит"
✅ "/confirmCourierMeeting - Создание встречи при несуществующем userId"
✅ "/depositAccount - Запрос реквизитов клиента по leadId с активным договором"

Для негативных:
/endpoint - [Действие] при [неправильное условие]
✅ "/confirmCourierMeeting - Создание встречи при несуществующем userId"

А вот один из production-примеров целиком – Claude видит его как образец и копирует структуру:

{
  "name": "/depositAccount - Запрос реквизитов клиента по leadId с активным договором",
  "description": "Тест-кейс позволяет проверить корректность работы метода при успешном получении реквизитов клиента.\n\n[Документация /depositAccount](https://wiki.company.local/pages/viewpage.action?pageId=18944483)",
  "preconditions": "Создана депозитная заявка и подписан договор, например для банка Синара.",
  "steps": [
    "Отправить POST /depositAccount с leadId активного договора → Код ответа 200",
    "Проверить наличие полей accountNumber, bik, bankName в теле ответа → Все поля присутствуют и не пустые",
    "Проверить запись в таблице midb.deposit_account → Запись соответствует ответу API"
  ],
  "expectedResult": "Метод возвращает корректные реквизиты клиента с кодом 200"
}

Под каждую новую задачу мы собираем юзер-промпт. Туда подкладывается ключ родительской задачи, summary, описание, содержимое Confluence (если бот его нашёл) и ключ подзадачи. В конце – короткая инструкция:

Сгенерируй 8-12 тест-кейсов:
- 2-3 happy path
- 3-4 negative (несуществующие ID, отсутствие параметров, неправильные статусы)
- 2-3 validation (обязательность полей, форматы, границы)
- 1-2 edge cases

Используй НАШИ стандарты из примеров выше!

С чеклистами история похожая, но проще. Они короче, постятся прямо в комментарий к подзадаче в Jira, поэтому на выходе нужен не JSON, а Jira wiki markup с заголовками:

ФОРМАТ ОТВЕТА (Jira wiki markup):

h2. 🧪 QA Чеклист: [Название функционала из задачи]

h3. ✅ Основной сценарий (Happy Path)
* [Действие с конкретными данными] → [Ожидаемый результат]

h3. ❌ Негативные сценарии
* [Невалидные данные] → [Конкретная ошибка из документации]

h3. 🔢 Граничные значения
* [Поле] = [значение из документации] → [результат]

h3. 🔌 API проверки
* [METHOD] [endpoint из документации] с [параметры] → [статус], [ответ]

И главное в этом промпте – пара примеров «плохо / хорошо». Без них чеклист скатывался в общие фразы вроде «проверить валидацию». С ними Claude вытаскивает конкретные суммы, имена полей, коды ошибок прямо из документации Confluence:

ПЛОХО (абстрактно):
* Проверить валидацию входных параметров
* Эндпоинт возвращает корректный ответ

ХОРОШО (конкретно):
* POST /api/v1/deposits с amount=0 → ошибка 400 «Сумма должна быть больше 0»
* Создать депозит с минимальной суммой 10000₽ → депозит создан, статус ACTIVE

В сухом остатке: и для тест-кейсов, и для чеклистов работают три вещи в связке – жёсткий формат на выходе, несколько живых примеров из прода и подгруженный контекст из Confluence. Если убрать любой из трёх компонентов, качество падает в разы.

Как это теперь работает и что дает в итоге

Итак, бот готов. Что теперь с ним делать тестировщику? 

  1. Когда поступает новая задача в Jira, нужно создать в ней подзадачу.

  2. В подзадаче поставить статус «В работе» и метку need-tc, если нужен тест-кейс, или need-checklist, если чеклист, – так бот поймет, что это для него. 

  3. Подождать 10 минут и наслаждаться результатом.

Внутри воркфлоу в это время задействуются несколько нод: 

  1. Schedule Trigger запускается каждые 8 минут и проверяет, есть ли для него работа.

  2. Search Jira отбирает задачи в проекте, где стоят нужные метки и статусы.

  3. Get Parent Issue читает родительскую задачу, а Confluence: Get Content подтягивает данные ссылок в описании. 

  4. Build Prompt собирает контекст и пишет промпт для Claude AI (LiteLLM), который генерирует кейсы и чеклисты по уже загруженным в него регламентам.

  5. Parse + Upload CSV парсит ответ и отправляет ТК в Allure.

  6. Tag + Move to AI-Generated добавляет метку generated, ставит статус «Сгенерирован» и складывает кейсы в папку AI-Generated, чтобы Schedule Trigger не взял эти задачи в работу повторно. 

  7. Bulk Link to Jira привязывает ТК к родительской задаче.

  8. Comment + Update Labels добавляет комментарий со ссылками и меняет метку need-tc на tc-generated либо need-checklist на checklist-generated.  

В результате этой работы создается пачка из 8-12 тест-кейсов: happy path, негативные сценарии, валидация, граничные значения вроде отсутствующих полей JSON и так далее. Все описаны по нашему регламенту и прилинкованы к своим задачам.

Такой кейс QA берет в работу, вручную проверяет описанные сценарии, добавляет скрины из логов и либо меняет статус на «Активный», либо передает ТК коллегам-тестировщикам на ревью. Его, кстати, удобно скормить ИИ, чтобы он прогнал некоторые тесты сам. 

Чеклисты генерируются отдельно от ТК и отправляются в комметарии к подзадаче.

Итоги

Бот работает в продакшене с апреля 2026 года.

За это время:

• Время на один тест-кейс сократилось с 1,5 часов до 10 минут от метки до готового драфта в Allure.
• 40% сгенерированных ТК уходит в работу после минимального ревью – поправить значение, добавить специфичный шаг , приложить фото результата.

Что не работает:

• Сложная многошаговая бизнес-логика с большим контекстом (5+ страниц Confluence ~40K символов ) – нужно дописывать вручную.
• Тест-кейсы на UI со скриншотами – генерация только текстовая.
• Performance- и нагрузочные сценарии – здесь LLM пока бесполезна.

Что планируем дальше:

• Интеграция с git diff – чтобы при коммите кода в PR Claude видел изменения и предлагал ТК именно на изменённую логику.

Спасибо что прочитали статью, буду рад пообщаться в комментариях!

ссылка на оригинал статьи https://habr.com/ru/articles/1045336/