Приемочные тесты из промптов: 5-10 сценариев на фичу

Проблема: фича описана в чате, а проверять нечем

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

Частая подмена - вместо приемки делают «проверки». Проверка выглядит так: «я нажал кнопку, вроде работает». Приемочный тест - это обещание в проверяемом виде: при каких условиях, что именно должно произойти и что считаем ошибкой. А критерии приемки - короткие правила, по которым фича считается готовой. Они описывают поведение для пользователя, а не то, как вы это реализовали.

Отсюда и конфликт: фича описана в чате, а доказать, что она сделана правильно, нечем. Баги становятся «спорными»: «так и задумано», «нет, это точно ошибка», «в промпте было иначе». Набор приемочных сценариев решает эту боль даже в маленькой команде: расплывчатую идею он превращает в наблюдаемые результаты.

Почему обычно хватает 5-10 сценариев на фичу? Этого достаточно, чтобы покрыть главное и самые дорогие провалы, но не превратить приемку в отдельный проект. Такой набор легко прочитать, согласовать и реально прогнать перед релизом.

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

Простой пример: в чате написали «добавьте вход по коду из SMS». Без сценариев это может означать и автоподстановку кода, и таймер повторной отправки, и блокировку после 5 попыток, и разные тексты ошибок. 5-10 сценариев фиксируют смысл до разработки. Это полезно и когда вы работаете в обычном бэклоге, и когда собираете фичу через чат в TakProsto.

Коротко о терминах: промпт, критерии приемки, сценарий

Фича-промпт - сообщение (или цепочка сообщений) в чате, где вы описываете, что должна делать функция. В TakProsto это обычно просьба сделать экран, API или бизнес-логику простыми словами.

Проблема в том, что промпт чаще отвечает на «что хотим», но редко отвечает на «как проверим». Поэтому споры переезжают в приемку.

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

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

Часто удобно записывать в стиле Given When Then:

Given (дано): стартовые условия When (когда): действие пользователя или системы Then (тогда): что должно получиться

Happy path - главный сценарий, который должен работать всегда. Edge cases - «края», где чаще всего ломается логика: пустые или слишком длинные значения, неожиданный формат, повторные действия, истекшая сессия, конфликты данных.

Если коротко: промпт описывает задумку, критерии приемки фиксируют правила, а сценарии превращают правила в конкретные проверки.

Как подготовить промпт, чтобы из него получились тесты

Промпт для разработки часто звучит как пожелание: «сделай кнопку», «добавь фильтр», «пусть сохраняется черновик». Для приемки этого мало: проверять нужно не идею, а наблюдаемое поведение.

Начните с цели пользователя. Не «добавить форму», а «пользователь хочет быстро развернуть приложение и увидеть, что оно доступно по домену». Цель помогает отделить важное от «просто хотелось бы» и сразу подсказывает happy path.

Дальше зафиксируйте контекст, потому что одна и та же фича ведет себя по-разному в разных условиях. Пишите конкретно: роль (владелец проекта или участник), тариф (free/pro/business), устройство (мобильный/десктоп), состояние аккаунта (не авторизован, закончились кредиты), состояние данных (пустой проект, проект уже развернут).

Мини-шаблон промпта, который удобно превращать в сценарии

Фича: <название>
Цель: <зачем пользователю это>
Контекст: <роль, тариф, устройство, состояние аккаунта, исходные данные>
Входы: <что пользователь вводит/нажимает, какие параметры>
Ожидаемый результат: <что видим на экране и/или в данных>
Ограничения: <лимиты, статусы, права, ошибки>
Не делаем: <1-2 пункта, чтобы не расширять область>

Чтобы область не расползалась, отдельно выпишите входы и выходы. «Ввод» - это не только поле, но и файл, переключатель, выбор тарифа, подтверждение по почте. «Выход» - не «успешно», а конкретика: создан проект, появился статус, сгенерирован билд, включилась кнопка отката.

Отдельно полезно зафиксировать ограничения, которые чаще всего ломают приемку: права и доступы, лимиты и квоты, статусы и переходы, ошибки и восстановление, время ожидания.

Пример: «Пользователь на тарифе free хочет экспортировать исходники проекта». В контексте сразу важно, создан ли проект, кому доступен экспорт и какое сообщение увидит пользователь при отказе. А в «не делаем» можно зафиксировать: «не добавляем новые форматы архива» и «не меняем состав файлов». Это экономит споры на приемке и делает сценарии короткими.

Пошаговый процесс: из одного промпта в 5-10 сценариев

Сначала превратите фичу в один понятный счастливый путь. Запишите его как короткую историю на 3-6 действий: стартовое состояние, ключевое действие, ожидаемый итог, что пользователь видит на экране и что сохраняется в системе.

Если вы собираете фичу через чат (например, в TakProsto), отдельно зафиксируйте то, что реально можно воспроизвести: какие поля вводятся, какие кнопки нажимаются и какое состояние должно получиться после генерации или деплоя.

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

Теперь каждую ситуацию оформите одинаково, чтобы спорить было не о формулировках, а о поведении:

Дано: ...
Когда: ...
Тогда: ...

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

Финальная чистка - то, что делает набор живым. Оставьте 5-10 сценариев, которые дают максимум пользы: один на основной результат, остальные на самые дорогие ошибки. Уберите повторы, объедините мелкие вариации и проверьте, что каждый сценарий заканчивается конкретным ожидаемым итогом.

Удобные форматы сценариев, чтобы их читали все

Сценарий должен читаться как короткая инструкция и не оставлять места для трактовок.

«Дано-Когда-Тогда» для точности

Формат Given-When-Then удобен, когда нужна однозначность.

Пример:

Дано: пользователь авторизован и на странице профиля Когда: он меняет email на новый и нажимает «Сохранить» Тогда: показывается сообщение об успехе, а в профиле отображается новый email

Держите сценарии короткими и не смешивайте несколько проверок в одном тексте. Если хочется одновременно проверить и сообщение, и письмо, и запись в истории - лучше разделить на 2-3 сценария.

«Шаги + ожидаемый результат» для нетехнических команд

Если сценарии будут читать люди без привычки к тестовым шаблонам, пишите проще: 2-5 шагов и один главный ожидаемый результат.

Данные описывайте человеческим языком, без внутренней кухни. Не «создать пользователя U123 с флагом isBeta», а «пользователь с пустым профилем, без заполненного телефона». Если важны условия, укажите их явно: тариф, роль, язык, регион, наличие прав.

Полезная договоренность: что считается успехом и какая ошибка является нормальной. Например: «успех - данные сохранены и видно подтверждение», «нормальная ошибка - показано понятное сообщение, если email уже занят». Это резко снижает споры на приемке.

Где брать edge cases: 5 источников почти для любой фичи

С happy path обычно проблем нет. Сложнее вспомнить, где фича ломается. Эти источники почти всегда дают нужные 4-9 «краев»:

1. Ввод и ограничения: пусто, слишком длинно, неверный формат, пробелы, запрещенные символы.

2. Права, роли и контекст: гость, обычный пользователь, админ; доступ только к части данных; роль поменялась в процессе.

3. Состояния данных и конкуренция: объект уже существует, удален, в архиве; две правки одновременно.

4. Повторы: двойной клик, повторная отправка формы, перезагрузка страницы.

5. Сбои и частичный успех: таймаут, ошибка сервера, пропала сеть; данные создались, но подтверждение не дошло.

Чтобы не держать все в голове, помогает короткий набор вопросов:

• Что если ввод пустой, слишком большой или в неверном формате?
• Что увидит пользователь без прав, гость и админ?
• Что если объект уже есть, удален, архивирован или изменен кем-то еще?
• Что будет при повторной отправке и двойном клике?
• Как выглядит поведение при ошибке сервера, таймауте, пропаже сети и частичном успехе?

Пример: вы добавили кнопку «Экспортировать исходники» в TakProsto. Edge cases тут не только «экспорт скачался», но и «проект в архиве», «у пользователя нет прав», «экспорт запустили второй раз», «сервер вернул ошибку и нужно понятное сообщение», «файл получился пустым и это должно считаться ошибкой».

Пример: один промпт и 8 сценариев без лишней теории

Представим фичу для подписочного сервиса: пользователь меняет тариф, оплата проходит, и он получает чек. Один хороший промпт уже содержит основу для приемки.

Пример промпта фичи (как его мог написать продакт):

«Пользователь с ролью Владелец может сменить тариф с Free на Pro. При успешной оплате тариф меняется сразу, лимиты обновляются, пользователю показывается подтверждение и отправляется чек на email. Если оплата не прошла, тариф не меняется, показываем понятную причину и предлагаем попробовать еще раз».

Ниже - 8 сценариев в формате Given-When-Then.

1. Happy path: успешная смена тарифа и чек Given: пользователь - Владелец, текущий тариф Free, платежный метод валиден When: выбирает Pro, подтверждает оплату Then: статус оплаты "Успешно", тариф становится Pro без перезагрузки, в интерфейсе видно новый тариф и дату, показано сообщение "Тариф изменен", чек отправлен на email и отображается в истории платежей

2. Нет прав на смену тарифа Given: пользователь - не Владелец (например, Участник) When: открывает страницу тарифов и пытается нажать "Сменить" Then: действие недоступно или блокируется, показываем сообщение "Недостаточно прав", никаких попыток оплаты не создается

3. Недостаточно средств (или лимит банка) Given: платежный метод выбран, но средств недостаточно When: пользователь подтверждает оплату Then: статус "Неуспешно", тариф остается прежним, показываем понятную причину и кнопку "Попробовать снова" без двойного списания

4. Пользователь отменил оплату на стороне платежа Given: пользователь начал смену тарифа When: в окне оплаты нажимает "Отмена" Then: статус "Отменено", тариф не меняется, в интерфейсе сообщение "Оплата отменена", есть путь вернуться к выбору тарифа

Важно заранее договориться о текстах сообщений и о том, где они видны: баннер, модальное окно, строка в истории платежей. Тогда проверка перестает быть спором «нормально же».

5. Повторный клик и защита от двойной оплаты Given: пользователь нажал "Оплатить" и запрос ушел When: он кликает кнопку еще раз или обновляет страницу Then: создается только один платеж, показываем статус "В обработке", итог один чек, тариф меняется один раз

6. Неверные реквизиты (ошибка в карте или истек срок) Given: сохраненный платежный метод невалиден When: пользователь пытается оплатить Then: видит сообщение "Проверьте реквизиты" (или аналог), тариф не меняется, предлагается выбрать другой метод оплаты

7. Сбой сети после оплаты: платеж успешен, UI не обновился Given: платеж прошел, но клиент не получил ответ из-за обрыва When: пользователь возвращается в приложение Then: по данным сервера тариф уже Pro, интерфейс догружает актуальное состояние, показываем подтверждение без повторной оплаты

8. Уже на нужном тарифе Given: текущий тариф уже Pro When: пользователь открывает тарифы и пытается выбрать Pro снова Then: показываем "У вас уже Pro" и убираем путь к оплате

Чтобы превратить это в критерии приемки для релиза, по каждому сценарию зафиксируйте три вещи: что меняется в данных (тариф, запись платежа, чек), что видит пользователь (статусы, тексты, кнопки), что не должно случиться (двойная оплата, смена тарифа при ошибке). Этого достаточно, чтобы уверенно принять фичу без огромного набора тестов.

Типичные ошибки, из-за которых тесты не помогают

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

Чаще всего ломает ценность вот что:

• Размытые формулировки. «Должно работать», «быстро», «удобно» не проверяются. Лучше: «письмо приходит за 2 минуты», «ошибка показывается под полем», «кнопка недоступна, пока форма пустая».
• Один сценарий - несколько проверок. Когда в одном тексте и регистрация, и оплата, и письмо, вы не понимаете, что именно сломалось. Разделяйте по результатам.
• Нет исходных данных и состояния. Сценарий без контекста почти всегда превращается в спор. Укажите минимум: кто пользователь и что уже есть в системе.
• Проверяете внутренности вместо поведения. «Запрос ушел», «в базе появилась строка», «сгенерировался код» - детали реализации. В приемке важнее то, что видит пользователь: сообщение, статус, созданный объект, доступность действия.
• Гонка за количеством. 30 сценариев на простую фичу почти всегда означают повторы, которые никто не прогоняет.

Хороший признак полезного сценария - он помещается в 3-5 строк Given/When/Then и не требует уточняющих вопросов.

Быстрый чеклист перед релизом: 10 минут на самопроверку

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

Пробегитесь по набору и проверьте:

• Есть один понятный happy path с итогом. Пользователь видит конкретный результат.
• Есть хотя бы один сценарий про права и отказ. Отказ должен выглядеть как понятное сообщение, а не «что-то не сработало».
• Есть минимальная валидация ввода. Обычно хватает трех случаев: пусто, неверный формат, границы.
• Есть защита от повторов. Двойной клик, повторная отправка, обновление страницы.
• Есть сценарий про ошибку сети/сервера. И текст должен подсказывать, что делать дальше.

Если сценариев больше 10, чаще всего там дубли. Слейте похожие случаи или оставьте один более рискованный.

Чтобы не растягивать приемку, помогает простой ритм:

1. 3 минуты: прочитайте сценарии вслух и уберите двусмысленность.
2. 5 минут: прогоните по одному примеру на каждый пункт чеклиста.
3. 2 минуты: убедитесь, что сценарии помещаются на одну страницу и читаются без контекста из головы.

Следующие шаги: сделать сценарии привычной частью разработки

Сценариям нужно место в обычном потоке работы, иначе они превращаются в документ «на потом». Рабочий ритм простой: сформулировали фичу, зафиксировали 5-10 сценариев, приняли по ним, после правок обновили сценарии вместе с изменениями.

Роли распределяются гибко: продакт отвечает за смысл и критерии готовности, разработчик добавляет важные границы (валидации, статусы, ограничения), тестировщик (если он есть) помогает добрать edge cases и привести формулировки к одному стилю. Если тестировщика нет, обычно хватает совместной сессии на 10-15 минут перед реализацией.

Если вы делаете фичи в TakProsto, удобно держать сценарии рядом с промптом в planning mode: так они становятся коротким контрактом, к которому легко вернуться при правках. А когда нужно быстро проверить изменения перед релизом, помогают снимки и откат: можно безопасно вернуться к рабочему состоянию и перепроверить сценарии еще раз.

Минимальная привычка, которая обычно приживается без боли:

• Перед началом работы - 5-10 сценариев (happy path плюс несколько краев).
• Перед приемкой - прогон вручную и отметка «пройдено/не пройдено».
• После правок - обновить сценарии, если поведение поменялось.
• После релиза - добавить 1-2 сценария по итогам реальных обращений.

Когда сценарии становятся частью каждого изменения, качество растет не за счет огромных тест-сьютов, а за счет ясных ожиданий и общего понимания, что именно значит «готово».