Home

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг

Всем привет! Я один из лидеров стека тестирования в компании «ТехВилл» (в простонародье — Head QA). Моя цель простая: снимать рутину с QA-инженеров с помощью AI-инструментов.

В идеальном мире мы «скармливаем» модели, требования, ссылки на Figma, ветки в Git и прочие артефакты через MCP, а она помогает:

1) писать тест-кейсы по контексту,

2) а затем — генерировать автотесты на базе этих кейсов.

Про генерацию тест-кейсов из Swagger и автотестов на API по тест-кейсам через Cursor (на реальном проекте) я уже записывал большой гайд про «вайбкодинг/вайбтестинг». В этом гайде я в том числе показал свой подход вайбкодинга через вспомогательные файлы типа roadmap.md, progress.md, refactor.md, context.md и т. д. В таком подходе мне удалось завайбкодить два своих микропродукта на JS, у одного из которых более 60 000 weekly users (при том, что я ни разу не программист и JS «не знаю совсем»). 

Решили начать с ИИ-ревью тест-кейсов

Написание качественных тест-кейсов по ТЗ и всем материалам — задача реально непростая. Поэтому мы решили начать с малого: сделать AI-ревьюера тест-кейсов.

Идея такая:

1. QA-инженер переводит тест-кейс в Allure TestOps в статус «Ревью».

2. AI подключается, проверяет кейс по регламенту (промпту).

3. Публикует результат ревью комментарием к кейсу.

4. Переводит тест-кейс в понятный статус (например, «Нужно исправить»), чтобы QA сразу понял, что делать дальше.

Чтобы это работало технически, нам нужно уметь:

• сходить в TestOps,

• забрать тест-кейс,

• отревьюить,

• вернуть комментарий обратно.

Под это мы и сделали своё MCP для TestOps и интерфейс для настройки промптов под определенные проекты в TestOps. Выглядит он примерно так:

Почему не используем MCP TestOps

В TestOps недавно появился собственный MCP и встроенный AI-чат — прямо внутри системы. Для AI-чата, правда, нужна отдельная лицензия. Мы узнали об этом уже после того, как разработали свой MCP.

Мы также посмотрели на возможности встроенного AI-чата от TestOps и пришли к выводу: наше решение по возможностям нам нравится как минимум не меньше. При этом оно остаётся нас бесплатным (в рамках текущей инфраструктуры и наших лицензий).

Как работает наш MCP

Наш MCP написан на Python и использует фреймворк FastMCP:

https://moge.ai/ru/product/fastmcp2

Также мы трансформировали предоставляемую OpenAPI-спецификацию Allure TestOps в API-клиента.

Дальше флоу следующий:

• MCP через API TestOps получает нужные данные (тест-кейсы, шаги, вложения и т.д.) и передаёт их в LLM для анализа.

• После обработки в LLM мы через методы MCP сохраняем результат обратно в TestOps (например, в виде комментария/итога ревью).

Причём тут Cursor 

На момент, когда мы начали, у нас было несколько практичных ограничений:

• веб-интерфейс для ревью ещё не совсем готов;

• MCP может иногда «глючить» и не отдавать какие-то сценарии из TestOps;

• под капотом работает модель, которую нужно оплачивать;

• а в Cursor есть возможность использовать корпоративный аккаунт + у команды уже есть опыт работы с ним.

Поэтому я решил сделать минимальный прототип: маленький проект в Cursor с правилами и одной командой, чтобы любой QA мог:

• спулить репозиторий,

• открыть в Cursor,

• одной командой прогнать ревью своего тест-кейса,

• быстро проверить качество ревью на практике.

Как устроен мини-проект в Cursor

Внутри по сути минимум:

• одно project rule (основной промпт ревью),

• одна command (/review-test-case),

• одно user rule (чтобы Cursor точно подтягивал project rules),

• MCP для работы с TestOps.

User Rule

Ниже — правило пользователя, которое решает боль Cursor: он не всегда стабильно читает project rules. Я принудительно заставляю его перед каждым ответом прочитать правила проекта, а фраза «В контекст добавлены правила…» служит маркером, что правила реально применились.

“Отвечай на русском языке.

Перед каждым ответом обязательно читай правила проекта из .cursor/rules. Не приступай к ответу, пока не прочтёшь правила.

Каждый свой ответ без исключений начинай с фразы «В контекст добавлены правила: X, Y, Z, etc.» с названиями прочтённых файлов с правилами.”

Промпт ревью тест-кейса (project rule)

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

Ты — Senior QA Engineer (30+ лет опыта) по тестированию Mobile/Web/API. Ты проводишь ревью тест‑кейсов в Allure TestOps и помогаешь QA писать кейсы так, чтобы они были: однозначными, проверяемыми, атомарными, воспроизводимыми, детерминированными и пригодными к автоматизации.

Я буду присылать тебе скриншоты/текст тест‑кейса из Allure TestOps (иногда только часть полей). Твоя задача: быстро и строго отревьюить кейс по регламенту ниже и предложить конкретные правки.

=== РЕГЛАМЕНТ (кратко) ===

1. Принципы: однозначность, проверяемость (измеримый ER), атомарность, независимость/повторяемость, детерминизм (фиксируем флаги/данные), пригодность к авто (убираем «проверить корректно/обратить внимание»).

2. Термины: используем термины как в UI/продукте; если есть различия с API/доменом — поясняем.

3. Must‑have поля: Title, Preconditions (только состояние + данные/критерии), Shared steps (если повторяется в 2+ кейсах), Scenario с Expected result на КАЖДЫЙ шаг, Artifacts по делу, Tags/Links.

4. Title:

   4.1 Mobile/Front: <Экран/раздел> — <что проверяем> — <ожидаемый эффект>

   4.2 API (в отдельном API‑проекте): Suite = (<endpoint/контекст>), Title = <сценарий/вариация>, без «Positive/Negative.Search HTTP» в названии кейса.

5. Preconditions: не пишем «изучить доку/подготовить Postman/импортировать curl» — это не состояние системы. Данные фиксируем как значения или критерии поиска + где взять.

6. Шаги: 1 шаг = 1 действие; Expected result измеримый (что именно видим/какой код/какие поля/какое состояние).

=== ФОРМАТ ОТВЕТА (строго) ===

A) Короткая оценка (2 блока)

• ✅ Что хорошо (3–6 пунктов)

• ❌ Что плохо / риски (3–8 пунктов). Пиши по существу: «неизмеримый ER», «preconditions = инструкция», «нет данных/критерия», «смешаны проверки», «не детерминированно», «термины расходятся», «можно вынести в shared step» и тому подобное

B) Правки «было → стало» (коротко и прикладно)

Для каждого изменения придерживайся структуры:

1. Что не так (1 строка: почему исправляем)

2. Было: <короткая цитата/суть текущего фрагмента>

3. Стало: <короткий улучшенный вариант>

Правки давай по главным зонам:

• Title (по правилу нейминга)

• Preconditions (только состояние + тест‑данные/критерии)

• Shared steps (если реально повторяемо)

• Scenario: шаги + Expected result (ER обязателен на каждом шаге)

• Artifacts/Tags/Links (только если явно нужно)

Важно:

• Не пиши длинные лекции. Только ревью и конкретные правки.

• В Scenario избегай воды: вместо «ссылка открывается» пиши где и как это проверяется (системный браузер / WebView, заголовок/URL/кнопка закрытия, отсутствие ошибок).

• Если в кейсе много повторяющейся навигации/подготовки токена/настройки окружения — явно предложи вынести в Shared step.

• Если часть данных неизвестна (нет id/значений) — используй плейсхолдеры {banner_id}, {token}, {card_number} и добавь критерий «как найти/проверить актуальность».

=== ВХОДНЫЕ ДАННЫЕ ===

Я присылаю:

• id тест‑кейса, который необходимо поправить

Начинай ответ сразу с пункта A), потом B).

Команда /review-test-case

Чтобы QA мог прогнать ревью «одной кнопкой», я добавил command review-test-case:

# review-test-case

Сделай ревью тест-кейса в Allure TestOps и опубликуй результат НОВЫМ комментарием в этот тест-кейс через MCP TestOps.

Важно: всегда создавай новый комментарий (create), никогда не обновляй существующие (update) и не удаляй комментарии.

Входной параметр: {test_case} — ссылка на тест-кейс или его ID.

Приоритет данных:

1. Получи данные через MCP (testcase_get_by_id / testcase_get_scenario).

2. Если в ответе API какие-то поля пустые (например, scenario: null или steps: []), но к сообщению приложен скриншот — ориентируйся на скриншот.

3. Не пиши «Нет сценария» или «Пустое поле», если текст виден на изображении.

Примеры:

- /review-test-case 70756

Требования к ответу (строго):

- Начинай с пункта A), затем B) по регламенту проекта.

- В A) два блока: ✅ Что хорошо (3–6), ❌ Что плохо/риски (3–8).

- В B) “было → стало” для ключевых зон: Title, Preconditions, Shared steps (если нужно), Scenario (шаги + ER на каждый шаг), Artifacts/Tags/Links (если нужно).

Зачем второй MCP: sequential-thinking

У меня подключено два MCP:

1. MCP для работы с TestOps (получить кейс/сценарий/добавить комментарий).

2. sequential-thinking — чтобы модель не «стреляла общими словами», а шла последовательно и фиксировала проверки.

Я решил, что для ревью sequential-thinking будет полезна не хуже, чем для кода: модель проходит по цепочке preconditions → шаги → expected result → тест-данные → детерминизм/автоматизируемость, и на каждом этапе быстрее всплывают типовые дыры: размытые ER, пропущенные данные, смешение нескольких проверок в одном кейсе и т. д.

Как это выглядит в работе

Флоу максимально простой:

1. Берём тест-кейс в TestOps.

2. Вызываем команду /review-test-case <id> в Cursor. На всякий случай прикладываем скриншот кейса (помним, что MCP иногда может не отдать сценарий).

3. Через несколько секунд получаем результат ревью комментарием в TestOps.

По-моему неплохо!

Если вам понравилась статья дайте знать и мы выложим продолжение.

Обсудить в форуме