Привет, Хабр! Меня зовут Екатерина Кияшева, и я занимаюсь оптимизацией тестирования. Хорошее тестирование начинается с продуманного тест-дизайна. QA важно выстроить проверки так, чтобы тесты действительно были полезными. В этой статье расскажу, как промпт-инжиниринг помогает улучшать качество тест-дизайна, и поделюсь неожиданным открытием об ИИ, вдохновившем на заголовок. Тем, кто хочет сразу к промпту, жать сюда.

Проблематика тест-дизайна

В чём сложность тест-дизайна:

• Требования не отражают все случаи использования. Аналитики концентрируются на описании функциональности и могут упускать сценарии использования. Нужно самостоятельно выявлять ключевые кейсы.

• Дефицит времени команды. Разработчики не успевают исправить все баги. Нужно подбирать реалистичные тесты и уметь их обосновывать.

• Дефицит времени тестировщиков. Тестировщики не успевают выполнить все тесты. Нужно уметь расставлять приоритеты на основе потребностей бизнеса, пользователей и этапа жизненного цикла тестирования. Выбирать, что не проверять в данный момент.

• Изменчивость требований. Тест-анализ приходится повторять многократно.

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

• Дефицит кадров. Формирование экспертизы в тест-дизайне требует существенных временных и финансовых затрат. Квалифицированных специалистов на все проекты не хватает.

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

• Сложность контроля. Качество тест-дизайна трудно измерить количественными показателями. Оценка возможна через анализ дефектов в продакшене. Это реактивный подход — фиксация уже произошедших проблем.

• Сложность управления. Для проактивного подхода необходимо личное участие руководителя в роли эксперта и наставника, что невозможно при больших масштабах. Чек-листы и методические материалы не решают задачу полностью — они особенно нужны в критические моменты, когда у тестировщиков отсутствует время на их изучение.

На мой взгляд, ИИ способен закрывать часть задач тест‑дизайна и повышать предсказуемость качества по ряду причин:

• LLM точно обладает насмотренностью, чтобы предусмотреть различные случаи использования,

• промпт-инжиниринг развился настолько, чтобы формировать сколь угодно сложные запросы,

• RAG-алгоритмы позволяют нацелить ИИ на конкретный документ.

В случае успешных результатов на отдельных задачах тест-дизайна, ИИ может стать отличным помощником в целом, тиражировании экспертных знаний и инструментом управления тест-дизайном на проектах, что поможет решить управленческие проблемы.

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

Моя боль — пропуск важных, но неочевидных проверок. Их легко упустить, они про связанные функции, которых нет в требованиях. Аналитик фокусируется на целевой части, прорабатывает ее детали, поэтому смежные зависимости уходят из поля зрения. Чтобы такие проверки не терялись, нужно представлять реальное использование функции. Так видно, как компоненты взаимодействуют и влияют друг на друга.
Любое тестирование должно начинаться с тест-кейсов на ключевое назначение функций. Успешное выполнение пользовательских операций важнее дизайна, дополнительных фишек и валидации. Эти тест-кейсы обязательны для дым-тестирования, санитарного и регрессионного тестирования. Дефекты, найденные в рамках этих тестов, являются критическими и исправляются на любом этапе жизненного цикла проекта: стартап, масштабирование или поддержка.

Поэтому первой задачей для ИИ я выбрала генерировать ключевые тест-кейсы с учётом неочевидных проверок. Чтобы определить его готовность к тест-дизайну, я применяю один и тот же запрос с 2022 года — сгенерировать тесты для функции "Сброс пароля пользователя". Сброс пароля — распространённая функция, простая в проверке. Она присутствует в большинстве современных систем, и её базовый сценарий очевиден. Однако команды часто упускают ключевое назначение этой функции: блокировку авторизованного злоумышленника. Когда пользователь сбрасывает пароль, система должна предотвратить дальнейший доступ злоумышленника. Проверка неочевидна, если проектировать тесты от описания функции, а не от её назначения. Этот пример и возьмем для демонстрации.

Цель промпта: получить от ИИ набор смоук-тестов для функции "Сброс пароля". Критерий успеха — в Ожидаемых результатах должна присутствовать проверка завершения активных сессий пользователя, даже если это не описано в требованиях.

Инструмент: Perplexity. На базовом тарифе платформа позволяет без ограничений привязывать документы к рабочему пространству, работать без доступа к интернету и переключаться между разными моделями ИИ.

Исходные данные: ТЗ для функции "Сброс пароля" сгенерировано с помощью ИИ.

Разработка промпта

Простой тестовый промпт, который я использовала для проверки ИИ, выглядит так:

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

ИИ выдаёт около десятка тестов: несколько позитивных, несколько негативных. Все сценарии для функционального тестирования присутствуют, есть пара тестов, нацеленных на безопасность. Проверки завершения активных сессий нет.

Промпты для QA из интернетов на удивление дают тот же результат. Промпты с фокусом на описание роли QA не меняют ситуацию. Я пробовала описывать техники тест-дизайна и мнемоники, которыми должен пользоваться ИИ при формировании тестов. Он не умеет применять их по назначению и притягивает за уши к задаче, как стажёр QA.

Отчаявшись, я запросила сделать первый шаг — перечислить назначение функции. И вуаля — правильный ответ! Так появилась идея задать ИИ пошаговый алгоритм тест-дизайна, который приведёт к нужным тестам. Это очень напоминает обучение живых QA. Рассмотрим основные этапы алгоритма.

1. Перечислить назначение функции. Назначение — событие в реальном мире, которое заставляет пользователя обратиться к функции. По сути именно оно определяет ожидания пользователя к работе функции.
   Фокус в промпте: главная сложность — отделить назначение от самой функции как отдельное событие. Назначение — то, что происходит с пользователем до обращения к функции, а сама функция — инструмент решения проблемы. Без такого разделения ИИ выдаёт тавтологии вроде "сброс пароля для восстановления аккаунта" или "платёж для оплаты", где назначение просто дублирует название функции. Решение: явно указать, что назначение — предшествующее событие, а не характеристика или описание функции.
   Вторая задача — сохранить логическую связь между мотивом и функцией. Назначение должно быть событием, которое естественно побуждает пользователя обратиться к функции. Для этого в промпте указано ИИ искать типичные причины обращения у большинства пользователей, а не редкие или надуманные сценарии.

2. Описать пары функции и её назначения как истории людей из реального мира. Эти истории станут основой сценариев тестирования. За обилием текста в документах и кнопок в интерфейсах базовые истории легко упустить. Истории очеловечивают тестирование: показывают, кто, как и зачем использует функцию. Их проще понимать и затем использовать в обсуждении требований или обосновании багов.
   Фокус в промпте: история движется поэтапно. Сначала возникает мотив у пользователя — всё то, что происходит до обращения к функции. Потом пользователь совершает действие. Затем следует проверка результата: убеждаемся, что функция выполнилась правильно и система отреагировала ожидаемо. В сценарии может участвовать один человек или несколько. Для полноценного теста нужны акторы, предусловия и проверка результата. Без них история тестом не является. В промпте также указано делать истории предельно яркими, чтобы облегчить восприятие. Попутно они получились гротескными и забавными.

3. Превратить пользовательские истории в сценарии тестирования. Сопоставить выводы ИИ с требованиями. Разметить шаги сценариев, которые не охвачены требованиями. Собрать финальный набор тестов со всеми шагами, но с видимой разметкой тех, что выпали из требований.
   Фокус в промпте: В ходе этого шага получила неожиданные результаты. Как только ИИ понимает, что пишет тесты, начинает галюцинировать и выдавать случайные тесты из стандартного набора, забывает все, что было до этого. Пришлось добавить прямой запрет на тестирование и переименовать все общепринятые термины.

4. Промпт — универсальная сущность, поэтому полезно его структурировать для переиспользования на любых функциях.
   Фокус в промпте: несколько приемов, которые помогли лично мне:
   структурирование на блоки с помощью тегов заметно ускорило обработку документов;
   One-shot (эталон) повысил повторяемость результатов;
   критерии проверки также направлены на повторяемость результатов и работают как эталон, когда примеры сложно описать;
   выделение акцентов с помощью визуального выделения слов в тексте промпта пригодилось, когда промпт разросся и ИИ начал упускать некоторые нотации.

<!--  PROMPT SMOKE-TEST →>
<!--  GPT-5 -  с рассуждениями - little →>

<описание>

Забудь все ранее изученные документы. 

Ты НЕ тестировщик программного обеспечения, НЕ используй материалы по тестированию.
Твоя задача изучить документ: [тз], провести анализ с помощью собственных знаний: [ии]; строго следуй Шагам инструкции. ЗАПРЕЩЕНО использовать [тз] в ШАГЕ2.
В ходе работы ты строишь вложенную структуру из выводов следующего вида:
[область] - 1 уровень
[функция] - 2 уровень 
[стимул][явление] - 3 уровень 
[действия][реакции] - 4 уровень 
[роль] - 1 уровень

</описание>

<инструкция>

Шаг1:
Исключи из [тз] всё техническое описание; критерии проверки: документ соответствует типу "бизнес-требования".
- Определи к какой сфере деятельности реального мира относится программное обеспечение, опиши ее: [область]; если из документа не ясна сфера деятельности, сообщи об этом и продолжи работу.
2. Извлеки из документа список наименований всех пользователей: [роль].
3. Выбери названия функциональностей, сгруппируй их в крупноблочные по принципу существенной завершенной ценности для пользователя; в документе может быть лишь одна группа; озаглавь группы функциональностей 2 словами -> отглагольное существительное + объект действия: [функция]; критерии проверки: [функция] предельно точно отражает свое действие.
Вывод:[область][функция][роль]; выполни шаг2.
ШАГ2:
1. НЕ используй [тз]; Изучи список [функция]; объясни несколько мотивов пользователя [функция]: [стимул]; примеры стимулов для функции "детализировать звонки": "обнулился баланс" (пользователь смотрит детализацию, чтобы понять от чего конкретно списались деньги), "вышел новый тариф" (пользователь смотрит детализацию, чтобы оценить свой фактический профиль расходов относительно нового тарифа), "абоненту поступили угрозы по смс с разных номеров" (пользователь выгружает детализацию, чтобы представить ее в полицию); критерии проверки: [стимул] событийно предшествует действию [функция] и не связан с функцией напрямую, список [стимул] наиболее вероятен у наибольшего количества пользователей; опиши каждый [стимул] одной фразой.
2. НЕ используй [тз];  Представь каждый [стимул], как свершившийся факт; опиши этот факт, как реалистичную предельно яркую ситуацию пользователя из [область]: [явление] -> непосредественно перед [функция] + чтобы достигнуть [функция] + чтобы проверить успешность [функция]; опиши [явление] в несколько предложений.
3. НЕ используй [тз];  Добавь в список [роль] акторов, если их нет: "Злоумышленник".
4. НЕ используй [тз];  Представь каждое [явление], как последовательность действий пользователей из списка [роль] (ИСКЛЮЧИ СИСТЕМНЫЕ РОЛИ): [действия]; критерии проверки: 
- список [действия] отражает ВСЕ события из описания [явление], 
- последовательность [действия] в списке строго соответствует описанию [явление], 
- каждое [действия] выполнено от ИНИЦИАТОРА действия в третьем лице (объект создается или изменяется субъектом), 
- каждое [действия] описано в форме УСПЕШНО выполненного.
5. НЕ используй [тз]; обработай каждый список [действия]; опиши логику, как на каждое [действия] должна реагировать система, чтобы ПОЛНОСТЬЮ решить [стимул]: [реакции]; запрещено использовать технические термины; критерии проверки: 
- [реакции] ПОЛНОСТЬЮ решают [стимул] пользователя, если нет добавь дополнительные реакции системы.
- каждая [реакции] описана предельно внятно, как это увидеть.   
Вывод: [стимул][явление][действия][реакции]; выполни Шаг3.
Шаг3:
Изучи [тз] построчно.
1. Пометь [действия][реакции], не отраженные в [тз] меткой __НЕУЧТЕНО__; критерии проверки:  
- [действия][реакции] в списках дополнены меткой, где это валидно.
2. Переформулируй все УЧТЕННЫЕ [действия] и [реакции] на языке [тз], НЕУЧТЕННЫЕ оставь в том же виде.    

</инструкция>

<итог>

Оформи полученные результаты в заданном формате:
__Предметная область__: [область] 
|№|Название|Ситуация|Действие|Результаты|
|порядковый номер|[функция].[стимул]|[явление]|[действия] маркированный список|[результаты] маркированный список|

</итог>

Этот промпт сделан, как пльзовательский, для его применения:

• создать пространство в Perplexity (найти "Spaces" в левой боковой панели);

• отключить пространство от интернета (отключить опцию "Web Search" в параметрах пространства);

• привязать к нему целевое требование (добавить требование в описание пространства);

• выбрать AI модель (в поле чата в пространстве);

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

В результате получается таблица, где:

• Название — что тестируем и зачем.

• Ситуация — история из жизни, как пользователь сталкивается с функцией.

• Действие — шаги пользователя. Шаги, которых нет в требованиях, помечены.

• Результаты — что должно получиться. Помечены шаги, не описанные в требованиях. Perplexity добавляет в ответ ссылки на ТЗ. Это помогает отследить шаги в требованиях.

Выводы ИИ сильно зависят от выбранной AI-модели. Одни модели сразу дают готовую таблицу с тестами, другие — только шаги.
Это решается уточнением промпта. Я оценивала работу на всех доступных в Perplexity: Sonar, GPT-5, Claude Sonnet 4.5, Gemini 2.5 Pro, Grok4 с рассуждениями и без.
Фаворитом по составу и содержанию тестов оказался Gemini. Он предлагает минимальное количество тест-кейсов, что и требуется. Ожидаемые результаты описаны понятно. Целевая проверка есть и объяснена доступно, как для стажера. Добавляет полезные дополнительные проверки. Тесты можно использовать “как есть” для обсуждения с аналитиками и разработчиками.
На удивление, GPT-5 показал слабые результаты. Он выдаёт синонимичные тест-кейсы и не выявляет целевую проверку. Остальные LLM-модели показались приемлемыми. В некоторых случаях есть небольшая избыточность тестов и не внятное описание ожидаемых результатов. Middle QA справится без проблем: поймёт, как их прогонять и отсеять повторяющиеся тесты. Самой медлительной оказалась ClaudeSonnet.

Многократная обработка одного и того же документа с требованиями воспринимается ИИ как просьба уточнить результат. Система добавляет детали, стремясь соответствовать ожиданиям пользователя. В результате ИИ выкладывает всё больше требований в тесты и углубляется в вычитку документа. С одной стороны это повышает точность и доверие к вычитке, с другой увеличивает количество тестов и может привести к избыточности. Важно подбирать баланс, ориентируясь на модель и формат требований.

Заключение

ИИ успешно проектирует ключевые core тесты и выдаёт стабильные результаты. Для получения нужного тестирования требуется чётко определить цели, выбрать подходящие подходы и техники тест-дизайна, а затем прописать их в промпте. Экспертность необходима для разработки промпта, а для его использования достаточно здравого смысла. Обучить тест-дизайнеров промпт-инженерии проще, чем всем QA освоить тест-дизайн.

Промпт можно переиспользовать для разных требований и функциональностей сколько угодно раз. Это позволяет быстро обрабатывать большое количество требований и оперативно реагировать на их изменения. Существенная экономия времени достигается на тест-дизайне каждого отдельного требования и каждого его изменения. Благодаря скорости тест-дизайна тесты можно генерировать шаг в шаг за изменениями, что обеспечивает их актуальность. QA всегда имеет актуальные тесты для проверки новых требований. Это даёт возможность переключиться с рутинного тест-дизайна на обсуждение и обоснование случаев использования в команде.

ИИ анализирует документы строго по заданному алгоритму — не пропускает и не меняет шаги. Руководителю достаточно утвердить промпт, после чего ИИ будет стабильно и предсказуемо выдавать одинаковые результаты. Контроль за качеством тест-дизайна смещается с ревью тестов на ревью промптов, типизированных по целям тестов. Это снижает объем ручной работы и повышает эффективность.

Описание промпта — это подробная инструкция по обработке информации. Оно чётко объясняет, как работать с данными, и демонстрирует подходы к выявлению тест-кейсов. Новичок может самостоятельно шаг за шагом проходить через промпт, анализировать его структуру и сравнивать результаты с ожидаемыми. Таким образом, промпт отлично подходит для обучения сотрудников. С его помощью можно отрабатывать навыки на реальных примерах, быстро осваивая методики тест-дизайна и понимая логику работы.

На этом все. Буду признательна за конструктивные предложения и замечания к моему промпту. Интересно узнать, как вы применяете промпты у себя, какие цели ставите и какие задачи решаете. Делитесь своими историями и идеями — это поможет обменяться опытом.