Приемочные тесты из промптов: как из описания фичи в чате быстро сделать 5-10 сценариев (happy path и крайние случаи), чтобы качество росло без громоздких наборов тестов.
Фича, которая родилась в переписке, кажется понятной ровно до момента приемки. Один и тот же текст разные люди читают по-разному: продакт думает о пользе, дизайнер - о поведении интерфейса, разработчик - об ограничениях, тестировщик - о том, где сломается. В итоге все кивают, но согласия по сути нет.
Частая подмена - вместо приемки делают «проверки». Проверка выглядит так: «я нажал кнопку, вроде работает». Приемочный тест - это обещание в проверяемом виде: при каких условиях, что именно должно произойти и что считаем ошибкой. А критерии приемки - короткие правила, по которым фича считается готовой. Они описывают поведение для пользователя, а не то, как вы это реализовали.
Отсюда и конфликт: фича описана в чате, а доказать, что она сделана правильно, нечем. Баги становятся «спорными»: «так и задумано», «нет, это точно ошибка», «в промпте было иначе». Набор приемочных сценариев решает эту боль даже в маленькой команде: расплывчатую идею он превращает в наблюдаемые результаты.
Почему обычно хватает 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 хочет экспортировать исходники проекта». В контексте сразу важно, создан ли проект, кому доступен экспорт и какое сообщение увидит пользователь при отказе. А в «не делаем» можно зафиксировать: «не добавляем новые форматы архива» и «не меняем состав файлов». Это экономит споры на приемке и делает сценарии короткими.
Сначала превратите фичу в один понятный счастливый путь. Запишите его как короткую историю на 3-6 действий: стартовое состояние, ключевое действие, ожидаемый итог, что пользователь видит на экране и что сохраняется в системе.
Если вы собираете фичу через чат (например, в TakProsto), отдельно зафиксируйте то, что реально можно воспроизвести: какие поля вводятся, какие кнопки нажимаются и какое состояние должно получиться после генерации или деплоя.
Дальше добавьте пограничные ситуации. Не пытайтесь охватить все. Возьмите источники, которые чаще всего ломают релизы: некорректный ввод, границы и лимиты, повторы действий, права и роли, сбои сети. Часто забывают еще один источник - параллельные действия: два пользователя меняют одну сущность, или один пользователь подтверждает действие в двух вкладках.
Теперь каждую ситуацию оформите одинаково, чтобы спорить было не о формулировках, а о поведении:
Дано: ...
Когда: ...
Тогда: ...
В «Тогда» добавляйте не только «операция успешна», но и наблюдаемые признаки: сообщение, состояние кнопки, индикатор загрузки, текст ошибки, куда попал пользователь после действия. Приемка почти всегда проходит глазами, а не логами.
Финальная чистка - то, что делает набор живым. Оставьте 5-10 сценариев, которые дают максимум пользы: один на основной результат, остальные на самые дорогие ошибки. Уберите повторы, объедините мелкие вариации и проверьте, что каждый сценарий заканчивается конкретным ожидаемым итогом.
Сценарий должен читаться как короткая инструкция и не оставлять места для трактовок.
Формат Given-When-Then удобен, когда нужна однозначность.
Пример:
Дано: пользователь авторизован и на странице профиля Когда: он меняет email на новый и нажимает «Сохранить» Тогда: показывается сообщение об успехе, а в профиле отображается новый email
Держите сценарии короткими и не смешивайте несколько проверок в одном тексте. Если хочется одновременно проверить и сообщение, и письмо, и запись в истории - лучше разделить на 2-3 сценария.
Если сценарии будут читать люди без привычки к тестовым шаблонам, пишите проще: 2-5 шагов и один главный ожидаемый результат.
Данные описывайте человеческим языком, без внутренней кухни. Не «создать пользователя U123 с флагом isBeta», а «пользователь с пустым профилем, без заполненного телефона». Если важны условия, укажите их явно: тариф, роль, язык, регион, наличие прав.
Полезная договоренность: что считается успехом и какая ошибка является нормальной. Например: «успех - данные сохранены и видно подтверждение», «нормальная ошибка - показано понятное сообщение, если email уже занят». Это резко снижает споры на приемке.
С happy path обычно проблем нет. Сложнее вспомнить, где фича ломается. Эти источники почти всегда дают нужные 4-9 «краев»:
Ввод и ограничения: пусто, слишком длинно, неверный формат, пробелы, запрещенные символы.
Права, роли и контекст: гость, обычный пользователь, админ; доступ только к части данных; роль поменялась в процессе.
Состояния данных и конкуренция: объект уже существует, удален, в архиве; две правки одновременно.
Повторы: двойной клик, повторная отправка формы, перезагрузка страницы.
Сбои и частичный успех: таймаут, ошибка сервера, пропала сеть; данные создались, но подтверждение не дошло.
Чтобы не держать все в голове, помогает короткий набор вопросов:
Пример: вы добавили кнопку «Экспортировать исходники» в TakProsto. Edge cases тут не только «экспорт скачался», но и «проект в архиве», «у пользователя нет прав», «экспорт запустили второй раз», «сервер вернул ошибку и нужно понятное сообщение», «файл получился пустым и это должно считаться ошибкой».
Представим фичу для подписочного сервиса: пользователь меняет тариф, оплата проходит, и он получает чек. Один хороший промпт уже содержит основу для приемки.
Пример промпта фичи (как его мог написать продакт):
«Пользователь с ролью Владелец может сменить тариф с Free на Pro. При успешной оплате тариф меняется сразу, лимиты обновляются, пользователю показывается подтверждение и отправляется чек на email. Если оплата не прошла, тариф не меняется, показываем понятную причину и предлагаем попробовать еще раз».
Ниже - 8 сценариев в формате Given-When-Then.
Happy path: успешная смена тарифа и чек Given: пользователь - Владелец, текущий тариф Free, платежный метод валиден When: выбирает Pro, подтверждает оплату Then: статус оплаты "Успешно", тариф становится Pro без перезагрузки, в интерфейсе видно новый тариф и дату, показано сообщение "Тариф изменен", чек отправлен на email и отображается в истории платежей
Нет прав на смену тарифа Given: пользователь - не Владелец (например, Участник) When: открывает страницу тарифов и пытается нажать "Сменить" Then: действие недоступно или блокируется, показываем сообщение "Недостаточно прав", никаких попыток оплаты не создается
Недостаточно средств (или лимит банка) Given: платежный метод выбран, но средств недостаточно When: пользователь подтверждает оплату Then: статус "Неуспешно", тариф остается прежним, показываем понятную причину и кнопку "Попробовать снова" без двойного списания
Пользователь отменил оплату на стороне платежа Given: пользователь начал смену тарифа When: в окне оплаты нажимает "Отмена" Then: статус "Отменено", тариф не меняется, в интерфейсе сообщение "Оплата отменена", есть путь вернуться к выбору тарифа
Важно заранее договориться о текстах сообщений и о том, где они видны: баннер, модальное окно, строка в истории платежей. Тогда проверка перестает быть спором «нормально же».
Повторный клик и защита от двойной оплаты Given: пользователь нажал "Оплатить" и запрос ушел When: он кликает кнопку еще раз или обновляет страницу Then: создается только один платеж, показываем статус "В обработке", итог один чек, тариф меняется один раз
Неверные реквизиты (ошибка в карте или истек срок) Given: сохраненный платежный метод невалиден When: пользователь пытается оплатить Then: видит сообщение "Проверьте реквизиты" (или аналог), тариф не меняется, предлагается выбрать другой метод оплаты
Сбой сети после оплаты: платеж успешен, UI не обновился Given: платеж прошел, но клиент не получил ответ из-за обрыва When: пользователь возвращается в приложение Then: по данным сервера тариф уже Pro, интерфейс догружает актуальное состояние, показываем подтверждение без повторной оплаты
Уже на нужном тарифе Given: текущий тариф уже Pro When: пользователь открывает тарифы и пытается выбрать Pro снова Then: показываем "У вас уже Pro" и убираем путь к оплате
Чтобы превратить это в критерии приемки для релиза, по каждому сценарию зафиксируйте три вещи: что меняется в данных (тариф, запись платежа, чек), что видит пользователь (статусы, тексты, кнопки), что не должно случиться (двойная оплата, смена тарифа при ошибке). Этого достаточно, чтобы уверенно принять фичу без огромного набора тестов.
Сценарии дают пользу только тогда, когда их можно выполнить одинаково сегодня, завтра и другим человеком. Если они читаются как пожелания, качество не растет.
Чаще всего ломает ценность вот что:
Хороший признак полезного сценария - он помещается в 3-5 строк Given/When/Then и не требует уточняющих вопросов.
Если у вас уже есть 5-10 сценариев, финальная проверка может занять 10 минут. Цель - не найти все баги, а убедиться, что вы защищены от самых дорогих провалов: пользователь не может сделать базовое действие, видит непонятную ошибку или случайно ломает данные.
Пробегитесь по набору и проверьте:
Если сценариев больше 10, чаще всего там дубли. Слейте похожие случаи или оставьте один более рискованный.
Чтобы не растягивать приемку, помогает простой ритм:
Сценариям нужно место в обычном потоке работы, иначе они превращаются в документ «на потом». Рабочий ритм простой: сформулировали фичу, зафиксировали 5-10 сценариев, приняли по ним, после правок обновили сценарии вместе с изменениями.
Роли распределяются гибко: продакт отвечает за смысл и критерии готовности, разработчик добавляет важные границы (валидации, статусы, ограничения), тестировщик (если он есть) помогает добрать edge cases и привести формулировки к одному стилю. Если тестировщика нет, обычно хватает совместной сессии на 10-15 минут перед реализацией.
Если вы делаете фичи в TakProsto, удобно держать сценарии рядом с промптом в planning mode: так они становятся коротким контрактом, к которому легко вернуться при правках. А когда нужно быстро проверить изменения перед релизом, помогают снимки и откат: можно безопасно вернуться к рабочему состоянию и перепроверить сценарии еще раз.
Минимальная привычка, которая обычно приживается без боли:
Когда сценарии становятся частью каждого изменения, качество растет не за счет огромных тест-сьютов, а за счет ясных ожиданий и общего понимания, что именно значит «готово».
Потому что промпт чаще описывает намерение («что хотим»), но не описывает проверяемое поведение («как поймём, что готово»). Без сценариев на приемке начинаются разные трактовки: что считать успехом, какие ошибки нормальны, какие ограничения важны.
Критерии приемки — это короткие правила «когда считаем готово» (например, что должно быть видно пользователю, какие статусы допустимы). Приемочные сценарии (тесты) — это конкретные проверки в формате Дано / Когда / Тогда или «шаги + ожидаемый результат», которые можно повторить и получить тот же итог.
Обычно достаточно:
Этого хватает, чтобы зафиксировать смысл и не превратить приемку в отдельный проект.
Держите один и тот же каркас:
И важно: один сценарий — одна основная проверка. Если хотите проверить и письмо, и запись в истории — лучше разделить на два сценария.
Начните с цели пользователя и добавьте минимальный контекст:
Так вы заранее фиксируете условия, из-за которых чаще всего возникают «спорные баги».
Берите 5 источников, которые почти всегда дают полезные «края»:
Выберите из них 4–7 пунктов, которые наиболее рискованные именно для вашей фичи.
Пишите «Тогда» так, чтобы это можно было увидеть без чтения логов:
Фразы вроде «всё работает» или «операция успешна» заменяйте на конкретный наблюдаемый итог.
Добавьте сценарий про идемпотентность:
Это один из самых частых источников дорогих ошибок.
Зафиксируйте ожидаемое поведение при сбое:
Даже один сценарий про «таймаут/обрыв после успешного действия» сильно снижает риск спорных ситуаций.
Удобный минимум:
Так сценарии остаются живыми и реально помогают в приемке.