Содержание
Введение
Что такое MCP и зачем оно мне нужно (+ плагины и как подключать)
MCP Confluence
MCP Kaiten
MCP TestOps
MCP Postgres
MCP Chrome DevTools
MCP Playwright
MCP GitLab
MCP Mattermost
Общий процесс: тестирование эндпоинта (Гига Чад версия)
Заключение
Введение
Приветствую! Нравится нам это или нет, но нейросети с нами навсегда. Они уже доказали свою эффективность в определенных областях и с каждым днем продолжают расширять свою экспансию на другие области, становясь всё совершеннее. Наша же задача — попробовать не отставать от темпов развития и оставаться на острие технологий, чтобы вместе с ними меняться и осваивать новые подходы к работе.
В этой статье я расскажу тебе про перспективные подходы в использовании MCP связок для решения задач в области автоматизации тестирования, ручного тестирования и в целом QA области.
Дисклеймер
Это обзорная статья про возможности MCP-связок, а не пошаговый гайд по установке. Я исхожу из того, что у тебя уже установлен агент (например, Claude Code) и настроено рабочее окружение. Как подключать конкретный MCP — коротко покажу в следующем разделе, а детали установки каждого сервера лучше смотреть в его официальной документации. Дальше мы фокусируемся на том, что эти связки дают в работе QA.
Про стоимость: точных цифр не привожу — расход токенов зависит от модели, тарифа и объёма контекста, поэтому дальше говорю про условную «тяжесть» инструментов и их сравнение.
Что такое MCP и зачем оно мне нужно?
MCP (Model Context Protocol) — это открытый стандарт, разработанный компанией Anthropic (создателями ИИ-ассистента Claude), который позволяет агентным приложениям подключаться к внешним инструментам (например, к БД, TMS, таск-менеджеру, IDE) и предоставлять языковой модели доступ к ним через стандартизированный протокол.
Глоссарий
Модель (LLM) - это мозги. Например, Claude (Sonnet 4.6), GPT-5 и другие. Сама ничего не делает, можно запомнить как сложный алгоритм.
Агент - то, что запускает модель, пишет код, управляет другими приложениями через MCP. Именно он подключается к внешним инструментам. Например: Claude Code, Cursor, Codex CLI.
MCP-сервер - обёртка над конкретным инструментом (Confluence, Kaiten, Postgres и т.д.), с которой и общается агент по протоколу MCP и управляет этим приложением.
md-документация - текстовые файлы в формате Markdown (
.md), которые лежат прямо в папке проекта рядом с кодом. Обычный текст с простой разметкой (заголовки, списки, таблицы), который одинаково удобно читать и человеку, и агенту. В них удобно складывать проанализированные артефакты: описание фичи, свод по Swagger, список тест-кейсов.Суб-агент - отдельный агент с заранее заданной ролью и инструкциями, которого мы вызываем под конкретную задачу. Технически это
.md-файл с описанием (кто он, что делает, какими MCP пользуется), который хранится в папке настроек агента (у Claude Code - в каталоге.claude/agents/). Один раз описали - дальше просто обращаемся к нему по имени, не повторяя инструкции каждый раз.
Поэтому корректнее говорить так: модель X через агент Y по протоколу MCP вызывает инструменты Z. Когда ниже я пишу «просим агента сходить в Confluence», я подразумеваю такую цепочку.
MCP - как универсальный коннектор (по аналогии с USB-C), который позволяет ИИ безопасно и стандартизировано подключаться к внешним приложениям и управлять ими через команды агенту. Что очень удобно. Представь, что ты сидишь в одном окне терминала и говоришь агенту: изучи документацию, составь мне список кейсов, добавь эти кейсы в ТМС, создай задачу на тестирование фичи, создай задачу на баг-репорт, напиши мне автотесты на основании документации, запушь код в ветку. Звучит многообещающе. Практически весь цикл тестирования уже можно уместить в одно окно терминала, и всё это при помощи MCP. Давай же скорее приступим!
Как подключать?
Краткий пример для понимания, как подключать MCP
Здесь и далее я буду использовать агент Claude Code (модель Sonnet 4.6) в связке с IDEA, но ты можешь использовать и другие агентные системы и IDE с поддержкой MCP (Cursor, Codex). Принцип подключения MCP у всех почти одинаковый.
Пример: я хочу, чтобы агент читал документацию по фиче в Confluence.
Стандартный способ:
в поисковой строке ввожу «confluence mcp github official» или ищу инструкцию на официальном сайте продукта
выбираю подходящий конфиг и копирую его в файл настроек Claude Code (находится в папке Claude);
перезапускаю Claude.
Способ для ленивых: прошу Claude самостоятельно найти в интернете MCP-конфиги для подключения нужного продукта и настроить их. Тоже рабочий вариант.
Помни о безопасности: бери конфиги только из официальных источников и не свети пароли и токены в открытом виде.
Заметка о том, что такое плагины Claude Code?
Я потратил некоторое время на изучение плагинов и пришёл к выводу, что они больше подходят для новичков - с их помощью проще подключить нужный функционал парой кликов.
Большинство плагинов идут от сторонних разработчиков, и являются, по сути, просто упакованными промптами и MCP-конфигами, которые при желании можно настроить самому. Реальную ценность представляют официальные плагины от Anthropic или другие официальные MCP крупных продуктов компаний (Figma, Supabase, GitHub MCP, Confluence и т.д.). Но их можно подключить напрямую через MCP без плагинной обёртки. Поэтому далее про плагины мы упоминать не будем. Использовать плагин или подключиться MCP выбор за тобой. Если ты только погружаешься в работу с MCP, попробуй плагины.
Подробнее про агентов и как ими пользоваться можно прочитать в этой статье: Когда зашел не в ту дверь. Или как рядовому QA automation жить в мире с LLM
Что мы получим после прочтения статьи.
Связку, которая позволяет эффективно покрывать значительную часть ежедневной работы QA любой направленности.
Какие MCP интересны для тестирования
MCP Confluence (Atlassian)
Начнем с нашего любимого Confluence. Базы знаний и хранилище документации.
Что умеет:
Заметка: Что умеет любой подключенный вами MCP - вы можете узнать, спросив у клода что умеет "Вставить название" подключенный MCP - расскажи о возможностях, выведи список.
Вот пример такого списка для Confluence:
Чем полезно:
Анализ документации
Тестирование документации
Поиск проблем и противоречий
Создание тест-кейсов
Редактирование документации
Создание новых страниц
Кейсы:
Кейс 1: Анализ документации.
Рассмотрим один из самых распространённых и полезных кейсов для тестирования, на мой взгляд - анализ документации. Используем промпт ниже:
Используй MCP Confluence в роли профессионального тестировщика ПО. Проанализируй документацию (ссылка) по эндпоинту или фиче и составь подробный список тест-кейсов. Проверяй документацию на противоречия. Выведи таблицу со списком кейсов, отсортировав их по критичности. Также предоставь заключение по анализу документации и выдели спорные моменты.
Результат:
Быстрая проверка документации на противоречия и спорные моменты.
Готовый набор тестовых кейсов, которые уже можно начинать проходить.
Мы можем запрашивать информацию в удобном для нас формате - вплоть до того, чтобы сразу оформлять тест-кейсы с нужным дизайном и шагами.
Обязательно перепроверяем результат, не забываем, что мы тестировщики и отвечаем за качество, а агент может что-то упустить или додумать.
Кейс 2: Что ещё умеет Confluence-агент.
Анализ документации частый сценарий, но далеко не единственный. Тем же MCP можно:
Тестировать документацию — сверить описание в Confluence с реальной реализацией или Swagger и подсветить устаревшие, неполные или противоречивые места.
Создавать и редактировать страницы — оформить отчёт о тестировании, чек-лист или новую страницу фичи прямо в базе знаний.
Искать по базе знаний — найти связанные страницы и зависимости по фиче по всему пространству документации.
Используй MCP Confluence, в роли профессионального тестировщика ПО. Сверь документацию (ссылка) с фактической реализацией/Swagger (ссылка): найди устаревшие, неполные и противоречивые места. Выведи таблицу расхождений с указанием, где именно документация не соответствует реализации, и предложи, что нужно актуализировать.
Спойлер: будущее за md-документацией прямо в проекте.
Представь цепочку, где знание передаётся быстро и без потерь: аналитик пишет md-документацию своим агентом → передаёт её разработчику, который обрабатывает её своим агентом и по ней же пишет код → эту же документацию берёт тестировщик и разбирает своим агентом. Документация живёт рядом с кодом, а каждый участник работает с ней через своего агента — процесс передачи знаний становится быстрым и точным.
Бонусы:
Бонус 1: Аналитики уже активно используют этот MCP для создания документации, включая блок-схемы, диаграммы и многое другое из аналитической кухни, что значительно ускоряет работу (механическую, конечно же).
Бонус 2: Чтобы не учить агента, что и как ему нужно делать с MCP, можно сделать следующее:
Бонус 2 - шаги воспроизведения + результат
Шаг 1: Просим агента:
Напиши мне промпт для использования MCP Confluence, для роли профессионального тестировщика, задачи представляют собой анализ документации в Confluence по разным направления: эндпоинту апи или любой другой фиче при разработке по. Составь подробный список тест-кейсов, также проверять на противоречия и выводить список кейсов отсортировав их по критичности. И дальше ещё подумай что добавить в промпт.
Получаем по-настоящему серьезный промпт. И в дальнейшем для написания промптов используем самого агента.
Шаг 2: Просим на основании этого промпта создать суб-агента с именем MCP-Confluence-агент. Создастся md-файл с нашим суб-агентом.
Применение: Теперь, если нам нужно проанализировать документацию в Confluence, то говорим следующее: Используй MCP-Confluence-агент, и проанализируй эту документацию (вставляем ссылку)
Результат: Наш суб-агент уже сам знает, что ему делать и что мы хотим получить, так как все необходимые инструкции уже описаны внутри md-файла суб-агента. Удобно? Ещё как!
MCP Kaiten (или Jira или другие таск трекеры)
Современные проекты не обходятся без таск-трекеров. Такие популярные инструменты, как Jira или Kaiten, объединяет общая черта - канбан-доска и тикеты внутри тикетов внутри тикетов (бесконечная рекурсия). Что дает нам MCP?
Чем полезно:
Создание задач / баг-репортов
Редактирование задач
Анализ задач
Сбор статистики по задачам
Кейсы:
Кейс 1: Создание задач / баг-репортов.
Устал тратить время на оформление баг-репорта?
Просим агента использовать MCP Kaiten, добавляем требования и текст и просим всё красиво оформить в баг-репорт.
Используй MCP Kaiten в роли профессионального тестировщика ПО. На основе требований и текста ниже оформи баг-репорт по шаблону: краткий заголовок, шаги воспроизведения (нумерованный список), фактический результат, ожидаемый результат, критичность, окружение. Выведи результат единым блоком в формате Markdown с заголовками по каждому полю. [сюда — описание проблемы и требования]
Результат: красивый оформленный баг-репорт по твоему дизайну. Хочешь чтобы вообще красиво было? Проси добавить смайликов да побольше.
Из минусов: пока что скриншоты приходится добавлять вручную после создания задачи. Но плюсы уже заметны - рутина с созданием баг-репортов и задач уже не так раздражает.
Не забываем, что задачу по оформлению можно поручать специальному суб-агенту, который будет знать твои предпочтения и пожелания по оформлению.
Кейс 2: Анализ и статистика по задачам.
Неочевидный кейс, полезный для лидов и менеджмента - это использовать агента для сбора аналитики по задачам. Просим агента через MCP Kaiten (или Jira) собрать статистику по задачам за период: сколько багов заведено, какие тикеты зависли без движения, что скопилось на конкретном исполнителе или в статусе. Удобно для отчёта перед ретро или чтобы быстро понять, где узкое место. Можно быстро пылесосить нужную инфу по тикетам, что иногда сильно спасает, особенно если тикетов больше сотни.
Поздравляем! Открыта новая связка!
Lvl 1: Связка: Claude Code + MCP Confluence + MCP Kaiten
Анализируем документацию → Создаем тест-кейсы → Оформляем список кейсов в задачу на тестирование в Kaiten.
MCP TestOps
Без ТМС (тест-менеджмент-систем) уже сложно обходиться на больших проектах. Тесты нужно где-то хранить, оформлять, поддерживать и актуализировать.
Тут нам и помогает MCP TestOps.
Чем полезно:
Создание тест-кейсов
Оформление тест-кейсов
Актуализация тест-кейсов
Сбор статистики
Минусы: На текущий момент MCP TestOps работает тяжело и медленно. В будущем система анонсирует разработку собственного внутреннего ИИ-модуля, который, вероятно, исправит текущие проблемы. Но с базовыми задачами оформления кейсов справляется приемлемо. Особенно хорошо, если нужно оформить уже описанный кейс.
Кейсы:
Промпт MCP TestOps:
Используй MCP TestOps в роли профессионального тестировщика ПО. Оформи описанный ниже тест-кейс в TestOps: заголовок, предусловия, пронумерованные шаги с ожидаемым результатом на каждом шаге, приоритет. Помести кейс в нужную папку/сьют. [сюда — описание кейса]
Стоимость: сам кейс — это текст, лёгкий для агента. Но TestOps медленный, так что тут дороже не токены, а время ожидания ответа.
Lvl 2: Связки: Claude Code + MCP Confluence + MCP Kaiten + MCP TestOps
Новая фича: Анализируем документацию → Создаем тест-кейсы → Оформляем список кейсов в задачу на тестирование в Kaiten. → Оформляем тестовые кейсы в TestOps
Изменение старой фичи: Анализируем документацию на изменения → Создаем новые тест-кейсы → Оформляем задачу на тестирование изменений в Kaiten. → актуализируем тестовые кейсы в TestOps.
Анализ прогонов автотестов: Просим проанализировать тестовый прогон под номером Х и вывести аналитику по проблемам. Если проблема подтверждена, просим оформить проблему в баг-репорт через MCP Kaiten
MCP Postgres
Сходить в базу, создать тестовых данных, изучить структуру таблиц — всё это и прямо сейчас. С важной оговоркой. Скорее всего, у тебя на проекте не будет доступа к редактированию и удалению таблиц, тем более на проде. Поэтому будем считать, что мы работаем в своей уютной изолированной тестовой среде.
Чем полезно:
Создание SQL запросов
Анализ таблиц
Создание тестовых данных
Написание автотестов
Кейсы:
Промпт:
Используй MCP Postgres (только чтение). Сверь фактическую структуру таблицы <имя> с ожидаемой из документации (ссылка): имена колонок, типы данных, nullable, ключи и индексы. Выведи таблицу расхождений и помеченные красным несоответствия, которые стоит завести как баги.
Помни про доступы: для анализа структуры и сверки данных - read-only, для создания тестовых данных - write только на изолированной тестовой среде, никакого прода.
Ну и результат сверки перепроверяем сами, перед тем как заводить баг, глазами убеждаемся, что расхождение реальное, а не шутки агента.
Стоимость: дёшево, пока выборки небольшие. Если вытащить в контекст огромную таблицу или дамп на тысячи строк — токенов уйдёт заметно больше, поэтому просим агента брать только нужное и очень осторожно.
Lvl 3: Связки: Claude Code + IDEA + MCP Confluence + MCP Kaiten + MCP TestOps + MCP Postgres
Анализ таблиц: Анализируем по документации структуру таблицы → через MCP Postgres просим проверить на соответствие таблицы → если находим несоответствия, то через MCP Kaiten заводим задачу на исправление.
Написание автотестов: Предположим, что нам нужно проверить новый эндпоинт. Мы просим изучить документацию (MCP Confluence) → просим изучить дополнительную информацию в задаче (MCP Kaiten) → при необходимости сверяем структуру таблиц (MCP Postgres) → просим сгенерировать API-автотесты на нашем стеке → проверяем и дорабатываем.
Лайфхак: если всё же нельзя использовать MCP для БД, но доступ к схеме нужен, используй ручной способ получения структуры схемы БД - в любой СУБД правый клик на таблицу: Generate SQL → DDL.
MCP Chrome DevTools
Инструмент незаменим для тестирования UI. С помощью него наш агент получает “глаза” и может видеть всё, что происходит на UI части приложения. Самое полезное, на мой взгляд, — это автоматический сбор локаторов по всем элементам, исследовательские сценарии по тестированию форм, мониторинг вызовов и состояний при нажатии элементов на странице.
Чем полезно:
Анализ страницы
Поиск локаторов
Создание селекторов
Создание сценариев тестов
Написание автотестов
Анализ логов из консоли
Кейсы:
Используй MCP Chrome DevTools. Проанализируй страницу (ссылка), собери список всех интерактивных элементов (поля, кнопки, чекбоксы, ссылки). Для локаторов используй устойчивые признаки (id, data-атрибуты, уникальный текст), избегай индексов и динамических классов. Выведи результат таблицей (элемент, тип, локатор), затем предложи готовый PageObject на Selenide с этими селекторами.
Локаторы и селекторы желательно перепроверять на устойчивость.
Стоимость: дороже текстовых сценариев — снапшот страницы (DOM + дерево доступности) потребляет много токенов. Одна страница — терпимо, но анализ десятка страниц подряд - слишком тяжело.
Lvl 4: Связки: Claude Code + IDEA + MCP Confluence + MCP Kaiten + MCP TestOps + MCP Postgres + MCP DevTools
Парсинг локаторов для UI автотеста.Кидаем ссылку на страницу → Просим проанализировать страницу используя MCP DevTools, и на основании анализа собрать списки локаторов на все обнаруженные элементы с подробным описанием. → Как вариант сразу просим оформить в PageObject, создав селекторы на Selenide как вариант.
Анализ сетевых запросов и формирование кейсов.Открываем страницу с формой/запросом → просим используя MCP DevTools отследить реальные запросы и ответы в сети (endpoint, заголовки, тело, коды ответов) → просим оформить это в формате md-файла → на основании этого файла просим генерировать api автотесты.
Написание UI автотеста.Анализируем документацию → Просим создать предварительно набор ручных UI-сценариев на основании документации. → Кидаем ссылку на страницу → просим использовать MCP DevTools для анализа страницы. → Просим создать список локаторов элементов → Просим создать набор UI-автотестов на нашем стеке, на основании собранной информации по локаторам. → Проверяем тесты.
Парсинг инструкций.Также можно использовать DevTools для парсинга инструкций. Кидаем ссылку на страницу с инструкцией → просим используя MCP DevTools изучить страницу и вытащить содержимое инструкции → Просим оформить её в удобном виде (например md файл), чтобы дальше использовать как контекст для тестирования.
MCP Playwright
Если DevTools дают агенту «глаза» на живой странице и удобны для сбора локаторов, то MCP Playwright — это «руки»: агент сам открывает браузер, ходит по страницам, кликает, заполняет формы, проверяет состояния и снимает скриншоты. Причём делает это сразу, без предварительно написанного кода — прямо в диалоге. Отличный инструмент для исследовательского тестирования UI и быстрого прототипирования e2e-сценариев.
Чем полезно:
Исследовательское прохождение UI-сценариев (агент сам «прокликивает» флоу)
Генерация чернового каркаса e2e-теста
Снятие скриншотов и трейсов для баг-репорта
Проверка форм и валидаций
Проверка поведения в разных браузерах
DevTools MCP и Playwright MCP частично пересекаются. На мой взгляд, DevTools удобнее, когда нужно проанализировать уже открытую страницу и собрать локаторы, а Playwright — когда нужно управляемо «пройти» сценарий целиком. Держать оба активными одновременно без нужды — это лишнее раздувание контекста.
Минусы: прогон сценария через браузер заметно медленнее, чем анализ DOM; для стабильных регрессов всё равно лучше перенести сценарий в код на своём стеке.
Кейсы:
Кейс 1: Исследовательский прогон.
Кидаем ссылку на страницу → просим используя MCP Playwright пройти сценарий по шагам (например, оформление заявки) → просим фиксировать проблемы и снимать скриншоты на ключевых шагах.
Кейс 2: Черновик e2e-теста.
Просим пройти сценарий → на основании выполненных шагов и найденных элементов просим сгенерировать черновой автотест → переносим его на наш стек (Selenide) и доводим до ума.
Промпт:
Используй MCP Playwright. Пройди на странице (ссылка) сценарий по шагам (например, оформление заявки): заполни форму, нажми кнопки, дойди до результата. Фиксируй проблемы и делай скриншоты на ключевых шагах. По итогу предложи черновик e2e-теста по пройденному пути.
Минусы: всё равно придется доделывать черновой автотест. Сгенерированный каркас — это заготовка, а за стабильность регресса отвечаем мы. Но то, что есть, уже значительный прирост к скорости работы.
Стоимость: самый тяжёлый инструмент — живой прогон по страницам съедает токены на каждом шаге. Лучше брать очень маленькие и точечные сценарии для использования. Так и стабильность выше, и стоимость дешевле. Не нужно отправлять агента путешествовать по огромному проекту исследуя десятки страниц, ограничься одной. Ещё не пришло время :)
Lvl 5: Связки: Claude Code + IDEA + MCP Confluence + MCP Kaiten + MCP TestOps + MCP Postgres + MCP DevTools + MCP Playwright
Кейс: Полный цикл UI-теста.
Анализируем документацию (MCP Confluence) → создаём ручные UI-сценарии → используя MCP Playwright прогоняем сценарий в браузере и снимаем скриншоты → на основе прогона генерируем черновой e2e-тест → переносим на наш стек (Selenide).
MCP GitLab
Код фичи, merge requestы, пайплайны. MCP GitLab даёт агенту доступ к репозиторию: он может почитать код по фиче, посмотреть MR, разобрать причину упавшего пайплайна, создать ветку и залить туда готовые автотесты. По сути это то место, куда «замыкается» весь цикл всего тестирования.
Чем полезно:
Анализ кода фичи по задаче (сверка «как задумано» и «как сделано»)
Чтение diff и merge request-ов
Создание веток и MR
Разбор упавших пайплайнов
Сбор дополнительного контекста для написания автотестов
Минусы и безопасность: для анализа достаточно read-only доступа. Права на push и особенно на защищённые ветки давать осторожно. Пока, на мой взгляд, страшновато доверять агенту полностью пушить в ветку.
Кейсы:
Кейс 1: Анализ кода фичи.
Просим используя MCP GitLab изучить код по фиче (ссылка на MR или ветку) → сверяем реализацию с документацией из Confluence → если находим расхождения, через MCP Kaiten заводим задачу на исправление.
Кейс 2: Заливка автотестов.
После того как автотесты написаны и проверены → просим создать отдельную ветку → залить код → оформить merge request с описанием. Это и есть шаг 12 из «Гига Чад версии».
Промпт:
Используй MCP GitLab (только чтение). Изучи код по фиче (ссылка на MR или ветку), сверь фактическую реализацию с документацией из Confluence (ссылка) и подсвети расхождения: что описано, но не сделано, и что сделано иначе. Выведи список расхождений.
Помни: код перед заливкой тестов обязательно перепроверяем и прогоняем, потому что за то, что улетает в репозиторий, отвечаем тоже мы.
Стоимость: невысокая. Крупный MR на сотни изменённых строк в контексте обойдётся дороже, поэтому просим агента смотреть точечно по фиче, а не весь репозиторий.
Lvl 6: Связки: Claude Code + IDEA + MCP Confluence + MCP Kaiten + MCP TestOps + MCP Postgres + MCP DevTools + MCP Playwright + MCP GitLab
Кейс: Замыкаем цикл кодом.
Пишем автотесты на основе всего собранного контекста → проверяем → через MCP GitLab создаём ветку и заливаем код → оформляем merge request. Круг замкнулся: от документации до кода в репозитории.
MCP Mattermost Server
Далеко не весь контекст по фиче есть в документации и задачах. Куча важных договорённостей, уточнений и прочих кулуарных обсуждений лежит в рабочих чатах. MCP Mattermost позволяет агенту добраться до этого контекста: почитать обсуждение фичи, найти инфу в треде, завести новую задачу на основании переписок в чате. При желании можно даже отвечать кому-то в чате через агента или делать рассылки.
Чем полезно:
Сбор контекста из обсуждений в чатах
Поиск решений и договорённостей в тредах
Генерация задач на основании переписок
Минусы и безопасность: переписка — это чувствительные данные. Нужно помнить про приватность каналов и не светить лишнее, поэтому лучше дать агенту исследовать конкретный топик. И уважай приватность коллег, не выставляй на всеобщее обозрение свой неформальный стиль общения.
Кейсы:
Промпт:
Используй MCP Mattermost. Собери из топика (ссылка) ключевые договорённости и уточнения по фиче: что решили сделать иначе, чем в документации, какие есть открытые вопросы. Кратко резюмируй — это добавим в общий контекст анализа.
Кейс 1: Сбор контекста из топика.
Даём ссылку на рабочий топик по фиче → просим используя MCP Mattermost собрать ключевые договорённости и уточнения → добавляем это к общему контексту анализа
Кейс 2: Генерация задач на основании переписок.
Копируем ссылку нужного топика → кидаем агенту, просим через MCP Mattermost прочитать все сообщения топика, обобщить информацию, выделить ключевые мысли → просим через MCP Kaiten создать нам оформленную задачу на основании полученной информации.
Стоимость: чтение одного топика — лёгкое. Дорого станет, если тянуть большие треды целиком в стиле "всё изучи мне!", поэтому точечно обрабатываем топики с конкретными запросами.
Общий процесс: на примере тестирования эндпоинта
У нас открыт наш проект в IDEA, у нас запущено окно Claude Code. И теперь мы как оператор терминала будущего, начинаем творить техномагию. Опишу шаги и события моего процесса.
Lvl 7: Связки: Claude Code + IDEA + MCP Confluence + MCP Kaiten + MCP TestOps + MCP Postgres + MCP DevTools + MCP Playwright + MCP GitLab + MCP Mattermost
Шаги общего процесса:
У нас есть задача — протестировать новый эндпоинт.
Просим Claude создать нам новую задачу на тестирование в Kaiten
Просим Claude проанализировать документацию в Confluence и создать полный md-файл.
Просим Claude проанализировать дополнительно информацию из задачи в Kaiten и создать md-файл.
Просим Claude проанализировать дополнительно информацию по эндпоинту в Swagger и создать документацию сваггера в md-файле.
Просим Claude проанализировать дополнительно информацию из рабочего топика по фиче из Mattermost и вынести полученную информацию в отдельный md-файл.
Опционально просим проанализировать код по фиче в GitLab и также результаты описать в md-файле.
На текущем этапе у нас есть наиболее полный анализ всех артефактов по новому эндпоинту. И копии этих артефактов сохраненные в md-файлах, внутри проекта. Думаю при большом желании можно ходить и в miro/figma.
На основе всего этого контекста и анализа просим агента проверить все противоречия в наших артефактах и исправить их. После завести таску на исправление в Kaiten, если выявились проблемы.
На основании контекста анализа просим создать ручные тесты и продублировать их в md-файл, и после проверки и повторной просьбы проверить нет ли там лишних или избыточных тестов, просим оформить их в нашей ТМС TestOps.
На основании созданных тестов, которые также продублированы у нас в md-файле, просим написать код автотестов используя наш фреймворк (подразумевается, что у тебя настроена инфраструктура для твоих автотестов и прописаны инструкции по правилам написания и оформления этих тестов).
После того как мы получили пачку автотестов на нужный нам эндпоинт, пробегаемся глазами (своими настоящими), убеждаемся, что тесты имеют смысл и работают, вносим правки и просим залить их в репозиторий кода ГитЛаб.
Удивляемся.
Стоимость: Полный цикл обычно не имеет смысла реализовывать. Эффективнее работать последовательно, а не запускать отдельный большой сценарий от и до. Понятно, что он будет достаточно дорогой (дорого — это относительная оценка, основанная на "если бы я делал дома за свои деньги"). Тут задействуются все MCP и много контекста. Но сам факт, что это реально сделать, очень радует. Кто знает, может скоро понятие стоимости токенов уйдет и будут доступны сложнейшие сценарии без ограничений :)
Заключение
Вот мы и прошли путь от одного MCP до связки из семи инструментов, которая покрывает почти весь цикл тестирования — от анализа документации до залитого в репозиторий кода автотестов. И всё это в одном окне терминала, не переключаясь между десятком вкладок. Шаги, на которые уходили часы рутины, теперь можно реализовать в едином процессе.
Но есть и минусы: некоторые инструменты ещё сырые. TestOps работает медленно, скриншоты приходится добавлять руками, агент ошибается и его нужно поправлять, UI — отдельная непредсказуемая область. Но вектор очевиден, и текущий тренд УЖЕ экономит время — а дальше будет только лучше.
Пара слов о безопасности
Прежде чем внедрять эти связки, зафиксируй базовые правила:
В начале,когда ты только продуешь, используй только read-only доступы и расширяй права по мере необходимости. Давай полный доступ иснтрументу который ты ещё осваиваешь, плохая идея.
write-операции (создание тестовых данных, пуш в ветку) — только на изолированной тестовой среде и с ручным подтверждением. Пока ты не разобрался как это всё работает, лучше не рисковать ценными данными.
Никакого прода и никаких боевых данных в контексте агента. Используй естовую среду, так спокойней.
MCP-конфиги — из официальных источников, пароли и токены не светим;
чувствительные данные (переписки, персональные данные) агенту скармливаем точечно;
результат агента всегда перепроверяем сами — ответственность за качество остаётся на нас.
С чего начать? Не пытайся подключить сразу всё. Возьми один MCP под свою задачу, установи, пойми, что он умеет, попробуй потыкаться, поиграться. Дальше уже как освоишься, можно пробовать другие инструменты, постепенно. Когда придет понимание, можно уже их объединять между собой в цепочки.
Поделись в комментариях, полезна ли была статья и получилось ли у тебя настроить свои MCP связки. Что получилось и работает, а что нет. А если ты только начинаешь жить в мире LLM, загляни в предыдущую статью — Когда зашел не в ту дверь. Или как рядовому QA automation жить в мире с LLM — там я писал про первые эксперименты с агентами. Удачи!
