Ответ
Приёмочный критерий (Acceptance Criterion, AC) — это чёткое, проверяемое условие, которое должно быть выполнено, чтобы пользовательская история (User Story) или задача считалась завершённой и готовой к приёмке заказчиком или продукт-менеджером.
Ключевые характеристики хорошего приёмочного критерия:
- Независимый: Описывает отдельный, законченный аспект функциональности.
- Измеримый: Его выполнение можно объективно проверить (обычно результатом является проходной тест).
- Достижимый: Критерий реализуем в рамках одной итерации.
- Релевантный: Непосредственно связан с бизнес-ценностью истории.
- Ограниченный по времени: Ясен объём работы.
Формат (часто используется Given-When-Then):
Дано (Given) [начальный контекст]
И (And) [дополнительный контекст]
Когда (When) [происходит событие или действие]
Тогда (Then) [ожидаемый результат]
И (And) [дополнительный результат]Пример для истории "Как пользователь, я хочу входить в систему, чтобы получить доступ к личному кабинету":
-
Критерий успеха:
Дано зарегистрированный пользователь с валидными логином и паролем
Когда пользователь вводит валидные логин и пароль и нажимает "Войти"
Тогда происходит перенаправление на страницу личного кабинета
И в заголовке страницы отображается приветствие "Добро пожаловать, [Имя]!" -
Критерий неудачи (неверный пароль):
Дано зарегистрированный пользователь
Когда пользователь вводит валидный логин, но неверный пароль и нажимает "Войти"
Тогда на экране отображается сообщение об ошибке "Неверный логин или пароль"
И пользователь остаётся на странице входа
Роль QA-инженера:
- Участие в формулировке: Помогать команде (продукт-менеджеру, разработчикам) делать критерии максимально конкретными и проверяемыми с самого начала.
- Основа для тестирования: Приёмочные критерии — это первичный источник для создания тест-кейсов и автоматизированных сценариев (например, на Cucumber/Gherkin).
- Критерий завершённости: Функция не считается готовой, пока не выполнены все её приёмочные критерии и не пройдены соответствующие тесты.
- Общий язык: AC служат «контрактом» между бизнесом и командой разработки, минимизируя недопонимание.
Ответ 18+ 🔞
А, приёмочные критерии! Ну это ж святое, ёпта. Сейчас объясню на пальцах, без этой вашей заумной воды, которая только мозги пудрит.
Представь, ты заказчику фичу продаёшь. Он смотрит и спрашивает: «Ну и как я пойму, что вы сделали то, что надо, а не какую-то хуйню?». Вот тут-то ты и выкатываешь приёмочные критерии — это такой чёткий список условий, типа «сделай раз, сделай два». Если всё по списку работает — заказчик подписывает акт, деньги капают, все довольны. Если хоть один пункт хромает — работай дальше, дружок.
Что это за зверь такой?
По-простому, это проверяемые правила игры. Не абстрактное «сделайте красиво», а конкретное «кнопка должна быть синей, а при наведении курсора — становиться на 10% темнее, вот скриншот, вот цвет в HEX».
Какими они должны быть, чтобы не было мучительно больно?
- Конкретными до одури. Не «работает быстро», а «страница загружается менее чем за 2 секунды при 3G-соединении».
- Проверяемыми на раз-два. Любой тестировщик (или даже сам разработчик, если не бздит) должен взять и за пять минут доказать: да, работает или нет, нихуя не работает.
- Про одну фичу. Не надо в один критерий пихать овердохуища всего. Один критерий — одна чёткая мысль. Иначе потом непонятно, что именно сломалось.
- Про бизнес-ценность. Они должны отвечать на вопрос «Какую проблему пользователя это решает?», а не «Какую технологическую дичь вы там внутри применили?». Всем похуй на ваш реактивный стек, им надо, чтобы кнопка «Купить» вела на оплату.
Любимый формат всех айтишников — Given-When-Then (Д-К-Т). Выглядит как сценарий для робота, но зато нихуя не двусмысленно.
Допустим (Given) [начальные условия, типа пользователь залогинен]
Когда (When) [он совершает действие, например, тыкает в кнопку]
Тогда (Then) [происходит вот такой вот конкретный, блядь, результат]Пример из жизни, чтобы совсем всё стало ясно.
Задача: «Как пользователь, я хочу выйти из аккаунта, чтобы мой младший брат-пидарас шерстяной не мог под моим именем в игрушки играть».
-
Критерий успеха (нормальный сценарий):
Допустим я, Вася Пупкин, авторизован в системе. Когда я нажимаю на свой аватар в правом верхнем углу и выбираю в меню «Выйти», Тогда система меня разлогинивает, перенаправляет на главную страницу, И кнопка «Войти» снова становится активной. Волнение ебать — братан уже не зайдёт!
-
Критерий неудачи (проверяем граничные случаи, тут-то и кроется вся манда с ушами):
Допустим я нажал «Выйти», и в этот момент пропало интернет-соединение. Когда соединение восстанавливается через 30 секунд, Тогда я всё равно остаюсь на странице выхода (а не в админке), И вижу понятное сообщение «Сессия завершена», И попытка вернуться назад в личный кабинет требует повторного логина. Доверия ебать ноль к этому брату!
А где тут место тестировщику, спросишь?
Да в самой жопе событий, чувак!
- Писать их надо вместе. Не жди, пока аналитик или проджект скинет тебе кривую писанину. Садись в начале спринта и говори: «Ребят, а как мы это будем проверять? А что если пользователь нажмёт сюда, когда у него хуй с винтом?». Так ты с самого начала отсекаешь туманные формулировки.
- Это твоя главная библия для тестов. Каждый приёмочный критерий — это готовый тест-кейс, иногда даже в автомат сразу ложится. Сделал сценарий по всем AC — считай, основную функциональность покрыл.
- Это твой железный аргумент. Разработчик говорит: «Всё готово!». А ты: «Минуточку, дружок-пирожок. Вот по третьему критерию, когда вводишь отрицательную сумму, должно выскакивать предупреждение. Где оно? Покажи-ка». И всё, спор окончен. Либо фикси, либо идёшь на хуй с пометкой «в работе».
Короче, без чётких приёмочных критериев проект превращается в балаган, где все делают то, что сами поняли, а потом удивление пиздец, почему заказчик не принимает работу. Это ваш общий язык, ваш контракт. Чем он конкретнее — тем меньше хитрых жоп и недопонимания в конце спринта.