Когда использовать Given-When-Then?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Given-When-Then: Формат для описания требований и сценариев
Given-When-Then (GWT) — это структурированный формат описания поведения системы, широко используемый в Behavior-Driven Development (BDD). Эта нотация помогает бизнес-аналитикам, разработчикам и QA-инженерам общаться на одном языке.
Когда использовать Given-When-Then
1. При описании юзер-сторий и критериев приёмки
Given-When-Then идеален для формализации критериев приёмки (acceptance criteria). Вместо размытого описания вроде "система должна позволять пользователю войти", мы получаем четкий сценарий:
Гiven: Пользователь зарегистрирован в системе
When: Пользователь вводит корректные email и пароль на странице входа
Then: Пользователь перенаправляется на личный кабинет
And: В интерфейсе отображается его имя
Такой формат минимизирует неоднозначность и упрощает автоматизацию тестов.
2. При работе с командой BDD (Cucumber, SpecFlow)
Eсли команда использует BDD-фреймворки, Given-When-Then становится не просто описанием, а исполняемым кодом. Сценарии пишутся на естественном языке (Gherkin) и автоматически превращаются в тесты:
Feature: Аутентификация пользователя
Scenario: Успешный вход с корректными учётными данными
Given пользователь на странице входа
When пользователь вводит email "user@example.com"
And вводит пароль "correct_password"
And нажимает кнопку "Войти"
Then пользователь видит личный кабинет
Это позволяет запускать одни и те же тесты на разных уровнях (unit, integration, E2E).
3. При документировании сложных бизнес-логики
Для процессов с множеством условий и ветвлений Given-When-Then обеспечивает наглядность. Например, при описании правил расчёта скидок:
Given: Покупатель имеет статус "VIP"
And: Сумма заказа больше 10 000 рублей
When: Покупатель применяет промо-код "SPRING2026"
Then: Система рассчитывает скидку 20% на товары
And: Итоговая цена пересчитывается
4. При планировании тестов и выявлении edge cases
Процесс описания сценариев в формате GWT помогает выявить граничные случаи. Пока писал Given-When-Then для всех основных сценариев входа, появляются вопросы: а что если пользователь заблокирован? Что если забыл пароль? Формат естественно подталкивает к полноте.
Когда НЕ использовать Given-When-Then
1. Для быстрого описания простых требований
Если требование однозначно (например, "добавить кнопку на страницу"), Given-When-Then может быть избыточным. Используй простой текст.
2. Для документирования уже готового кода
Given-When-Then пишется на этапе планирования, а не после разработки. Если код уже написан, лучше извлечь сценарии из него автоматически.
3. Когда команда не готова к BDD
Если разработчики и QA не знают Gherkin, Given-When-Then станет шумом. Начни с обучения команды или используй более простой формат.
Рекомендации для Business Analyst
- Используй Given-When-Then для критерия приёмки каждой юзер-истории средней и высокой сложности
- Пиши на русском или английском, в зависимости от команды
- Начни с основных happy-path сценариев, потом добавляй edge cases
- Вовлекай разработчиков и QA в написание сценариев — они выявят неоднозначности
- Регулярно обновляй сценарии при изменении требований
Given-When-Then — это не просто формат, это способ мышления, который делает требования изобразимыми и проверяемыми.