Критерии Приёмки

Критерии Приёмки (здесь и далее по тексту -- Лектио) -- это часть урока Суть Приёмки Работ. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.

Материалы

Предшественник этого Лектио -- Тесты Приёмки.

Текст

Критерии Приёмки

Критерии приемлемости (acceptance criteria или AC) -- это набор стандартов, который применяется для принятия решения о готовности чего-либо к передаче, применению или употреблению. Речь может идти о готовности различных вещей от одной характеристики изделия до предмета контракта.

Критерии приемлемости выполненного требования формируются исходя из требования.

и, потому, завершению разработки. 

изделия или другого продукта к передаче заказчику, конечным пользователям или уполномоченному органу. Если итоги приёмочных тестов сравнить с оценками, критерии приемлемости будут проходным баллом. Критерии приемлемости устанавливаются заказчиком и принимаются подрядчиком.

это условия, которым должен соответствовать программный продукт, чтобы его принял пользователь, заказчик или другая система.

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

Наконец, некоторые Проверки зависят от использования продуктов конечными пользователями и их производительности.

Специально организованное Тестирование может затрагивать конкретные проблемы или области, требующие улучшения. Например, рабочее тестирование продукта оценивает функциональность рабочих продуктов, производительность тех команд, которые их разработали, и/или другие результаты разработки. Юзабилити-тестирование направлено на поиск областей для улучшения и удобства пользовательского опыта (UX). Приемочные испытания проводятся для проверки того, соответствует ли разработанная система требованиям завершения, обычно называемым критериями приемки. То есть готов ли продукт для следующей эксплуатации.

Большинство Ручных Тестов включает в себя контроль того, соответствует ли рабочий продукт его требованиям, поиск ошибок, проблем с пользовательским интерфейсом и/или областей для улучшений при ручном выполнении действий на веб-сайте, мобильном приложении или другом приложении конечного пользователя.

Другой пример, проверка этого самого лектио, которое Вы сейчас читаете или слушаете, может тестировать различные требования к её тексту, объёму, количеству слов в предложениях, соответствие нормам русского языка и так далее. Однако только Ваше понимание разницы между приёмкой и проверкой может подтвердить, что лектио готово. Если большой процент учащихся не будут осознавать разницу, то требования необходимо будет пересмотреть и лектио надо будет обновить.

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

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

Критерии приемки: цели, форматы и передовой опыт

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

Это когда качественная документация по программному обеспечению может помочь избежать проблемы. Пользовательские истории и критерии приемки (AC) как основные форматы документирования требований. Пользовательская история - это описание функции на естественном языке. Обычно он сопровождается критериями приемлемости.

Критерии приемлемости (AC) - это условия, которым должен соответствовать программный продукт, чтобы его принял пользователь, заказчик или другая система. Они уникальны для каждой пользовательской истории и определяют поведение функции с точки зрения конечного пользователя. Хорошо написанные критерии приемки помогают избежать неожиданных результатов в конце этапа разработки и гарантировать, что все заинтересованные стороны и пользователи удовлетворены тем, что они получают.

Критерии приемки - функциональные требования самого низкого уровня

Критерии приемки - это функциональные требования самого низкого уровня. Критерии приемки основные цели

Разъяснение требований заинтересованных сторон - задача высокого уровня. Чтобы сделать цели AC более ясными, давайте разберем их.

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

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

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

Оптимизация приемочного тестирования. AC являются основой приемочного тестирования пользовательской истории. Каждый критерий приемки должен подвергаться независимому тестированию и, таким образом, иметь четкие сценарии успешности или неудачи. Их также можно использовать для проверки истории с помощью автоматических тестов.

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

AC можно записывать в разных форматах. Есть два наиболее распространенных варианта, и третий вариант - разработать собственный формат:

   ориентированный на сценарий (Учитывая / Когда / Тогда)
   ориентированный на правила (контрольный список)
   специальные форматы

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

Сценарийно-ориентированный формат записи AC известен как тип Given / When / Then (GWT).

   Учитывая некоторые предварительные условия
   Когда я делаю какое-то действие
   Тогда я жду результата

Этот подход унаследован от разработки, основанной на поведении (BDD), и обеспечивает согласованную структуру, которая помогает тестировщикам определять, когда начинать и когда завершать тестирование той или иной функции. Это также сокращает время, затрачиваемое на написание тестовых примеров, поскольку поведение системы описывается заранее.

Каждый критерий приемки, написанный в этом формате, содержит следующие утверждения:

   Сценарий - название поведения, которое будет описано
   Дано - начальное состояние сценария
   Когда - конкретное действие, которое совершает пользователь
   Затем - результат действия в «Когда».
   И - используется для продолжения любого из трех предыдущих утверждений

В совокупности эти утверждения охватывают все действия, которые пользователь предпринимает для выполнения

Поставьте задачу и ощутите результат.

Давайте посмотрим на несколько примеров.

Пример 1

История пользователя: Как пользователь, я хочу иметь возможность восстановить пароль своей учетной записи, чтобы иметь доступ к своей учетной записи в случае, если я забыл пароль.

Сценарий: Забыли пароль

Дано: пользователь перешел на страницу входа

Когда: пользователь выбрал опцию забытого пароля

И: Ввели действующий адрес электронной почты, чтобы получить ссылку для восстановления пароля.

Затем: Система отправила ссылку на введенный адрес электронной почты.

Дано: пользователь получил ссылку по электронной почте

Когда: пользователь перешел по ссылке, полученной в электронном письме.

Затем: Система позволяет пользователю установить новый пароль.

Пример 2

История пользователя: Как пользователь, я хочу иметь возможность запрашивать наличные со своего счета в банкомате, чтобы получать деньги со своего счета быстро и в разных местах.

Критерии приемки 1:

При условии, что счет кредитоспособен

И: карта действительна

И: в диспенсере есть наличные

Когда: клиент запрашивает наличные

Затем: убедитесь, что счет списан

И: обеспечить выдачу наличных

И: убедитесь, что карта возвращена

Критерии приемки 2:

Учитывая: что на счету овердрафт

И: карта действительна

Когда: клиент запрашивает наличные

Затем: убедитесь, что отображается сообщение об отказе

И: убедитесь, что наличные не выдаются Формат критериев приемлемости, ориентированный на правила

В некоторых случаях сложно вписать критерии приемки в структуру Given / When / Then. Например, GWT вряд ли пригодится в следующих случаях:

   Вы работаете с пользовательскими историями, которые описывают функциональные возможности системного уровня, требующие других методов обеспечения качества.
   Целевая аудитория для критериев приемлемости не нуждается в точных деталях тестовых сценариев.
   Сценарии GWT не подходят для описания дизайна и ограничений пользовательского опыта функции. Разработчики могут упустить ряд важных деталей.

Вы можете решить эти случаи с помощью ориентированного на правила формата AC.

Форма, ориентированная на правила, предполагает наличие набора правил, описывающих поведение системы. Исходя из этих правил, можно рисовать конкретные сценарии.

Обычно критерии, составленные с помощью этой формы, выглядят как простой маркированный список. Давайте посмотрим на пример.

пример

История пользователя: как пользователь я хочу использовать поле поиска, чтобы ввести город, название или улицу, чтобы найти подходящие варианты отелей.

Основные критерии приемки интерфейса поиска

   Поле поиска находится на верхней панели
   Поиск начинается, когда пользователь нажимает «Поиск».
   Поле содержит заполнитель с текстом серого цвета: «Куда вы собираетесь?»
   Заполнитель исчезает, когда пользователь начинает печатать
   Поиск выполняется, если пользователь вводит город, название отеля, улицу или все вместе
   Поиск ведется на английском, французском, немецком и украинском языках.
   Пользователь не может набрать более 200 символов.
   Поиск не поддерживает специальные символы (символы). Если пользователь ввел специальный символ, покажите предупреждающее сообщение: «Поисковый ввод не может содержать специальные символы».

Другие форматы

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

Иногда ваши критерии могут быть указаны как пример поведения системы:

Пользовательский формат критериев приемки

Простой набор AC для надежных паролей от Марка Левисона для agilepainpainrelief.com

Этот подход дает четкие рекомендации по тестированию функций паролей. Ответственные роли и как создаются критерии приемки

Некоторые критерии определяются и записываются владельцем продукта при создании бэклога продукта. А остальные могут быть дополнительно указаны командой во время обсуждения пользовательских историй после планирования спринта. Строгих рекомендаций по выбору ответственного за написание критериев нет. Клиент может задокументировать их, если он или она имеет достаточные знания в области технической документации и документации продукта. В этом случае клиент согласовывает критерии с командой, чтобы избежать взаимных недоразумений. В противном случае критерии создаются владельцем продукта, бизнес-аналитиком, аналитиком требований или менеджером проекта.

как создать критерии приемки

Процесс начинается с определения приоритетов пользовательской истории и заканчивается согласованием деталей со всей командой. Основные проблемы и лучшие практики написания критериев приемки

Критерии приемки выглядят так, как будто их очень легко написать. Несмотря на их упрощенные форматы, написание текста представляет собой проблему для многих команд. Давайте подробнее рассмотрим передовые методы, которые помогут избежать распространенных ошибок.

Документируйте критерии перед разработкой. Критерии приемки должны быть задокументированы до начала фактической разработки. Таким образом, команда, скорее всего, заранее уловит все потребности клиентов. Вначале достаточно установить критерии для небольшого количества пользовательских историй, чтобы заполнить бэклоги для двух спринтов (если вы практикуете Scrum или аналогичный метод). Они должны быть согласованы обеими сторонами. Затем задокументированные критерии приемки используются разработчиками для планирования технического процесса.

Не делайте AC слишком узким. Критерии приемлемости могут быть слишком конкретными, поскольку для разработчиков практически нет маневра. Чтобы избежать этого, помните, что AC должен выражать намерение, но не окончательное решение. Более того, узкий AC может быть лишен множества действий пользователя, которые не рассматриваются.

Держите ваши критерии достижимыми. Эта точка близко пересекается с предыдущей. Эффективные критерии приемки определяют разумный минимальный объем функциональности, которую вы можете предоставить. Но если вы поддаетесь описанию всех мелких деталей, есть риск, что ваша команда застрянет на сотнях мелких задач.

Держите переменный ток поддающимся измерению и не слишком широким. Широкие критерии приемлемости делают историю пользователя расплывчатой. Эффективные критерии приемки должны определять объем работ, чтобы разработчики могли правильно спланировать и оценить свои усилия.

Избегайте технических подробностей. Как мы уже упоминали, критерии приемки должны быть написаны простым английским языком. Это сделает их ясными и понятными для всех: ваши заинтересованные стороны или менеджеры могут не иметь технического образования.

Достигайте консенсуса. Одна и та же проблема может быть решена по-разному командой и заинтересованными сторонами в зависимости от их точки зрения. Убедитесь, что вы сообщили свой AC заинтересованным сторонам и достигли взаимного согласия. То же самое и с членами команды. Каждый должен просмотреть AC и подтвердить, что он понимает и согласен с каждой строкой.

Напишите тестируемый AC. Это позволит тестировщикам убедиться, что все требования соблюдены. В противном случае разработчики не поймут, завершена ли пользовательская история. Последнее слово

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

Термины

Верификация, Валидация, Проверка, Приемка, Требования

Вопрос(ы)

Исходя из выше описанного текста: Проверка отвечает на вопрос, был ли разработан правильный продукт, так как он решает проблемы, которые должен был решить. -- Правда/Неправда

Следующее лектио -- Что Есть Отчетность