Модуль 2 · Критерии приёмки

Критерии приёмки: когда «готово» значит одно и то же

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

Зачем они нужны

Возьмём требование из прошлого модуля:

Требование Система должна рассчитывать реальную доходность вклада с учётом инфляции.

Требование говорит что делать, но не говорит, как проверить, что сделано верно. Отдай его двум разработчикам — получишь два разных калькулятора. Один округлит до целых, другой до копеек. Один при инфляции выше ставки покажет минус, другой про этот случай не подумает.

💡 Что такое критерий приёмки Критерий приёмки (acceptance criteria) — условие, при котором требование считается выполненным. Это мост между требованием и тестом: все трое смотрят на него и одинаково понимают слово «готово».

Формат «Дано / Когда / Тогда»

Мировой стандарт записи — три строки. В оригинале это язык Gherkin («Given / When / Then», читается «геркин»).

ДАНО состояние до действия КОГДА действие пользователя ТОГДА ожидаемый результат
Дано — контекст, Когда — действие, Тогда — проверяемый результат.

Пример на калькуляторе

Требование одно, а сценариев к нему несколько.

Сценарий 1 — обычный случай (счастливый путь)
Дано: пользователь открыл калькулятор доходности
Когда: вводит сумму 100 000 ₽, ставку 12%, инфляцию 8%
Тогда: система показывает реальную доходность ≈ 3,7% годовых и реальную сумму ≈ 103 700 ₽
Сценарий 2 — инфляция съедает вклад
Дано: пользователь на калькуляторе
Когда: вводит ставку 6% и инфляцию 9%
Тогда: реальная доходность отрицательная (−2,75%), число подсвечено красным как предупреждение
Сценарий 3 — пустое поле
Дано: пользователь на калькуляторе
Когда: оставляет поле «инфляция» пустым
Тогда: расчёт не запускается, под полем подсказка «введите инфляцию»
📌 Схема, которую спрашивают на собесе Одно требование → один счастливый путь (happy path — когда всё вводят верно) + несколько граничных случаев (edge cases — крайности: ноль, минус, пусто, слишком много). Джуна часто заваливают тем, что он описывает только сценарий 1 и забывает про 2 и 3.

Две ошибки, на которых легко попасться

Ошибка 1. Расплывчатый результат

«Система сравнивает оба значения» — это как запрещённое «правильно» из модуля 1. Тестировщик спросит: сравнивает — это как? Делаем наблюдаемым: показывает разницу в рублях и выделяет более выгодный вариант.

Ошибка 2. Внутренняя кухня в «Тогда»

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

✅ Слабый сценарий → готовый критерий Было: «показывает доход по вкладу и инвестпродукту, сравнивая оба значения (тянется из базы)».
Стало: «показывает реальный доход по вкладу и по инвестпродукту за 12 месяцев с учётом инфляции, выделяет более выгодный вариант и разницу между ними в рублях».
По второму варианту тест пишется без единого уточняющего вопроса.

Ключевые термины

Критерий приёмки — когда требование «готово» Дано / Когда / Тогда — формат записи (Gherkin) Счастливый путь — всё введено верно Граничный случай — ноль, минус, пусто Наблюдаемое поведение — что видно снаружи
← Конспект 1: Требования Оглавление →