- PVSM.RU - https://www.pvsm.ru -
Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:
В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.
В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!
Давайте будем идти по порядку, как это нам предлагает методология. И начать следует с
Если нет общего понимания терминологии, то возможно, это признак того, что заинтересованные стороны на самом деле не договорились о других вещах? Это могут быть цели бизнеса, бизнсс-процессы или функции, которые требуются системе. Простая проверка терминологии может выявить серьезные недостатки в самом понимании проекта
Поэтому начинать надо с того, что мы считаем нашим словарем и откуда в нем определения. Это могут быть обыкновенные словари, какие-либо книги, корпоративные стандарты и так далее. Задайте себе вопрос о том, точно ли вы понимаете значения существительных и глаголов? Обязательно запомните откуда вы берете это определение. Обратите внимание, не вызывает ли оно каких-либо противоречий с тем, что вы уже знаете.
И самое главное — попросите вашего заказчика вместе с вами проверить, что все это верно.
Что касается нашего случая, полезным будет узнать:
Когда мы говорим о требованиях, надо мыслить фичами и визуализировать именно их, а не абстрактный UML в вакууме. И визуализация позволяет понять это гораздо четче, потому что каждый процесс отображается через свои шаги и каждый шаг и становится фичей. За счет этого прием Story Mapping и дает такой классный результат.
Так вот, когда вы читаете требования, обращайте внимания на следующие вещи, которые являются самостоятельными фичами:
Для нашего случая, явным образом выделяются следующие фичи:
Больше, чем что-либо другое, требования должны описывать результаты работы. Результаты это то, чего мы хотим от системы. Обычно в тексте требований результаты легко выделить по следующим паттернам:
Соответственно, результаты работы систему могут ссылаться на веб-страницы, где отображаются результаты, отчеты и так далее. Так же они могут относиться к поведению системы, которое мы видим как пользователи через интерфейс или в виде медиа выдачи (видео, например).
Часто результат, который не явно не видим, наблюдается сообщением, который информирует пользователя о том, что произошло. Соответственно, результатом работы системы может быть «ничего». Типичным примером здесь будет реакция системы на попытки взлома или подбора пароля.
Возвращаясь к нашим требованиям. Нам было бы полезно видеть:
Мы наконец-то подошли к сценариям (но это еще не конец нашей работы), и теперь можем комбинировать все то, что нарыли на предыдущих этапах. При этом обращаем внимание на следующие вещи:
(Кстати, все это и делает сценарий отличным тест-кейсом).
Например,
Изначально склад пуст и может хранить 100 мешков картошки, когда мы добавляем 1 мешок картошки, мы видим, что процент заполненности склада стал 1%
Идем дальше.
Начинаем проверять наши сценарии на логику. Всегда понятно, почем из мы получаем именно тот результат, который в сценарии описан. Если нет, это чаще всего означает что пропущен тот или иной шаг, или даже описаны не все условия. Это возвращает нас на этап визуализации процесса в целом.
(Мой любимый этап) Для этого этапа полезно представлять сценарии в виде таблицы, которая потом так же найдет свое применение.
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 |
И начинаем после этого смотреть на следующие вещи:
На этом этапе начинают всплывать такие вещи, как:
На самом деле, этот этап неявно проскальзывал уже несколько раз, но стоит упомянуть его еще раз. Например, еще и по той причине, что после того, как мы получили классные сценарии, мы забли обновить глоссарии, исходные документы и так далее.
На этом этапе так же полезно видеть таблицу сценариев, так он позволяет быстрее ориентироваться в них и находить пробелы.
Дальше мы берем BDD фреймворк и начинаем писать код! Об этом я расскажу, а точнее покажу как это делается в ближайшем вебинаре. Следите за новостями!
Кстати, а вот и сам вебинар про общую теорию подхода Spec By Example
Автор: mythmaker
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/28227
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/170919/
Нажмите здесь для печати.