За последние несколько лет роль 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 официальных интеграций).
С его помощью можно:
Строить надежные автоматизации на базе классических алгоритмов (HTTP-запросы, вебхуки, Cron).
Создавать автономных ИИ-агентов для интеллектуальной обработки данных между системами.
Кейс 1. BugMan — агент Скотт Лэнг
Проблема: в тредах обсуждений багов может быть 50+ сообщений, внутри которых лежат полезные логи и скрины. QA вручную агрегирует всю важную информацию и оформляет баг-репорт.
Решение: n8n-агент с инструментами для взаимодействия с сервисами.
Готовая Mattermost-нода — сразу тянет треды по API.
HTTP-нода — кастомные запросы к любым сервисам.
Мой подход: отдельный workflow для получения тредов (модульность + переиспользование), который агент вызывает как tool.
Как это работает:
Агент получает от пользователя ссылку на тред → tool get_info_thread_mattermost.
Парсит все признаки баг-репорта: шаги воспроизведения, expected/actual, логи, скрины, id проблемных юзеров. Здесь очень важно корректно описать промпт агенту.
LLM заворачивает баг-репорт в Jira Wiki Markup.
Создаёт в нужном проекте задачу с типом Bug.
Кейс 2. QA-tab — агент Стив Роджерс
Стандартный процесс: разработчик завершает задачу → двигает её в Ready for Test → QA начинает тестирование.
Проблема: описание в задаче может быть неточным или недостаточным, QA не понимает весь объём изменений и рисков.
Решение: агент Стив Роджерс автоматически готовит промпт для Cursor. Мы всё так же создаём агента в n8n, прописываем ему промпт и доступ к нужным tools:
Jira-задача → анализ требований.
GitLab MR → анализ изменений git diff.
Формирует структурированный промпт:
Требования из Jira: [текст задачи].
В этой 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 — он делает работу эффективнее. Если вы знаете архитектуру, умеете в тест-дизайн и понимаете бизнес-логику, эти инструменты только принесут вам пользу. Без экспертизы это просто дорогой калькулятор.
