Как составить проверяемую пользовательскую историю.
Пользовательская история должна описывать возможность и её значение. Не маскируйте техническую задачу под пользовательскую пользу.
Адаптируйте процесс под свою задачу.
Назовите пользователя, возможность и причину её важности, затем добавьте условия приёмки, делающие результат наблюдаемым. Ограничьте историю так, чтобы завершение можно было проверить в конкретном сценарии.
- Что вы предоставляете
- Проблема пользователя и желаемая возможность.
- Что вы получите
- Истории с фокусом на пользователе и границами объёма.
Посмотрите входные данные и результат.
Иллюстративные входные и выходные данные · учебный пример, а не реальный запуск WebAct
Полей ввода: Пример
Catalog manager needs to identify changed supplier prices.
Готовый пример
As a catalog manager, I want to review changed prices so I can approve updates before importing them.
Добавьте эти данные в промпт и скопируйте его в WebAct, чтобы попробовать задачу. Ваш результат может отличаться от примера.
Решения и устранение проблем.
Нужно ли насильно превращать техническое обслуживание в пользовательскую историю?
Объясните его истинную цель и ограничения. Техническую задачу можно честно описать, не придумывая действие пользователя ради формата.
Почему история выглядит завершённой, но её трудно проверить?
Добавьте ожидаемое поведение и важные границы. Польза объясняет, зачем нужна работа; условия приёмки — что значит её завершение.
Попробуйте на собственном источнике.
Замените пример своим материалом в промпте. Сохраните нужные требования и скопируйте задачу в WebAct.
Настроить и скопировать задачу ↑