Эпопея в трёх частях: ИИ-инструменты в работе QA. Практическое применение Cursor, n8n и LLM

Введение

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

В нашей команде это особенно проявилось после реструктуризации: в зоне моей ответственности оказалось около 40 сервисов. Приходится глубже разбираться в устройстве системы, понимать, как двигаются данные между сервисами на более низком уровне, — документации и регламентов уже недостаточно.

Нагрузка растёт: через Mattermost и другие каналы коммуникации постоянно приходит всё больше обращений от поддержки и пользователей. Даже при наличии документации и регламентов важная информация всё чаще сначала появляется в переписке, а не в формальных артефактах. В такой среде ИИ — это хороший помощник, который позволяет QA обрабатывать больший объём информации быстрее.

Битва за качество

Чтобы понять, в каком состоянии сегодня находится типичный отдел тестирования, достаточно вспомнить одну эпичную сцену из Marvel.

Разберёмся, как эти инструменты реально помогают команде.

Часть 1. Cursor — когда требований нет, но надо тестировать

Классический сценарий из практики. Из Mattermost прилетает тикет от ТП: «В CRM-виджете отправки письма в поле „Кому“ (селект с выпадающим списком) путаются роли преподавателей: основной и замещающий. Менеджеры не понимают, кому именно уйдёт письмо».

Проблема: чтобы воспроизвести и понять, баг это или фича, нужно разобраться, как работает логика. Документации нет, или она устарела. Остаётся:

• исследовательское тестирование (долго и не факт, что найдёшь);

• обратиться к разработчику, чтобы тот посмотрел, как работает фича на уровне кода.

Как я работаю с Cursor

Вы наверняка знаете, но я напомню: Cursor это форк VS Code с ИИ на уровне ядра. Ключевая фишка — RAG по всему репозиторию. Cursor индексирует проект и понимает связи между сервисами.

Как он можем помочь с анализом бага в CRM-виджете:

Шаг 1. Открываем консоль браузера → Inspect Element на проблемном селекте → копируем HTML.

Шаг 2. Открываем репозиторий фронтенда приложения → вставляем в Cursor точный запрос:

«На странице в поле отправки письма находится селект с выбором «Кому». Там есть Преподаватель и Временный преподаватель. Можешь показать, откуда тянутся данные и как фронт определяет, выводить „преподаватель“ или „временный преподаватель“?»

Прикрепил HTML-селект.

Ответ Cursor:

Данные → компонент mail-compose-message → метод optionsService

Логика фронта:

teacherId = основной преподаватель

mainId + replacedId = оба преподавателя

Проблема: фронт проверяет наличие teacherId, игнорируя поле type: primary/temporary из API

{ "teachers": [ { "id": "...", "teacherId": "...", "replacedTeacherId": "...", "type": "temporary", "createdAt": "2025-06-01T14:33:13+00:00", "updatedAt": "2025-06-01T14:33:13+00:00" }, { "id": "...", "teacherId": "...", "replacedTeacherId": null, "type": "primary", "createdAt": "2025-04-02T14:05:23+00:00", "updatedAt": "2025-04-02T14:05:23+00:00" } ] }

Результат для QA

Cursor даёт больше информации о том, как работает сейчас функциональность тем самым повышает вашу экспертизу. У вас больше контекста для того, чтобы воспроизвести проблему и более точно описать баг-репорт.

Что даёт на деле:

• На естественном языке понимаете бизнес-логику, которая не была вынесена в документацию.

• Можете сами создать актуальную документацию или обновить старую.

• Идёте к разработчику не с вопросом «Почему сломалось?», а с конкретной гипотезой по коду.

• Воспроизводите баги в тестовой среде — знаете точные данные и сценарии.

Реальный результат: QA сам разбирается в архитектуре и может документировать фичу.

А при хороших технических навыках можно даже принести баг с уже готовым техническим решением:

QA принёс на груминге тех. решение:

Часть 2. n8n — автоматизация рутинных задач

Если с Cursor мы разбираем код и понимаем, как всё работает, то в n8n мы помогаем себе с рутиной. Это low-code-платформа для автоматизации воркфлоу, которую можно развернуть внутри своего контура (self-hosted).

Тестировщик, как правило, взаимодействует с разными сервисами:

• задачи в Jira,

• корпоративные мессенджеры,

• GitLab,

• TMS cистемы и т.д.

n8n — low-code платформа, которая умеет работать с сервисами по API (на текущий момент доступно более 400 официальных интеграций).

С его помощью можно:

1. Строить надежные автоматизации на базе классических алгоритмов (HTTP-запросы, вебхуки, Cron).

2. Создавать автономных ИИ-агентов для интеллектуальной обработки данных между системами.

Кейс 1. BugMan — агент Скотт Лэнг

Проблема: в тредах обсуждений багов может быть 50+ сообщений, внутри которых лежат полезные логи и скрины. QA вручную агрегирует всю важную информацию и оформляет баг-репорт.

Решение: n8n-агент с инструментами для взаимодействия с сервисами.

• Готовая Mattermost-нода — сразу тянет треды по API.

• HTTP-нода — кастомные запросы к любым сервисам.

• Мой подход: отдельный workflow для получения тредов (модульность + переиспользование), который агент вызывает как tool.

Как это работает:

1. Агент получает от пользователя ссылку на тред → tool get_info_thread_mattermost.

2. Парсит все признаки баг-репорта: шаги воспроизведения, expected/actual, логи, скрины, id проблемных юзеров. Здесь очень важно корректно описать промпт агенту.

3. LLM заворачивает баг-репорт в Jira Wiki Markup.

4. Создаёт в нужном проекте задачу с типом Bug.

Кейс 2. QA-tab — агент Стив Роджерс

Стандартный процесс: разработчик завершает задачу → двигает её в Ready for Test → QA начинает тестирование.

Проблема: описание в задаче может быть неточным или недостаточным, QA не понимает весь объём изменений и рисков.

Решение: агент Стив Роджерс автоматически готовит промпт для Cursor. Мы всё так же создаём агента в n8n, прописываем ему промпт и доступ к нужным tools:

1. Jira-задача → анализ требований.

2. GitLab MR → анализ изменений git diff.

3. Формирует структурированный промпт:

   1. Требования из Jira: [текст задачи].

   2. В этой MR изменены файлы X, Y, Z [git diff].

Сам воркфлоу в n8n агента для формирования промпта из контекста сервисов:

1. Мы отправляем агенту в чат ключ задачи Jira и получаем промпт для Cursor с готовым контекстом:

2. Проверяем промпт и копируем его.:

3. Вставляем промпт в Cursor и получаем суть изменений бизнес-логики.

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

Часть 3. Open WebUI

Для работы с агентами n8n и другими LLM (облачными или локальными) нужен удобный интерфейс. Встроенный чат n8n подходит для простых случаев, но для масштабирования на отделы требуется система с администрированием.

Решение: Open WebUI — self-hosted-интерфейс с поддержкой любых моделей.

Преимущества:

• подключение локальных и облачных LLM;

• удобное администрирование пользователей и моделей;

• вебхуки для интеграции с n8n;

• community-решения для сложных интеграций.

Интеграция: n8n ↔ Open WebUI через вебхуки и кастомные скрипты.

Результат: единый интерфейс для всех агентов с централизованным управлением.

Логика настройки:

В n8n: создаем workflow, начинающийся с ноды Webhook (метод POST):

Обработка: внутри воркфлоу настраиваем цепочку действий (например, вызов LLM-агента):

Ответ: в конце обязательно ставим ноду Respond to Webhook:

Интеграция реализуется через кастомный скрипт на стороне Open WebUI, который пробрасывает запросы в вебхуки n8n. За основу взято решение из Community Open WebUI:

Найди данный скрипт можно по адресу: https://openwebui.com/search

В Open WebUI: прописываем URL нашего вебхука в настройках функции:

Инструментарий — не догма: выбирайте то, что решает ваши боли

В n8n можно собирать агентов под свои задачи или использовать другие инструменты автоматизации.Сейчас QA чаще всего используют ИИ для решения задач:

• сбор и анализ требований;

• создания тест-кейсов и чек-листов;

• написания автотестов.

Я фокусируюсь на том, что отнимает больше всего времени, и шарю наработки с коллегами. Не обязательно использовать только инструменты, о которых я рассказал в статье — можно и своё что-то собрать.

Недавно я создал мини-рекордер: он записывает все действия в браузере (API-запросы, локаторы, URL) и формирует промпт для Cursor. Тот смотрит на код фронтенда и бэкенда проектов и генерит точный тест-кейс.

Подводные камни и best practices

Галлюцинации и проверка

ИИ не замена QA-инженера, а что-то вроде стажёра. Он может уверенно придумать несуществующий эндпоинт или параметр.

Best practice №1. Никогда не копируйте результат ИИ бездумно. Всегда проверяйте, что он возвращает.

Prompt Engineering

Успех почти полностью зависит от системного промпта. Не пишите «сделай чек-лист». Пишите по структуре:

• Role. Кто он?

• Context. Что мы тестируем?

• Instruction. Что сделать?

• Output. В каком виде?

• Rules. Чего делать нельзя?

Очень хорошо описывают как работать с галлюцинациями Anthropic: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations

Заключение

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

• n8n даёт хороший старт в автоматизации: то, что раньше съедало часы, теперь занимает 10 минут. Вы можете самостоятельно выстраивать воркфлоу для взаимодействия с нужными системами.

• Open WebUI даёт удобный интерфейс для взаимодействия с LLM.

Главное: ИИ не заменяет QA — он делает работу эффективнее. Если вы знаете архитектуру, умеете в тест-дизайн и понимаете бизнес-логику, эти инструменты только принесут вам пользу. Без экспертизы это просто дорогой калькулятор.