Практика: чек-листы, тест-кейсы, автотесты и MCP с локальной LLM

Теория и настройки позади. В этом посте — только практика: конкретные промпты, которые я использую ежедневно для QA-задач. Берите, копируйте, адаптируйте под свой проект.

Генерация чек-листа из требований

Самый частый сценарий. Получил ТЗ — нужно быстро понять, что тестировать.

Промпт

На основе следующих требований составь чек-лист тестирования.

Требования:
{вставляем текст требований}

Формат вывода:
- Номер | Проверка | Ожидаемый результат | Приоритет (High/Medium/Low)
- Минимум 10 пунктов
- Обязательно включи граничные случаи
- Обязательно включи негативные сценарии
- Для каждого обязательного поля проверь: пустое значение, слишком длинное, спецсимволы

Что получается

На выходе — структурированный список из 10-20 пунктов. Не идеальный: иногда модель забывает про кросс-браузерность, иногда дублирует проверки. Но вместо того чтобы писать с нуля, вы редактируете готовый вариант. Экономия — 30-40 минут на каждую фичу.

Усиление промпта

Если добавить в контекст примеры ваших чек-листов (3-4 штуки), модель начнёт копировать ваш стиль: терминологию, формат, уровень детализации. Это работает лучше любых инструкций.

Примеры наших чек-листов:
{вставляем 3-4 примера}

На основе этих примеров составь чек-лист для новой фичи:
{текст требований}

Генерация тест-кейса с шагами

Когда чек-листа недостаточно — нужен полноценный тест-кейс с шагами, предусловиями и ожидаемыми результатами.

Промпт

Напиши подробный тест-кейс для проверки: {описание сценария}

Требования:
{вставляем релевантные требования}

Формат:
ID: TC-XXX
Название: (краткое, понятное)
Предусловия: (что нужно подготовить)
Шаги: (нумерованный список, каждый шаг — одно действие)
Ожидаемый результат: (после каждого шага или общий)
Приоритет: High/Medium/Low
Тип: Positive/Negative/Edge case

Требования к качеству:
- Каждый шаг должен быть выполним одним действием
- Ожидаемый результат должен быть проверяемым
- Укажи, какие данные нужны для теста

Реальный пример

Я попросил написать тест-кейс для проверки восстановления пароля. Получилось 8 шагов: открыть страницу → ввести email → нажать «Отправить» → проверить письмо → перейти по ссылке → ввести новый пароль → подтвердить → проверить вход. С предусловиями («пользователь зарегистрирован», «доступ к почте»), ожидаемыми результатами после каждого шага, и граничными случаями («ссылка просрочена», «пароль совпадает со старым»).

Готов к загрузке в TestOps? Нет, нужно поправить ID и убедиться, что локаторы актуальны. Но структура, шаги и проверки — на месте. Экономия — 20-30 минут.

Написание кода автотестов

Playwright (TypeScript)

Напиши Playwright-тест для проверки: {описание сценария}

Контекст проекта:
- Используем TypeScript
- Page Object Model
- Локаторы через data-testid
- Базовый URL: {url}

Требования к коду:
- Используй fixtures для общих setup/teardown
- Добавь комментарии к сложным проверкам
- Используй expect с понятными сообщениями об ошибках
- Добавь скриншот при падении

Элементы интерфейса:
{список элементов с data-testid}

Реальный результат

Модель генерирует полноценный тестовый файл: импорты, describe/it блоки, Page Object класс (если его ещё нет), сам тест с ассертами. В 70-80% случаев код компилируется без правок. Остаётся:

• Проверить, что data-testid актуальны
• Добавить ожидания там, где нужно
• Дописать edge cases

Pytest + Appium (Python)

Напиши pytest-тест для мобильного приложения (Appium):
- Платформа: {iOS/Android}
- Сценарий: {описание}
- Используй pytest fixtures
- Page Object Model
- Добавь скриншот при падении

Доступные элементы:
{список элементов: accessibility id в приоритете, id, xpath — в крайнем случае}

Особенность мобильной автоматизации — модель чаще ошибается с локаторами, потому что их структура вариативнее. Но архитектура теста (fixtures, POM, структура) получается отлично. Экономия — 40-50 минут на каждый тест.

Проверка покрытия требований

Одна из самых полезных задач для LLM. Даёте два списка — получаете анализ.

Промпт

Сравни список требований и список тест-кейсов.

Требования:
{список требований с ID}

Тест-кейсы:
{список тест-кейсов с ID и названиями}

Проанализируй:
1. Какие требования не покрыты тестами? (конкретные ID)
2. Какие тесты избыточны или дублируют друг друга?
3. Какие граничные случаи упущены?
4. Какие требования покрыты частично? (что именно не проверено)
5. Предложи недостающие тест-кейсы (с кратким описанием)

Формат: таблица с колонками: Требование | Статус покрытия | Рекомендации

Реальный результат

На проекте с 23 требованиями и 18 тест-кейсами модель нашла:

• 4 непокрытых требования (включая валидацию ИНН и проверку дублей email)
• 2 дублирующих теста (оба проверяли валидацию телефона разными способами)
• 3 пропущенных граничных случая (пустая корзина, максимальное количество товаров, спецсимволы в адресе)

Всё это я бы нашёл и сам, но на это ушёл бы час внимательной работы. Модель — 5 минут.

Анализ логов тестового прогона

Промпт

Проанализируй логи тестового прогона.

Задачи:
1. Найди все FAILED тесты, укажи причину падения
2. Найди флаки (тесты с нестабильными результатами)
3. Найди паттерны ошибок (например, timeout на конкретных эндпоинтах)
4. Сгруппируй ошибки по типам
5. Дай рекомендации по исправлению

Логи:
{вставляем логи — можно несколько тысяч строк}

Реальный результат

На логах в 2000 строк модель нашла:

• 5 тестов падают с timeout на /api/v1/cart — рекомендация: увеличить wait с 10 до 30 секунд
• 3 теста флакают на проверке даты — рекомендация: использовать моки или фиксированную дату
• 2 теста падают с 500 на стенде — рекомендация: проверить стенд перед прогоном
• 1 тест падает из-за изменившегося локатора — рекомендация: обновить селектор

Структурированный отчёт, готовый к отправке в Slack или Jira. Экономия — 30-40 минут ручного чтения логов.

Работа с Jira через MCP

Теория MCP была в первом посте. Здесь — конкретный пример.

Сценарий: создание баг-репорта из описания

Пользователь: "Создай баг на падение приложения при входе без интернета"

Системный промпт модели:
"Ты — QA automation engineer. При получении описания бага:
1. Сформулируй чёткое название
2. Опиши шаги воспроизведения
3. Укажи ожидаемый и фактический результат
4. Определи severity (Blocker/Critical/Major/Minor)
5. Добавь labels на основе текста
6. Вызывай mcp_jira_create_issue с полученными параметрами"

Результат:
- project: MOBILE
- summary: "Crash при offline-входе в приложение"
- description: "Шаги: 1. Отключить Wi-Fi и мобильный интернет..."
- priority: Critical
- labels: ["crash", "offline", "regression", "ios"]
- assignee: {определяется по компоненту}

Модель сама формирует структурированный баг-репорт и создаёт тикет. Вы только проверяете и отправляете.

Полезные трюки

Temperature для разных задач

Задача	Temperature	Почему
Чек-листы, тест-кейсы	0.1-0.3	Максимальная точность, минимум галлюцинаций
Код автотестов	0.3-0.5	Точность + небольшая гибкость для нестандартных кейсов
Анализ логов	0.1-0.2	Только факты, никаких домыслов
Поиск edge cases	0.8-1.0	Креативность, нестандартные мысли
Мозговой штурм	0.7-0.9	Много вариантов, из которых вы выбираете

Системный промпт для QA

Ты — senior QA automation engineer с 8-летним опытом.
Твои задачи:
- Писать чёткие тест-кейсы с однозначными ожидаемыми результатами
- Использовать data-testid для локаторов в автотестах
- Добавлять граничные случаи и негативные сценарии
- Следовать паттерну Arrange-Act-Assert в коде
- Комментировать сложные участки кода
- Не делать предположений о поведении — если не указано в требованиях, отмечай как вопрос

Стек проекта: {Playwright/Python/Appium/...}
Соглашения о коде: {camelCase/snake_case/...}

Контекст — ваш друг

Чем больше контекста вы дадите модели, тем лучше результат:

• Покажите примеры существующих тестов (3-5 штук)
• Укажите стек технологий
• Опишите соглашения о коде
• Передайте ограничения проекта («не используем XPath», «все тесты должны быть независимыми»)

Модель не умеет читать мысли. Чем конкретнее запрос — тем лучше ответ.

Что дальше

В следующем посте — продвинутый уровень. OpenCode, Pi и другие инструменты, которые работают в связке с локальными моделями. Как они ускоряют разработку и почему локальные LLM — идеальное сочетание для этих инструментов.

Если есть промпты, которые работают у вас — делитесь в комментариях. Дополним коллекцию.