Acceptance Criteria Given/When/Then на собеседовании системного аналитика

Зачем спрашивают на собесе SA

AC — основной инструмент описания, что значит «фича готова». На собесе SA обязательно: «напиши AC для регистрации», «отличие AC от DoD», «когда Given/When/Then, когда чек-лист». Без чёткого AC разработчик угадывает, тестировщик не знает что проверять, бизнес недоволен.

Главная боль без понимания — SA пишет AC «должно работать корректно». Тимлид возвращает на доработку, спринт уходит в перенос.

Что такое acceptance criteria

Acceptance Criteria (критерии приёмки) — условия, которым должна удовлетворять фича, чтобы её приняли. Объективные, проверяемые, без двойного толкования.

Свойства хорошего AC:

• Конкретность. «Кнопка должна быть видна» — плохо. «Кнопка отображается в шапке на десктопе ≥ 1024px» — хорошо.
• Тестируемость. Должно быть однозначно — пройдено или нет.
• Без описания решения. AC = что должно произойти, а не «как реализовать».
• Ограниченность scope. Один user story = свой набор AC. Не размазывать.
• Чёткие границы happy path / edge cases. Включать оба.

AC vs use case vs user story:

• User story — формулировка ценности («Как X, я хочу Y, чтобы Z»).
• Use case — формальное описание сценариев взаимодействия (UML).
• AC — критерии приёмки конкретного user story.

Формат Given/When/Then (Gherkin)

Самый структурированный формат, идеально для автотестов (BDD).

Given <предусловие>
When <действие>
Then <ожидаемый результат>

Пример: AC для логина.

Сценарий: Успешный логин

  Given пользователь зарегистрирован с email "user@test.com" и паролем "secret123"
   And пользователь находится на странице "/login"
   When пользователь вводит email "user@test.com"
    And пользователь вводит пароль "secret123"
    And нажимает "Войти"
   Then пользователь видит главную страницу "/dashboard"
    And в header отображается имя пользователя
    And в localStorage есть ключ "auth_token"

Сценарий: Неверный пароль

  Given пользователь зарегистрирован с email "user@test.com"
   And находится на странице "/login"
   When вводит email "user@test.com"
    And пароль "wrong"
    And нажимает "Войти"
   Then отображается ошибка "Неверный email или пароль"
    And пользователь остаётся на странице "/login"

Преимущества:

• Читаемо для бизнеса.
• Однозначно для разработчика и тестировщика.
• Автотесты на BDD-фреймворках (Cucumber, behave, pytest-bdd) парсят Gherkin напрямую.

Минусы:

• Многословно.
• Не подходит для всего (например, для API — другие форматы).

Формат чек-листа

Простой и быстрый формат для небольших фич:

US-15: Покупатель видит итоговую сумму в корзине

Acceptance Criteria:
- [ ] Сумма отображается в правом верхнем углу корзины
- [ ] Сумма пересчитывается при изменении количества товара
- [ ] Сумма включает НДС с пометкой "в т.ч. НДС 20%"
- [ ] При пустой корзине показывается "0 ₽"
- [ ] Сумма отображается с пробелом-разделителем тысяч (1 234 ₽)
- [ ] При сумме > 999 999 ₽ — без округления
- [ ] Сумма доступна для скрин-ридеров (атрибут aria-label)

Подходит для UI и простых требований. Минус — нет явного Given (предусловия).

Сценарийный формат

Текстовое описание основного и альтернативных потоков. Похоже на use case, но короче.

US-22: Восстановление пароля

Основной сценарий:
1. Пользователь нажимает "Забыли пароль?" на /login
2. Видит форму с полем email
3. Вводит email и нажимает "Восстановить"
4. Видит сообщение "Если email зарегистрирован, ссылка отправлена"
5. Получает email со ссылкой за < 1 минуту
6. Открывает ссылку (валидна 24 часа)
7. Видит форму нового пароля
8. Устанавливает новый пароль (см. требования к паролю в US-7)
9. Автоматически логинится в систему

Альтернативные сценарии:
3a. Пользователь не зарегистрирован → то же сообщение (без выдачи факта регистрации)
6a. Срок ссылки истёк → "Срок ссылки истёк, запросите новую"
6b. Ссылка уже использована → "Ссылка использована"

Хорош для сложных пользовательских flow.

Definition of Ready vs Definition of Done

Часто путают с AC.

Definition of Ready (DoR) — что должно быть в задаче, чтобы её взять в работу:

• Ценность описана (user story).
• Acceptance Criteria сформулированы.
• Дизайн готов (если нужен).
• Технические нюансы прояснены.
• Оценка дана.
• Зависимости известны.

Definition of Done (DoD) — что должно быть сделано, чтобы фичу выкатить:

• Код написан и review пройден.
• Тесты написаны (unit / integration по правилам команды).
• AC удовлетворены.
• Документация обновлена.
• QA принял.
• Деплой на staging / prod.

AC — про конкретную задачу, DoD — общий стандарт качества для всех задач команды.

Acceptance criteria для нефункциональных требований

Производительность, безопасность, доступность нужны не меньше функциональных.

Performance:

- 95-я перцентиль времени ответа /api/orders < 300 мс при 100 RPS
- Загрузка страницы < 2 с на 4G и до 100 ms на wifi

Безопасность:

- Пароль хешируется bcrypt (cost ≥ 12)
- API требует Bearer JWT с подписью RS256
- В логах не сохраняется plaintext пароль / номер карты

Accessibility:

- Контрастность текста ≥ 4.5:1 (WCAG AA)
- Все интерактивные элементы доступны с клавиатуры
- На каждом изображении — alt-атрибут

Браузерная поддержка:

- Работает на Chrome, Firefox, Safari, Edge (последние 2 версии)
- Деградирует gracefully на iOS 14+

Частые ошибки

Размытые формулировки. «Должно быть быстро», «должно работать корректно», «должно быть user-friendly» — не AC.

AC описывает реализацию. «Использовать Redis для кэша» — это не AC, это решение. AC — «время ответа < 200 мс на повторный запрос».

Только happy path. Без edge cases (пустые входы, ошибки сети, лимиты, валидация) — фича не готова.

Отсутствие предусловий. «Когда нажимает кнопку» — а в каком состоянии система? Предусловие критично.

Несколько фичей в одном AC. Один user story → один scope. Если AC слишком много — разбей на несколько stories.

Использовать Given/When/Then для всего. Для API-контракта чек-лист с примерами JSON быстрее. Для регрессионных сценариев — Gherkin лучше.

Путать AC с DoD. «Code review пройден» — это DoD, не AC. AC = поведение фичи, DoD = качество разработки.

Не показать Тестируемость. AC должно проверяться однозначно. «Удобно» / «понятно» — не проверяемо.

Связанные темы

• User Stories и Acceptance Criteria для SA
• UML Use Case на собесе SA
• UML Sequence на собесе SA
• OpenAPI и Swagger на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Сколько AC на одну user story?

Обычно 3-10. Если 20+ — story слишком большая, разбивай. Если 1-2 — story тривиальная, проверь, что не упустил edge cases.

Кто пишет AC?

Чаще всего — SA или PM. На утверждение — команда (dev, QA, дизайн). На больших командах — SA пишет, dev и QA согласуют.

Можно ли менять AC после старта работы?

Можно, но это сигнал — спецификация не готова. Лучше — DoR гарантирует что AC чёткие до начала. Если спринт уже идёт — изменения через формальный change request.

AC обязательны для bug-фиксов?

Да, краткие. «Степы воспроизведения / ожидаемое поведение / фактическое». Это и есть acceptance criteria для бага.

Чем Gherkin отличается от просто AC в формате Given/When/Then?

Gherkin — формализованный синтаксис BDD-фреймворков (Cucumber и пр.) с ключевыми словами Feature/Scenario/Given/When/Then. Просто Given/When/Then — стиль формулировки без машинного парсинга.

Это официальная информация?

Нет. Статья основана на работах по Agile (Cohn «User Stories Applied»), документации Cucumber, BDD-практиках.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.