Критерии приемки для пользовательских историй



Ключевые слова : гибкая разработка (Agile), пользовательская история (User Story), критерии приемки, пользовательские требования

В проектах гибкой разработки пользовательские истории (User Stories, US) предназначены для документирования пользовательских требований с точки зрения взаимодействия пользователя и системы. Но в отличие от спецификации вариантов использования (Use Case Specification), которая обеспечивает всю необходимую информацию и может быть представлена с точки зрения формальной модели [1, с. 224], и поэтому, как правило, является частью спецификации требований программного обеспечения (Software Requirement Specification, SRS) [2], пользовательские истории содержат небольшое количество деталей и остаются открытыми для интерпретации. Таким образом, пользовательские истории представляют собой быстрый способ документирования требований клиента без необходимости разрабатывать и поддерживать обширные формализованные документы.

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

Поскольку программное обеспечение пишется для создания продукта, которое соответствует ви́дению заказчика, то критерии приёмки должны быть определены заказчиком [3, с. 83]. Для фактического составления критериев заказчик может работать с программистом или тестировщиком, но как минимум заказчик должен определить критерии, которые можно будет использовать для того, чтобы установить момент, когда история может считаться корректно разработанной. Кроме того, команда разработки обычно дополняет некоторые истории собственными критериями.

Таким образом, критерии приёмки предназначены главным образом для решения следующих задач:

— Определение границ пользовательской истории;

— Синхронизация ожиданий бизнеса и команды разработчиков;

— Служат основой для позитивного и негативного тестирования;

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

Существует несколько типов критериев приёмки. Наиболее популярными являются ориентированные на правила (в виде списка) и сценарии.

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

Наиболее распространенным шаблоном для написания критериев приёмки, ориентированных на сценарии, является формат «Given-When-Then» (GWT):

— Given (дано) — ситуация выглядит таким образом: есть некоторое состояние до того, как пользователь вошел в сценарий;

— When (когда) — затем пользователь совершает некоторые действия;

— Then (тогда) — теперь ситуация выглядит по-другому: система реагирует на действия пользователя.

Пример для функции поиска по веб-сайту:

Как посетитель веб-сайта Я хочу иметь возможность выполнить поиск по строке текста Чтобы найти разделы сайта, в которых находится интересующая меня информация

Сценарий: посетитель ищет информацию на сайте по строке текста Поскольку я нахожусь в роли посетителя, и система предоставляет мне строку поиска в правом верхнем углу экрана Когда я заполняю поле поиска строкой текста и нажимаю кнопку «Найти» или клавишу ENTER на клавиатуре Тогда система открывает модальное окно с результатами поиска, в которых есть совпадения с введённой мной строкой текста. Результаты могут включать в себя номера журналов, мангу и новостные статьи. Все результаты упорядочены по приоритету (журналы идут в начале списка). Система отображает количество найденных результатов поиска в левой верхней части модального окна. В правой верхней части окна располагается кнопка «Закрыть» и ниже фильтр, который позволяет упорядочить результаты поиска по категориям и дате публикации (в начале новые)

Сценарий для ошибочной ситуации: посетитель ищет информацию на сайте по строке текста, которая содержит специальные символы или нарушает ограничения поиска Когда я заполняю поле поиска строкой текста, которая нарушает заданные ограничения поиска или содержит специальные символы, и нажимаю кнопку «Найти» или клавишу ENTER на клавиатуре Тогда система открывает модальное окно, в котором показывает сообщение: «Произошла ошибка при выполнении поиска» Система предлагает проверить данные для поиска или написать в службу поддержки, если ошибка повторяется систематически

В отличие от спецификации вариантов использования, которая пишется в безличной форме, поскольку является частью формализованного документа, сценарии для критериев приёмки как правило пишут от первого лица с использованием личного местоимения, что позволяет представить ситуацию с точки зрения пользователя. Тем не менее, и варианты использования и критерии приёмки для пользовательских историй пишутся на повседневном языке пользователя для облегчения взаимодействия между заинтересованными сторонами проекта. Поэтому узко специализированные термины, сложные слова и компьютерный сленг не должны использоваться как при написании историй, так и спецификации вариантов использования [4, с. 45].

Пример для формы обратной связи:

Как посетитель веб-сайта Я хочу иметь возможность оставлять отзывы Чтобы владелец системы мог учесть мои пожелания или замечания при будущих обновлениях системы

Сценарий: посетитель отправляет отзыв о работе системы через форму обратной связи Поскольку я нахожусь в роли посетителя, и система предоставляет мне ссылку на форму обратной связи Когда я перехожу по данной ссылке Тогда система открывает модальное окно с формой для отправки отзыва, которая содержит «Адрес электронной почты», «Имя пользователя», «Комментарий» и включает возможность прикреплять дополнительные файлы (фото и скриншоты) через интерфейс «drag and drop» или проводник Когда я заполняю указанные поля, прикрепляю дополнительные файлы (опционально) и нажимаю кнопку «Отправить отзыв» Тогда система сохраняет мой отзыв, показывает всплывающее сообщение «Вы успешно отправили отзыв» и затем закрывает модельное окно для формы обратной связи

Сценарий для ошибочной ситуации: посетитель пытается загрузить файл неподдерживаемого формата Когда я загружаю файл неподдерживаемого формата Тогда система отменяет загрузку файла и уведомляет, что разрешены файлы следующих форматов: JPG / JPEG / JFIF / WEBP / PNG / GIF

Сценарий для ошибочной ситуации: посетитель пытается загрузить файл размером более 1024 Кбайт Когда я загружаю файл, который превышает заданные ограничения на размер Тогда система отменяет загрузку файла и уведомляет, что допускаются файлы размером до 1024 Кбайт включительно

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

Тип критериев приёмки, ориентированный на правила, для истории поиска по веб-сайту выглядит следующим образом:

В правом верхнем углу страницы отображается строка поиска с кнопкой «Найти»; Строка поиска присутствует на каждой странице; Результаты поиска отображаются в модальном окне; Результаты поиска могут включать в себя номера журналов, мангу и новостные статьи; Все результаты поиска упорядочены по приоритету (журналы идут в начале списка); В левой верхней части модального окна показано количество найденных результатов поиска; В правой верхней части окна находится кнопка «Закрыть»; В правой верхней части окна под кнопкой «Закрыть» располагается фильтр, который позволяет упорядочить результаты поиска по категориям и дате публикации (в начале новые); В случае если строка текста содержит специальные символы или нарушает ограничения поиска, система открывает модальное окно, в котором показывает сообщение «Произошла ошибка при выполнении поиска», и предлагает проверить данные для поиска или написать в службу поддержки

Тип критериев, ориентированный на сценарии, удобнее в использовании, поскольку он написан причинно-следственным образом. Кроме того, тестировать сценарии проще, чем набор правил.

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

Литература:

1. Вигерс, Карл. Разработка требований к программному обеспечению = Software Requirements: пер. с англ.; 3-е издание, дополненное / Карл Виггерс, Джой Битти — СПб.: Издательство «BHV», 2020. — 736 с.
2. ISO/IEC/IEEE 29148:2018 International Standard — Systems and software engineering — Life cycle processes — Requirements engineering [Электронный ресурс]. URL: https://www.iso.org/standard/72089.html (дата обращения: 18.12.2024)
3. Кон Майк. Пользовательские истории. Гибкая разработка программного обеспечения = User Stories Applied: For Agile Software Development: пер. с англ. / Майк Кон. — М.: Издательство «Вильямс», 2018–256 с.
4. Lee C. The Art of Crafting User Stories: Unleash creativity and collaboration to deliver high-value products with a delightful user experience / Christopher Lee. Packt Publishing, 2023. — 192 p.