Проектирование программного обеспечения: что такое Acceptance Criteria и зачем они нужны? Хабр

И хотя часть дефектов можно оставить на пострелизный период, некоторые из них, скорее всего, окажутся важными и срочными и потребуют устранения в рамках UAT. Для приемки имеет смысл подготовить для клиента отдельную тестовую среду, наполнив её данными, максимально приближенными к реальным. А если вы осуществляете миграцию со старой системы в новую, то лучше наполнить тестовую среду реальными данными клиента, предварительно анонимизировав их. Ниже вы найдете пример одного из возможных шаблонов для сценария приемки. Такая таблица используется как на этапе подготовки и согласования сценариев, так и на этапе проведения UAT — клиент заполняет колонки для фидбека. Пользовательские истории — это короткие предложения, описывающие функциональность с точки зрения пользователя.

Как и в предыдущем кейсе, велась практика ежедневных звонков для обсуждения результатов приемки и классификации дефектов. В любом случае окончательное решение о выходе в продакшн принимает клиент. Ваша задача — дать рекомендации на основании согласованных ранее критериев и предоставить клиенту всю необходимую информацию для принятия решения. Проведение приемки происходит по заранее оговоренным сценариям. По каждому шагу/сценарию принимающая сторона должна проставить отметку прохождения (например, pass/fail/pass with comments) и описать обнаруженную проблему. Сделать это можно либо прямо в таблице со сценариями, либо заводя дефект в баг-трекинг систему (Jira, Redmine и так далее) и оставляя номер дефекта в строке с проверяемым шагом.

Декомпозиция бэклога (Backlog Slicing, слайсинг или нарезка бэклога)

При его написании я понял, что не знаю, что произойдет после того, как пользователь успешно войдет в систему. Форматирование данного требования таким образом заставило меня задуматься об этом, что поспособствовало развитию дизайна продукта и пользовательского опыта. Конкретные значения, естественно, должны быть согласованы отдельно в каждом конкретном случае. Для мобильной игры критерии могут быть мягкими (здесь более важна скорость выхода на рынок), а медицинская система должна соответствовать очень высоким стандартам качества. Кроме того, критерии входа в UAT, описанные в одном из предыдущих разделов, могут быть достаточно мягкими.

Это также дает разработчикам и специалистам по контролю качества четкий способ определить, выполнена ли история. Ваши критерии бесполезны, если ваши разработчики не могут их понять. Если вы не уверены, ясно ли что-то, найдите время, чтобы спросить и внести поправки, пока все не станет ясно. Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта. Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта.

Образцы Acceptance Criteria

В частности, так тестировалась интеграция с legacy-системой клиента. Часто бывает полезно провести первую сессию UAT совместно с представителем клиента, в идеале онсайт. В этом случае процесс обычно acceptance criteria це идет быстрее, поскольку все вопросы выясняются в личном общении. В дальнейшем можно перейти на удаленный вариант общения и отдать оставшуюся часть приемки на самостоятельное выполнение клиенту.

Условия удовлетворенности (Conditions of Satisfaction) специфичны для каждого элемента бэклога и определяют, что должно быть верным, чтобы эта конкретная пользовательская история считалась выполненной. Далее мы описали, какие пользовательские истории относятся к нашим эпикам. Для доступа в приложение это были выбор роли при входе, регистрация и авторизация, восстановление пароля, причём регистрации техника и клиента отличались, поэтому мы разделили их на две разные истории. В работе с профилем появились такие истории, как редактирование профиля, работа с квалификационными документами, просмотр отзывов, смена локализации и др. Для модерации — блокировка и разблокировка пользователей, подтверждение и отклонение техников, просмотр заявок. Вначале мы определяемся с главными составляющими нашего проекта — эпик (epic).

Достаточно ли AC как такового?

Когда я прошу их написать Критерии приемки (Acceptance criteria) для пользовательской истории, многие владельцы продуктов кажутся сбитыми с толку, говоря, что они не знают, как их написать. Для работы с требованиями и критериями приемки подойдет Jira или любая другая система управления задачами. Для отслеживания изменений требований более уместно использовать отдельные документы — реестры изменений, например в банальном Google Spreadsheet или Excel.

При этом у команды не должно быть вопросов к документу, описание должно быть понятным и однозначным. Если клиент вдруг решил обратиться в другую студию, то передать проект новой команде будет проще и быстрее, когда есть ФЗ. Завтра там нужно будет что-то поменять, а документации, которая проливает свет на то, что и как работает — нет.

Зачем нужны Acceptance Criteria

Наконец, критерии приемки часто определяют тестирование «прошел/прошел», чтобы определить, завершена ли пользовательская история. В Agile критерии приемки (Acceptance Criteria) относятся к набору предопределенных требований, которые должны быть выполнены, чтобы отметить User Story как завершенную. Критерии приемки также иногда называют «definition of done», потому что они определяют объем и требования, которые должны быть выполнены разработчиками, чтобы считать User Story завершенной.

• Завтра там нужно будет что-то поменять, а документации, которая проливает свет на то, что и как работает — нет.
• В этой статье, а также видео материале, я привожу пример, не имеющий ничего общего с IT.
• Шаблонная структура документа позволила новым членам команды быстрее влиться в проект и быстро вносить изменения в ходе работы над проектом.
• Практически любой член кросс-функциональной команды мог написать критерии приемки для пользовательских историй.
• Критерии приемки – это средство взглянуть на проблему с точки зрения клиента.

Функциональное задание не должно создаваться в одиночку, оно всегда открыто для обсуждений, иначе недопониманий не избежать. Если же это мобильное приложение для оплаты услуг ЖКХ, то для такого проекта можно выделить такие эпики как доступ в приложение, профиль пользователя, счётчики, оплата услуг. Например, в интернет-магазине пользователю хочется посмотреть каталог, заказать понравившийся товар и отслеживать его доставку, поэтому эпиками будут каталог, личный кабинет, заказ товара. Каждый из этих эпиков имеет собственную ценность для пользователя и относительно самодостаточен. Так как общепринятых стандартов нет, требования к ФЗ диктуются здравым смыслом. Оно должно быть ёмким, ведь никто не захочет читать огромную простыню.

Как нужно: эпики, пользовательские истории и критерии приёмки

В любом процессе или явлении не может быть единой-верной позиции и лишь в споре (сопоставлении различных мнений) рождается истина. Всё, как всегда, зависит от контекста проекта, от команды и от стейкхолдеров — правда, как всегда, где-то посередине! Практика обсуждений в формате трех ролей будет полезна в любом проекте, потому что везде есть разработчики и тестировщики, которые дальше https://deveducation.com/ будут внедрять и проверять созданные требования. Участники собираются за 1-2 спринта до того, как функция должна быть в разработке, и рассматривают требования на будущее. Это «фильтр на выход» (тогда как критерии подготовленности — «фильтр на вход» в разработку). Критерии приемлемости – это совсем не о том, каким образом вы, как разработчик, могли бы взаимодействовать с чем-то.

Критерии Приемки (Acceptance Criteria)

И не о том, как вы хотите, чтобы кто-то взаимодействовал с чем-то. Необходимо представить себя самым бестолковым и раздраженным существом на планете — пользователем. Потому что именно он будет возиться с вашей “замечательной” формой входа в систему. Наконец, в связи с таким форматированием, AC побуждает вас к более логичному мышлению, а благодаря использованию Then, гарантирует, что вы тщательно продумаете результаты действий пользователя. Это заставляет вас позаботиться о том, как пользователь сможет испытать приложение, а не только о том, какие замечательные вещи вам хотелось бы сделать. Так или иначе обнаруживаются какие-то нестыковки, возникают вопросы, заводятся дефекты.

Den

all author posts