Spec By Example на примере одного требования

в 11:48, , рубрики: agile, bdd, Блог компании ScrumTrek, тестирование, управление требованиями, метки: , ,

Spec By Example на примере одного требования

Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:

В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.

В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!

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

Определения (Definitions)

Если нет общего понимания терминологии, то возможно, это признак того, что заинтересованные стороны на самом деле не договорились о других вещах? Это могут быть цели бизнеса, бизнсс-процессы или функции, которые требуются системе. Простая проверка терминологии может выявить серьезные недостатки в самом понимании проекта

Поэтому начинать надо с того, что мы считаем нашим словарем и откуда в нем определения. Это могут быть обыкновенные словари, какие-либо книги, корпоративные стандарты и так далее. Задайте себе вопрос о том, точно ли вы понимаете значения существительных и глаголов? Обязательно запомните откуда вы берете это определение. Обратите внимание, не вызывает ли оно каких-либо противоречий с тем, что вы уже знаете.
И самое главное — попросите вашего заказчика вместе с вами проверить, что все это верно.

Что касается нашего случая, полезным будет узнать:

  • что вообще будет храниться на складе?
  • есть ли зоны спец-товаров, например, холодильник?
  • как происходит процесс отгрузки/приема?
Функционал (Features)

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

  • Именованные фичи — пользователи и аналитики, возможно, уже решили, какие функции они хотели бы видеть в системе. Примерами могут быть «Ввод заказа», «Экран поиска», «Отчет о состоянии дел.
  • Фразы вроде: «Система будет {глагол} {объект} '. Типовые глаголы: добавлять, обновлять, удалять, обрабатывать и так далее. Объектом может быть любая сущность или процесс в система, например, клиент, заказ, продукт, человек, счета-фактуры и так далее.

Для нашего случая, явным образом выделяются следующие фичи:

  • отгрузка товара со склада
  • прием товара на склад
  • регистрация товара на складе
Результаты (Outcomes)

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

  • активное проявление — «ситема будет»
  • пассивное проявление — «правильный результат работы это...» или «неправильный результат работы это...»

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

  • процентное наполнение склада
  • информацию о том, что место заканчивается
Сценарии (Scenarios)

Мы наконец-то подошли к сценариям (но это еще не конец нашей работы), и теперь можем комбинировать все то, что нарыли на предыдущих этапах. При этом обращаем внимание на следующие вещи:

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

(Кстати, все это и делает сценарий отличным тест-кейсом).
Например,
Изначально склад пуст и может хранить 100 мешков картошки, когда мы добавляем 1 мешок картошки, мы видим, что процент заполненности склада стал 1%
Идем дальше.

Прогноз (Prediction)

Начинаем проверять наши сценарии на логику. Всегда понятно, почем из мы получаем именно тот результат, который в сценарии описан. Если нет, это чаще всего означает что пропущен тот или иной шаг, или даже описаны не все условия. Это возвращает нас на этап визуализации процесса в целом.

Двусмысленность (Ambiguity)

(Мой любимый этап) Для этого этапа полезно представлять сценарии в виде таблицы, которая потом так же найдет свое применение.

Customer type Cart contents Delivery
VIP 1 book Free
VIP 10 books Free
VIP 11 books Standard
Regular 10 books Standard
VIP 5 washing machines Standard
VIP 1 washing machine 5 books Standard

И начинаем после этого смотреть на следующие вещи:

  • есть ли случаи, когда данные не отличаются или отличаются незначительно, а результат кардинально разный
  • если случай, когда разные данные ведут к одному результату

На этом этапе начинают всплывать такие вещи, как:

  • разные определения одного функционала
  • скрытые шаги
  • неоднозначное понимание терминологии
  • и так далее
Пробелы (Missing)

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

Что дальше?

Дальше мы берем BDD фреймворк и начинаем писать код! Об этом я расскажу, а точнее покажу как это делается в ближайшем вебинаре. Следите за новостями!

Кстати, а вот и сам вебинар про общую теорию подхода Spec By Example

Автор: mythmaker

Источник

Поделиться

* - обязательные к заполнению поля