Методы и анти-паттерны

Как выбрать технику под задачу QA

Почему важно выбирать не только слова, но и режим работы

Одна из типичных ошибок при использовании LLM — пытаться решать все задачи одним и тем же способом: например, всегда писать один большой запрос и ожидать одинаково хорошего результата для форматирования, анализа требований, генерации тест-кейсов и работы с большими документами.
На практике качество ответа зависит не только от формулировки, но и от того, какой именно паттерн взаимодействия вы выбрали.

Для тестировщика это особенно важно, потому что QA-задачи сильно различаются по своей природе:

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

Шесть основных режимов работы

Сначала выберите режим взаимодействия — от него зависит архитектура запроса не меньше, чем формулировка. Справочник с примерами для QA — ниже; интерактивное дерево выбора — в блоке «Схема выбора техники».

Схема выбора техники

Простое правило для запоминания

Хороший QA-промпт — это не только хороший текст, но и правильная архитектура запроса.

Продвинутые техники для тестировщика

Ты — QA-аналитик. Твоя задача — проверить полноту и ясность требований.
Перед тем как генерировать тест-кейсы, составь список из 5–10 наиболее
важных вопросов, которые нужно задать разработчикам/PM,
чтобы устранить все неоднозначности в предоставленных материалах.

Аромат RTCCO Базовый рецепт, описанный в главе 5. Фундамент для всех остальных методов.

Аромат «Сначала вопросы» — особенно на этапе анализа требований: сначала уточняющие вопросы, затем тест-кейсы с ответами заказчика.

Ты — QA-аналитик. Твоя задача — проверить полноту и ясность требований.
Перед тем как генерировать тест-кейсы, составь список из 5-10 наиболее
важных вопросов, которые нужно задать разработчикам/продакт-менеджеру,
чтобы устранить все неоднозначности в предоставленных материалах.

Сгенерируй 20 тест-кейсов по этому ТЗ. [вставка 50 страниц без ответов на вопросы]

Аромат Few-shot (мало-образцовый)

Мощная техника: вы даёте модели 1–3 эталонных примера «правильного» ответа — так стабилизируется формат команды.

Пример хорошего тест-кейса:
ID: TC-001
Название: Успешная авторизация
Шаги:
  1. Ввести логин
  2. Ввести пароль
  3. Нажать Войти
Ожидаемый результат: Авторизация успешна

Пример 1 — позитивный:
ID: TC-AUTH-001
Название: Авторизация валидным пользователем
Предусловия: Пользователь существует, статус Active
Шаги:
  1. Ввести email: user@example.com
  2. Ввести пароль: ValidPass123
  3. Нажать «Войти»
Ожидаемый результат:
  — HTTP 200, редирект на /dashboard
  — JWT записан в localStorage
  — Имя пользователя отображается в хедере

Пример 2 — негативный:
ID: TC-AUTH-NEG-001
Название: Авторизация с неверным паролем
Предусловия: Пользователь существует
Шаги: [...]
Ожидаемый результат: HTTP 401, сообщение «Неверный пароль»

Пример 3 — граничное значение:
ID: TC-AUTH-BND-001
Название: Авторизация с паролем минимальной длины
[...]

Сгенерируй аналогичные тест-кейсы для [НОВАЯ ФУНКЦИЯ],
строго соблюдая структуру и детализацию.

Аромат "Два прохода" Разделение задачи на две части: генерация и последующая самопроверка.

🧪 Пример для QA: Сгенерировали тест-кейсы одним промптом — вторым промптом отдайте их той же модели «в роли ревьюера» с чек-листом: так выловите пропуски и дубли до ручной проверки.

Проход 1: Генерация

Сгенерируй 10 тест-кейсов для функции поиска товаров по названию и категории.

Проход 2: Ревью

Теперь выступи в роли QA-ревьюера. Оцени сгенерированные тест-кейсы по следующему чек-листу:
- Покрыты ли все acceptance criteria?
- Есть ли негативные сценарии?
- Есть ли граничные значения?
- Нет ли дублирования?
- Достаточно ли конкретны шаги?
- Указаны ли тестовые данные?

Для каждого пункта укажи: ✅ / ❌ и рекомендации по улучшению.

Аромат "Матрица покрытия" Перекрестная проверка различных осей тестирования.

Создай матрицу покрытия для функции 'Авторизация'. 
Оси: 
1) Платформы (Web, iOS, Android)
2) Роли пользователей (Гость, Авторизованный пользователь, Администратор)
3) Состояния (новый пользователь, существующий пользователь)
4) Сценарии (успешная авторизация, неуспешная, сброс пароля)

Аромат "Оракул" Модель задумывается о том, как проверить корректность функции.

Ты — QA-эксперт. Для проверки корректности функции 'Расчет скидки' 
тебе даны бизнес-правила. Сформулируй список из 5-7 наблюдаемых 
сигналов («оракульских» утверждений), которые подтвердят, что функция 
работает как положено. Например: 'Система успешно применяет скидку Х% 
к товарам в корзине', 'В ответе API поле 'итоговая_стоимость' 
уменьшилось на Y%'

Метод: "Противоречивый эксперт" (Adversarial Review)

• Когда применять: Для критичных функций.

Ты — QA-инженер в роли «чёрного мыслителя». Найди максимальное 
количество способов сломать функцию [НАЗВАНИЕ].

Для каждого сценария укажи:
1. Что может пойти не так
2. Предпосылки (какие условия нужны)
3. Последствие для бизнеса/пользователя
4. Сложность воспроизведения (Easy/Medium/Hard)

Не ограничивай себя «разумными» сценариями — включай 
экстремальные и маловероятные случаи.

Метод: "Интервью с заказчиком"

• Когда применять: На ранних этапах при неполных требованиях.

Ты — опытный бизнес-аналитик. На основе описания функции 
составь 10–15 уточняющих вопросов для product-менеджера.

Вопросы должны выявлять:
- Неявные бизнес-правила
- Граничные случаи
- Зависимости от других систем
- Требования к производительности и доступности

Формат: нумерованный список с пояснением критичности каждого вопроса.

Метод Chain-of-Thought (Цепочка рассуждений, CoT) Техника предполагает, что вы просите модель "думать вслух" и показывать шаги своего рассуждения.

• Когда использовать: Для сложных логических задач (анализ причин сбоя).

Задача: Определить причину сбоя в работе функции "Поиск".

Ты — senior backend developer. Проанализируй следующие фрагменты 
кода и логи, чтобы найти причину сбоя. Рассуждай шаг за шагом.

Шаг 1: Проанализируй SQL-запрос в коде. Есть ли в нем очевидные ошибки?
Шаг 2: Проверь логи на наличие ошибок базы данных.
Шаг 3: Сопоставь время ошибок в логах с кодом.
Шаг 4: Сделай вывод о причине сбоя.

[Вставьте код и логи]

Метод Self-Consistency (Самосогласованность) Техника предполагает генерацию нескольких ответов на один и тот же вопрос с небольшими вариациями, а затем выбор наиболее часто встречающегося ответа.

Сгенерируй 3 независимых набора тест-кейсов для одной и той же функции.
Каждый набор должен быть полным и независимым от других.

Затем проанализируй:
- Какие тест-кейсы встречаются во всех трёх наборах? (критически важные)
- Какие уникальны для каждого набора? (дополнительные идеи)

Другие техники

Анти-паттерны — типичные ошибки

Практикум: исправление анти-паттернов

Напиши тесты для нашего приложения.

Задание: Найдите анти-паттерны в следующих промптах и предложите исправления.

1. Промпт: «Напиши тесты для нашего приложения.»
   • Анти-паттерны: слишком общий, без контекста, без формата.
2. Промпт: «Вот 100 страниц требований. Проанализируй и сгенерируй тест-план, тест-кейсы, автотесты и отчёт о покрытии.»
   • Анти-паттерны: сделай всё сразу, перегрузка контекстом.
3. Промпт: «Ты — QA. Сгенерируй тест-кейсы для формы.»
   • Анти-паттерны: без контекста (какая форма?), без ограничений, без формата.