Acceptance criteria что это
Проектирование программного обеспечения: что такое Acceptance Criteria и зачем они нужны?
Вы разрабатываете функцию для веб-сайта. Пусть это простая форма входа в систему. Поскольку вы превосходный разработчик, то решили провести базовое планирование, прежде чем приступить к проектированию. По крайней мере, вы хотите определить некоторые аспекты функции, которую собираетесь создать.
Поля ввода для имен пользователей и паролей
Способ сообщить пользователю, если он ввел свои данные неправильно
Способ восстановления забытых данных
Способ регистрации учетной записи, если у пользователя ее еще нет.
Итак, достаточно ли этого?
А что, если вы хотите написать что-то вроде поведенческого теста? Как перевести то, что написано выше, в шаги пользователя? И достаточно ли такой подход «короткого теглайна» говорит вам о том, как пользователь на самом деле выполняет эти действия? Задумывались ли вы о том, что происходит после того, как пользователь успешно вошел в систему? Помогает ли такой подход размышлять подобным образом?
Мы знаем, что нам нужно, но как это воплотить в хорошо спроектированную функцию?
Вы, наверное, догадались, какой будет ответ: это критерии приемки.
Что такое критерии приемки?
Пример критериев приемки для вашей формы входа в систему может выглядеть следующим образом:
Given определяет некое предварительное условие для выполнения действия. When определяет действие. Then определяет результат действия. Мы также можем использовать And для дополнения любого из этапов, внося дополнительные условия. Этот подход логичен, понятен и прост. Каждый из этих этапов точно объясняет, что должно произойти в сценарии.
Мы также можем легко написать поведенческий тест для этого, потому что точно знаем, какие установки, действия и результаты будут задействованы. Есть предварительное условие для теста: у пользователя должна быть учетная запись. Имеется действие: пользователь нажимает на кнопку входа. Также известен результат: пользователь вошел в систему и просматривает главную страницу.
Данный AC также дал нам некоторую дополнительную информацию. При его написании я понял, что не знаю, что произойдет после того, как пользователь успешно войдет в систему. Форматирование данного требования таким образом заставило меня задуматься об этом, что поспособствовало развитию дизайна продукта и пользовательского опыта.
Наконец, в связи с таким форматированием, AC побуждает вас к более логичному мышлению, а благодаря использованию Then, гарантирует, что вы тщательно продумаете результаты действий пользователя. Это заставляет вас позаботиться о том, как пользователь сможет испытать приложение, а не только о том, какие замечательные вещи вам хотелось бы сделать.
Как написать хороший AC?
Итак, вы решили написать этот продукт, но как сделать это правильно? Приведенная выше функция входа в систему очень проста, но более сложные концепции могут привести к путанице в AC, поэтому важно помнить о следующих вещах:
1. Пишите с точки зрения пользователя
2. Простота
AC должен быть простым для понимания. Постарайтесь соотнести каждую строку с конкретным действием пользователя или предварительным условием, например, ввести правильные данные пользователя или уже быть зарегистрированным в приложении. Длинная строка AC, которая пытается вместить в себя несколько вещей, может повлиять на ясность и тем самым свести на нет многие преимущества, упомянутые выше.
3. Понятный язык
Этот пункт связан с пунктом 2 и напрямую влияет на него. Пишите AC простым языком. Одно из главных преимуществ такого подхода заключается в том, что он может быть понятен нетехническим людям. Инструмент, способный описать функцию для любого человека и одновременно управлять реализацией/тестированием, бесценен. Сложный же язык будет этому препятствовать.
4. Не заостряйте внимания на деталях реализации
5. Не будьте техническими специалистами
Достаточно ли AC как такового?
Нет, это только отправная точка. Он будет определять ваш дизайн, передавать ваше видение и помогать для тестирования, однако это еще не все и не всегда. Вы должны писать подзадачи, чтобы лучше определить технические аспекты ваших функций, создавать макеты и писать конкретные примеры. Все эти вещи важны и ценны и должны использоваться, но, тем не менее, хорошо написанные критерии приемки — это надежная отправная точка, и если они сделаны правильно, то в результате всегда получается более высокое качество программного обеспечения.
Перевод материала подготовлен в рамках курса «Системный аналитик. Basic». Если вам интересно узнать подробнее о формате обучения и программе курса, приглашаем на день открытых дверей онлайн.
acceptance criteria
1 acceptance criteria
аттестационные критерии
(напр. соответствия системы или оборудования предназначенным функциям)
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
Тематики
критерии приемлемости
Предписанные границы значения функционального индикатора или индикатора состояния используются для оценки способности конструкции, системы или элемента выполнять свою проектную функцию.
[Глоссарий МАГАТЭ по вопросам безопасности]
Тематики
критерии приёмки
(напр. оборудования)
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
3.1.1 критерии приемки (acceptance criteria): Установленные границы характеристик, определяющих область приемлемости процесса или продукции.
критерии приемлемости (acceptance criteria): Числовые предельные значения, диапазоны или другие критерии, применяемые для приемки результатов испытаний.
3.1 критерий допустимости (acceptance criteria): Допустимое значение риска, установленное до начала оценки риска, на основе которого можно отделить приемлемый пожарный риск от неприемлемого.
1 См. также «допустимый пожарный риск».
2 Критерии приемки, необходимые для описания приемлемого пожарного риска, могут быть неколичественными.
3.1.1 критерий приемки (acceptance criteria): Спецификация, используемая для того, чтобы принимать или браковать компьютерную систему, приложение, функцию или проведение испытания.
2 acceptance criteria
3 acceptance criteria
4 acceptance criteria
5 acceptance criteria
6 acceptance criteria
7 acceptance criteria
8 acceptance criteria
9 Acceptance Criteria
10 acceptance criteria
11 acceptance test criteria
См. также в других словарях:
radioactive waste package acceptance criteria for storage or disposal facility — radioaktyviųjų atliekų pakuočių priėmimo į saugyklą ar atliekyną kriterijai statusas Aprobuotas sritis radiacinė sauga apibrėžtis Kriterijai, pagal kuriuos nustatoma, ar radioaktyviųjų atliekų pakuotės tinkamos saugoti ir dėti į atliekyną.… … Lithuanian dictionary (lietuvių žodynas)
Acceptance testing — of an aircraft catapult In engineering and its various … Wikipedia
Acceptance Of Office By Trustee — A mutual understanding that a person has with the estate that implies they will assume administrative duties after being nominated. Acceptance of office by trustee is basically a formal way of giving consent to serve as a trustee. After being… … Investment dictionary
Wife acceptance factor — Wife Acceptance Factor, Wife Approval Factor, or Wife Appeal Factor[1] (WAF), are design elements that increase the likelihood a wife will approve the purchase of expensive consumer electronics products such as high fidelity loudspeakers, home… … Wikipedia
Credit Criteria — The various financial characteristics that lenders analyze when scrutinizing a prospective borrower. Credit criteria include a borrower s assets and liabilities, income and expenses and credit history. Favorable criteria will usually result in… … Investment dictionary
Unorthodox Creative Criteria — Infobox Album Name = Unorthodox Creative Criteria Type = studio Artist = Coprofago Released = Start date|2005|6|20 Recorded = 2004 Genre = Technical death metal Length = 49:25 Label = Sekhmet/Galy Producer = Reviews = * The Metal Observer (7/10)… … Wikipedia
Common Criteria Evaluation and Validation Scheme — (CCEVS) is a United States Government program administered by the National Information Assurance Partnership (NIAP) to evaluate information technology (IT) product conformance to the Common Criteria international standard. CCEVS Logo Objectives… … Wikipedia
Критерии — 24. Критерии безопасности гидротехнических сооружений как основы контроля их состояния / А.И. Царев, И.Н.Иващенко, В.В. Малаханов, И.Ф.Блинов //Гидротехническое строительство, 1994. №1, С.9 14. Источник … Словарь-справочник терминов нормативно-технической документации
критерии приёмки услуги — (ITIL Service Transition) Набор критериев, используемых для того, чтобы убедиться, что ИТ услуга соответствует требованиям к её функциональности и требованиям к качеству, а также что поставщик ИТ услуг готов обеспечивать эксплуатацию новой ИТ… … Справочник технического переводчика
ГОСТ Р ИСО/ТУ 29001-2007: Менеджмент организации. Требования к системам менеджмента качества организаций, поставляющих продукцию и предоставляющих услуги в нефтяной, нефтехимической и газовой промышленности — Терминология ГОСТ Р ИСО/ТУ 29001 2007: Менеджмент организации. Требования к системам менеджмента качества организаций, поставляющих продукцию и предоставляющих услуги в нефтяной, нефтехимической и газовой промышленности: 3.1.6 валидация проекта… … Словарь-справочник терминов нормативно-технической документации
Software performance testing — In software engineering, performance testing is testing that is performed, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such… … Wikipedia
Превращаем пожелания заказчика в Acceptance Criteria: 3 практики
Меня зовут Анна Лаврова, сейчас я Agile Coach, живу и работаю в Брюсселе. До этого больше девяти лет управляла проектами в Дубае и в Украине, занималась проектным и программным менеджментом.
В статье расскажу, как превратить пожелания заказчика в критерии приемки готового продукта. На конкретных примерах объясню, чем отличаются понятия Definition of Done и Acceptance Criteria, поделюсь техниками работы с требованиями для пользовательских историй.
Думаю, что статья будет полезной для РМ’ов, бизнес-аналитиков и других специалистов, которые работают с заказчиками и создают требования.
Критерии приемки и завершенности: как не перепутать
Поскольку критерии приемки и определение «завершенности» применяют к пользовательским историям, давайте договоримся, что понимать под каждым термином:
Acceptance Criteria прописываются отдельно для каждой User Story, а Definition of Done — общие требования для всех User Stories проекта
Definition of Done
Критерий завершенности — список требований, которым должна соответствовать любая пользовательская история, чтобы команда назвала ее завершенной. Список атрибутов завершенности применяется абсолютно ко всем историям или ко всем элементам бэклога.
Definition of Done — это договоренность о том, как команда будет работать в процессе. Один из элементов scrum set up — это командное соглашение (team working agreements) о критериях завершенности и создание estimation baselines.
Например, обычный критерий завершенности для команд разработки — у каждой конкретной задачи есть шаг code review. Может быть и такой критерий, что у изменения нет известных дефектов — все, что нашли, уже закрыли и починили. В такие договоренности включается и бизнес-сторона: заказчик или Product Owner. Definition of Done — это четкие критерии, по которым мы договариваемся работать и создавать качественный продукт каждую итерацию.
Посмотрим, как будут выглядеть критерии завершенности для трех work items:
Критерии завершенности, общие для всех трех задач, могут быть такими:
Acceptance Criteria
Если пользовательскую историю создают как некую формулировку намерения, чтобы команда была свободна в поиске решения, то критерии приемки — это точные детали, уникальные для каждой User Story, набор условий, подтверждающий, что она реализована.
Критерии приемки всегда можно проверить по четкому параметру «да/нет». Нельзя выполнить какой-то критерий наполовину: он либо выполнен, либо нет. Благодаря Acceptance Criteria команда разработки знает, как должен выглядеть готовый результат конкретного требования.
В одном ряду с критериями приемки есть похожие, но не идентичные, термины от Хенрика Книберга «как продемонстрировать» (How to demo) или Майка Кона «условия удовлетворения ожиданий» (Conditions of Satisfaction).
В целом Acceptance Criteria должны соответствовать следующим характеристикам:
Примеры требований и Acceptance Criteria к ним:
1. Требование — разрешить пользователю загружать файл с картинкой. Критерии приемки:
2. Требование — разрешить пользователю менять пароль. Критерии приемки:
Перечисленные атрибуты должны быть выполнены для конкретных требований, они не описывают весь процесс.
Практика «три С»: Card, Conversation, Confirmation
Давайте вспомним полезную для хороших пользовательских историй практику «трех С», которая помогает:
Три компонента для работы с User Story: записать, обсудить, подтвердить
Методика состоит из трех компонентов:
Как выглядит работа с конкретной User Story: «Как пользователь мобильного телефона я хочу проверять прогноз для своего актуального местоположения, чтобы мне не приходилось искать его каждый раз, когда я еду в новое место».
Card: актуальное местоположение для прогноза погоды.
Conversation: команда обсуждает с PO или ВА, кто будет использовать продукт, зачем это нужно людям и какая в этом ценность для бизнеса. Создают примеры использования (техника Example Mapping).
Confirmation: прописываются критерии приемки и варианты non happy flow к этой истории, например:
Given-When-Then: переводим с языка заказчика на язык критериев приемки
Given-When-Then — это стиль представления тестов или, как сказали бы его сторонники, — определение поведения системы с помощью Specification By Example. Это подход, разработанный Дэниелом Терхорст-Нортом и Крисом Мэттсом в рамках программы Behavior-Driven Development (BDD).
Given-When-Then выглядит как структурный подход для многих сред тестирования, таких как Cucumber (чтобы быть точным, он использует Gherkin, что является названием DSL от Cucumber). Шаблон Given-When-Then позволяет автоматизировать тест для определения, разработано требование или нет.
Можно описывать Acceptance Criteria пунктами или сразу в формате Given-When-Then:
Как формулируется критерий приемки по этому шаблону:
Дано: у меня есть деньги на счету в банке.
Когда я пытаюсь снять деньги со счета, и сумма не превышает лимит.
Тогда система позволяет мне это сделать и не показывает никаких сообщений об ошибке.
Обратите внимание, формат Given-When-Then тоже бинарный: либо «да», либо «нет». В примере выше система должна позволить снять деньги без сообщений об ошибке. Если деньги сняты, но система показала сообщение об ошибке, это не значит, что требование выполнено на 90%. Это значит, что оно не выполнено.
Функционал: пользователь торгует акциями.
Сценарий: пользователь запрашивает продажу до закрытия торгов.
Дано:
Когда я прошу продать 20 акций MSFT.
Тогда:
Как выглядит создание критериев приемки для отдельной User Story:
User Story: как пользователь веб-сайта я хочу оставлять отзывы, чтобы владельцы могли учитывать моё мнение или озабоченность в ходе будущих обновлений платформы.
Сценарий: пользователь отправляет форму обратной связи с действительными данными (prerequisite). Учитывать, в какой роли находится человек: авторизованного или гостевого пользователя.
Дано: я открываю страницу обратной связи, и система показывает мне форму отправки отзыва с обязательными полями: Email, Name и Comment.
Когда я вписываю в поле Email действительный адрес электронной почты и заполняю Name своим именем, а в поле Comment пишу комментарий и нажимаю кнопку «Отправить отзыв».
Тогда система отправляет мой отзыв, показывает флэш-сообщение: «Вы успешно отправили свой отзыв», и очищает поля формы «Отправить отзыв».
Шаблон Given-When-Then не создается в одиночестве PM’ом или Product Owner’ом. Этот формат прописывается на командной встрече, которая называется «Три амигос».
Работа с требованиями на встрече «Три амигос»
Agile-практика «Три амигос» помогает донести голос команды до клиента и прийти к общему пониманию требований.
Результат встречи — это договоренность о том, что будем разрабатывать, и написанные критерии приемки, которые можно автоматизировать, те самые Given-When-Then.
На встречу собираются представители трех ролей:
Три участника представляют голос всей команды, потому что могут рассмотреть каждое требование с разных сторон и убедиться, что все вопросы и пограничные случаи будут обработаны.
Обмениваясь различными точками зрения на проект, участники встречи могут обсудить требования в режиме реального времени:
На встрече «Три амигос» специалисты обсуждают требования, которые еще недостаточно детализированы и не имеют критериев приемки. Требования, уже прошедшие валидацию и верификацию, не обговариваются.
Как проходит встреча «Три амигос»
Встреча длится от 30 минут до часа. Участники собираются за спринта до того, как функция должна быть в разработке, и рассматривают требования на будущее.
На встречу приглашают людей, которые будут разрабатывать и тестировать обсуждаемую функцию: один разработчик и один QA.Человек, написавший требование (BA или Product Owner), начинает собрание с представления того, что должно быть сделано: отвечает на вопрос, зачем нужна функция, как будет выглядеть, кто ею будет пользоваться. Есть высокоуровневый requirement, а дальше вы его детализируете: задаете вопросы и формируете критерии приемки, актуальные для этого конкретного требования. Бизнес-аналитик представляет требования, подготовленные заранее, а другие участники дают обратную связь. Требования обновляются на сессии до тех пор, пока не будут признаны «готовыми к разработке». Затем БА представляет тестовые сценарии, подготовленные до собрания, и они также рассматриваются другими «амигос».
Что может пойти не так:
Технику можно использовать и вне Agile-процесса. Практика обсуждений в формате трех ролей будет полезна в любом проекте, потому что везде есть разработчики и тестировщики, которые дальше будут внедрять и проверять созданные требования.
Что еще почитать
Все техники, о которых шла речь в статье, необходимы, чтобы составить качественные требования к пользовательским историям:
Четко прописанные критерии приемки и завершенности помогают создавать качественный продукт, подтверждают для команды и заказчика, что конкретная история реализована.
acceptance criteria
аттестационные критерии
(напр. соответствия системы или оборудования предназначенным функциям)
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
Тематики
критерии приемлемости
Предписанные границы значения функционального индикатора или индикатора состояния используются для оценки способности конструкции, системы или элемента выполнять свою проектную функцию.
[Глоссарий МАГАТЭ по вопросам безопасности]
Тематики
критерии приёмки
(напр. оборудования)
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
3.1.1 критерии приемки (acceptance criteria): Установленные границы характеристик, определяющих область приемлемости процесса или продукции.
критерии приемлемости (acceptance criteria): Числовые предельные значения, диапазоны или другие критерии, применяемые для приемки результатов испытаний.
3.1 критерий допустимости (acceptance criteria): Допустимое значение риска, установленное до начала оценки риска, на основе которого можно отделить приемлемый пожарный риск от неприемлемого.
1 См. также «допустимый пожарный риск».
2 Критерии приемки, необходимые для описания приемлемого пожарного риска, могут быть неколичественными.
3.1.1 критерий приемки (acceptance criteria): Спецификация, используемая для того, чтобы принимать или браковать компьютерную систему, приложение, функцию или проведение испытания.
Полезное
Смотреть что такое «acceptance criteria» в других словарях:
radioactive waste package acceptance criteria for storage or disposal facility — radioaktyviųjų atliekų pakuočių priėmimo į saugyklą ar atliekyną kriterijai statusas Aprobuotas sritis radiacinė sauga apibrėžtis Kriterijai, pagal kuriuos nustatoma, ar radioaktyviųjų atliekų pakuotės tinkamos saugoti ir dėti į atliekyną.… … Lithuanian dictionary (lietuvių žodynas)
Acceptance testing — of an aircraft catapult In engineering and its various … Wikipedia
Acceptance Of Office By Trustee — A mutual understanding that a person has with the estate that implies they will assume administrative duties after being nominated. Acceptance of office by trustee is basically a formal way of giving consent to serve as a trustee. After being… … Investment dictionary
Wife acceptance factor — Wife Acceptance Factor, Wife Approval Factor, or Wife Appeal Factor[1] (WAF), are design elements that increase the likelihood a wife will approve the purchase of expensive consumer electronics products such as high fidelity loudspeakers, home… … Wikipedia
Credit Criteria — The various financial characteristics that lenders analyze when scrutinizing a prospective borrower. Credit criteria include a borrower s assets and liabilities, income and expenses and credit history. Favorable criteria will usually result in… … Investment dictionary
Unorthodox Creative Criteria — Infobox Album Name = Unorthodox Creative Criteria Type = studio Artist = Coprofago Released = Start date|2005|6|20 Recorded = 2004 Genre = Technical death metal Length = 49:25 Label = Sekhmet/Galy Producer = Reviews = * The Metal Observer (7/10)… … Wikipedia
Common Criteria Evaluation and Validation Scheme — (CCEVS) is a United States Government program administered by the National Information Assurance Partnership (NIAP) to evaluate information technology (IT) product conformance to the Common Criteria international standard. CCEVS Logo Objectives… … Wikipedia
Критерии — 24. Критерии безопасности гидротехнических сооружений как основы контроля их состояния / А.И. Царев, И.Н.Иващенко, В.В. Малаханов, И.Ф.Блинов //Гидротехническое строительство, 1994. №1, С.9 14. Источник … Словарь-справочник терминов нормативно-технической документации
критерии приёмки услуги — (ITIL Service Transition) Набор критериев, используемых для того, чтобы убедиться, что ИТ услуга соответствует требованиям к её функциональности и требованиям к качеству, а также что поставщик ИТ услуг готов обеспечивать эксплуатацию новой ИТ… … Справочник технического переводчика
ГОСТ Р ИСО/ТУ 29001-2007: Менеджмент организации. Требования к системам менеджмента качества организаций, поставляющих продукцию и предоставляющих услуги в нефтяной, нефтехимической и газовой промышленности — Терминология ГОСТ Р ИСО/ТУ 29001 2007: Менеджмент организации. Требования к системам менеджмента качества организаций, поставляющих продукцию и предоставляющих услуги в нефтяной, нефтехимической и газовой промышленности: 3.1.6 валидация проекта… … Словарь-справочник терминов нормативно-технической документации
Software performance testing — In software engineering, performance testing is testing that is performed, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such… … Wikipedia