Перспективу тщательной проверки спецификации требований к ПО, состоящей из нескольких сотен страниц, можно смело назвать ужасающей. Вам покажется заманчивым пропустить проверку и сразу приступить к конструированию — тоже не самый мудрый выбор. Даже в спецификации среднего размера, как правило, все эксперты тщательно проверят первую часть, несколько наиболее стойких изучат середину, но маловероятно, чтобы кто-то дошел до конца.
Чтобы избежать перегрузок, проверяйте документ по мере его разработки, не ждите, когда он будет закончен. Определите области повышенного риска, которые требуют тщательной экспертизы — для менее важных фрагментов хватит и неофициального просмотра. Попросите определенных инспекторов начать с различных частей документа, это позволит окинуть каждую страницу свежим взглядом. Возможно, следует использовать несколько небольших команд для проверки различных фрагментов документа, однако при этом вы рискуете не заметить несогласованности. Чтобы оценить, требуется ли проводить экспертизу всей спецификации, исследуйте репрезентативную выборку фрагментов. Изучив количество и типы обнаруженных ошибок, вы определите, стоит ли проводить полную проверку (Gilb и Graham, 1993).
Большая команда экспертов. Многие участники проекта и клиенты хотят заниматься требованиями, поэтому список желающих может оказаться весьма длинным. Однако чем больше команда экспертов, тем труднее составить график совещаний, тем больше на них посторонних разговоров и тем труднее прийти к согласию по каждому вопросу.
Однажды я вместе с 13 инспекторами был приглашен на совещание, организованное человеком, который явно не понимал важность небольшой команды. Четырнадцати персонам трудно договориться, как выйти из горящей комнаты, не говоря уже о принятии решения, правильно ли данное требование. Попробуйте придерживаться следующих советов при работе с потенциально большими командами инспекторов:
|
|
· убедитесь, что каждый участник понимает, что его задача — выявлять дефекты, а не повышать квалификацию или отстаивать позицию;
· четко представьте себе, чью точку зрения (клиента, разработчика или тестировщика) представляет каждый участник. Тактично отклоните участие лиц, готовых отстаивать точку зрения, которая уже представлена. Если несколько человек относятся к одной группе, они могут объединить свою информацию и делегировать для участия в совещании кого-то одного;
· соберите несколько небольших групп для параллельной проверки спецификации требований к ПО и объедините их контрольные списки дефектов в один, удалив все повторы. Исследования показали, что экспертиза документа о требованиях, выполняемая несколькими командами, выявляет больше ошибок, чем одна большая команда (Martin и Tsai, 1990; Schneider, Martin и Tsai, 1992; Kosman, 1997), Как правило, результаты параллельных проверок скорее дополняют, чем повторяют друг друга.
Географическое разделение инспекторов. Все больше компаний разрабатывают продукты, привлекая команды, разъединенные географически. В этом случае проверки проводить труднее. Видеоконференции могут стать эффективным решением, но в телеконференциях вы не можете воспринимать язык тела и мимику других участников, как при личных встречах.
Просмотр электронного файла, размещенного в общей сетевой папке, — метод, альтернативный традиционным совещаниям экспертов (Wiegers, 2002а). В этом случае рецензенты используют функции текстового редактора, чтобы ввести свои комментарии в проверяемый документ. Каждый комментарий помечается инициалами эксперта, таким образом, любой может ознакомиться с мнением других рецензентов. ПО, поддерживающее совместную работу через Web встроено в такие инструменты как, ReviewPro компании Software Development Technologies (https://www.sdtcorp.com). Если вы решите не проводить совещания, то отдавайте себе отчет, что при этом результативность инспектирования снизится примерно на 25% (Humphrey, 1989), однако стоимость экспертизы также уменьшится.
|
|
Тестирование требований
Трудно представить себе, как система будет функционировать при определенных условиях только на основании прочитанной спецификации требований к ПО. Варианты тестирования, созданные на основании функциональных или пользовательских требований, помогают участникам проекта получить представление об ожидаемом поведении системы. Просто разработка вариантов тестирования поможет выявить множество проблем с требованиями, даже если вы не станете выполнять тесты (Beizer 1990). Если вы начнете разрабатывать варианты тестирования сразу после стабилизации некой части требований, вам удастся обнаружить проблемы, которые еще можно устранить с минимальными затратами.
| Ловушка Остерегайтесь тестировщиков, которые утверждают, что не могут приступить к работе, пока требования еще формируются, и тех, которые утверждают, что для тестирования ПО им не нужны требования. Тестирование и требования связаны между собой синергетическими отношениями, поскольку они представляют дополняющие взгляды на систему. |
|
|
При написании вариантов тестирования (функциональность) кристаллизуется ваше понимание того, как система должна себя вести при определенных условиях. Неясные и двусмысленные требования будут отскакивать от вас, поскольку вы не сможете описать ожидаемую реакцию систему. Когда аналитики, разработчики и клиенты вместе создают варианты тестирования, они вырабатывают общее понимание того, как продукт будет работать.
| Как сделать Чарли счастливым Как-то раз я попросил Чарли, профи в написании сценариев для UNIX в моей группе, сконструировать простое расширение интерфейса электронной почты для коммерческой системы отслеживания дефектов, которой мы пользовались. Я написал дюжину функциональных требований, описывающих, как должен работать интерфейс электронной почты. Чарли пришел в возбуждение. Он создал множество сценариев, но до сих пор не видел ни одного требования в письменной форме. К сожалению, я промедлил пару недель, прежде чем написал варианты тестирования для этой функции электронной почты. Разумеется, я допустил ошибку в одном из требований. Я обнаружил ее, поскольку мое представление о том, как функция должна работать, раскрытое в 20 контрольных примерах, оказалось несовместимо с одним из требований. Раздосадованный, я исправил требование с ошибкой, еще до того, как Чарли завершил разработку, и в законченном варианте не было ни одной ошибки. Это маленькая победа, но даже маленькие победы имеют смысл. |
Вы можете заняться созданием концептуальных вариантов тестирования, основываясь на вариантах использования продукта или других представлениях пользовательских требований, уже на ранней стадии процесса разработки (Ambler, 1995; Collard, 1999; Armour и Miller, 200"). Также варианты использования пригодятся вам для оценки текстовых требований, моделей анализа и прототипов. Варианты тестирования должны охватывать нормальную линию поведения варианта использования продукта, альтернативные направления, а также исключения, идентифицированные в ходе сбора информации и анализа. Эти концептуальные (или абстрактные) варианты тестирования не зависят от реализации. Для примера рассмотрим вариант использования «Просмотр заказа» (View Order) для Chemical Tracking System. Концептуальные варианты тестирования могут быть следующими:
· пользователь вводит номер заказа, который он хочет просмотреть - этот заказ существует - пользователь разместил заказ. Ожидаемый результат: отображение заказа детально;
· пользователь вводит номер заказа, который он хочет просмотреть - этот заказ не существует. Ожидаемый результат: появляется сообщение: «К сожалению, заказ не найден»;
· пользователь вводит номер заказа, который он хочет просмотреть - этот заказ существует - но он размещен не этим пользователем. Ожидаемый результат: появляется сообщение: «К сожалению, это не ваш заказ».
В идеале разработчик пишет функциональные требования, а тестировщик — варианты тестирования на основе одних и тех же материалов (одна исходная точка на рис. 15-6) — пользовательских требований. Неясности в пользовательских требованиях и различные интерпретации выливаются в несогласованность функциональных требований, моделей и вариантов тестирования. По мере того, как разработчики преобразовывают требования в пользовательский интерфейс и технический дизайн, тестировщики могут переработать концептуальные тесты в детально проработанные процедуры тестирования для официального тестирования системы (Hsia, Кипди Sell, 1997).
Рис. 15-6. Разработка и тестирование продуктов имеют один общий источник
Сначала вам может показаться, что тестирование требований — абстрактная категория. Давайте посмотрим, как команда разработчиков Chemical Tracking System связала вмести спецификации требований, моделирование анализа и первую стадию создания вариантов тестирования. Далее рассматриваются бизнес-требование, вариант использования продукта, некоторые функциональные требования, часть карты диалогов, а также вариант тестирования, которые связаны с задачей запроса химиката.
Бизнес-требование. Одна из основных бизнес-целей Chemical Tracking System такова:
«Эта система сэкономит компании в первый год применения 25% затрат на химикаты, позволив полностью использовать химикаты, уже имеющиеся в распоряжении компании…»
| Дополнительная информация Бизнес-требование взято из документа об образе и границах проекта, описанного в главе 5. |
Вариант использования продукта. Вариант использования продукта, поддерживающий это бизнес-требование, называется «Запрос химиката» (Request a Chemical). Он позволяет пользователю запросить, контейнер с химикатом, который уже имеется в наличии на складе химикатов. Вот как звучит описание варианта использования:
«Сотрудник, размещающий заказ на химикат, указывает в запросе желаемый химикат, вводя его название или номер идентификатора химиката или импортируя его структуру из инструмента для рисования. Система удовлетворяет запрос, предлагая новый или бывший в употреблении контейнер с химикатом со склада химикатов, либо позволяя создать запрос для заказа химиката у стороннего продавца»
| Дополнительная информация Этот вариант использования продукта показан на рис. 8-6. |
Функциональное требование. Здесь показана некоторая функциональность, связанная с этим случаем использования продукта.
1. Если на складе есть контейнеры с химикатами, на которые поступил запрос, система отобразит список доступных контейнеров;
2. Пользователь либо выберет один из перечисленных контейнеров или попросит разместить запрос на заказ нового контейнера у продавца.
Карта диалогов. На рис. 15-7 показана часть карты диалогов для варианта использования «Запрос химиката», которые имеют отношение к этой функции. Прямоугольники на этой карте диалогов представляют изображения пользовательского интерфейса, а стрелки показывают возможные пути перехода от одного изображения к другому.
| Дополнительная информация Подробнее о картах диалогов рассказано в главе 11. |
Рис. 15-7. Фрагмент карты диалогов для варианта использования «Запрос химиката»
Контрольный пример. Поскольку для этого варианта использования существует несколько возможных путей выполнения, вы можете придумать несколько вариантов тестирования для обработки нормального направления, альтернативных направлений и исключений. Ниже показан вариант тестирования, когда пользователю отображаются контейнеры, доступные на складе. Этот вариант тестирования разработан на основе описания варианта использования этой задачи пользователя и карты диалогов с рис. 15-7.
«В диалоговом окне DB40 введите действительный идентификатор химиката; на складе имеются два контейнера с этим химикатом. Откроется диалоговое окно IDB50, в котором показаны два контейнера. Выберите второй контейнер. DB50 закроется, и контейнер 2 будет добавлен в конец списка текущих запросов на химикаты в диалоговом окне DB70»
Рамеш, руководитель тестирования Chemical Tracking System, написал несколько вариантов тестирования, похожих на этот, исходя из своего понимания того, как пользователь может взаимодействовать с системой для запроса химиката. Такие абстрактные варианты тестирования не зависят от деталей реализации. В них не разъясняется ввод данных в поля, щелчки кнопок или другие особые детали взаимодействия. По мере разработки пользовательского интерфейса Рамеш возвращался к этим абстрактным вариантам тестирования, создавая более точные процедуры тестирования.
А теперь самое интересное — тестирование требований с помощью вариантов тестирования. Сначала Рамеш соединил на карте каждый вариант тестирования с функциональными требованиями. Он проверил и убедился, что вариант тестирования может быть выполнен при существующем наборе требований. Он также убедился, что по крайней мере один вариант тестирования связан с каждым функциональным требованием. Затем Рамеш проследил путь исполнения каждого варианта тестирования по карте диалога с помощью маркера. Толстая линия на рис. 15-8 показывает, путь предыдущего варианта тестирования на карте диалогов.
Рис. 15-8. Отслеживание варианта тестирования на карте диалогов для варианта использования «Запрос химиката»
Отслеживая путь исполнения для каждого варианта тестирования, вы можете найти некорректные или пропущенные требования, исправить ошибки на карте диалогов и отшлифовать варианты тестирования. Предположим, что после «исполнения» всех вариантов тестирования в этом случае линия на карте диалогов, помеченная как «заказать новый контейнер» от DB50 к DB60 на рис. 15-7 не была выделена. Возможны два объяснения этому:
· перемещение от DB50 к DB60 не допускается поведением системы. Аналитик должен убрать эту линию с карты диалогов. Если в спецификации есть требование, в котором указан этот переход, то это требование также необходимо удалить;
· перемещение допустимо поведением системы, но вариант тестирования, который демонстрирует это поведение, отсутствует.
Точно так же, предположим, что вариант тестирования, доступный пользователю, позволяет перейти непосредственно от диалогового окна DB40 к DB70. Однако в диалоговом окне на рис. 15-7 такой линии нет, и поэтому вариант тестирования не может быть выполнен с существующими требованиями. И опять же возможны две интерпретации, и вам необходимо определить, какая из них верна:
· перемещение от DB40 к DB70 не допускается поведением системы, следовательно, вариант тестирования неправильный;
· перемещение от DB40 к DB70 допускается поведением системы, но на карте диалогов и, возможно, в спецификации требований к ПО отсутствует требование, позволяющее выполнить вариант тестирования.
В этих примерах аналитик и тестировщик объединили требования, модели анализа и варианты тестирования для выявления пропущенных, ошибочных или ненужных требований задолго до того, как разработчики приступили к написанию кода. Концептуальное тестирование требований к ПО — мощный прием управления затратами и графиком проекта, так как он позволяет выявлять неясности и ошибки в требованиях в начале игры. Каждый раз, когда я использую этот прием, я нахожу ошибки во всех элементах, которые сравниваю друг с другом. Как сказал Ross Collard (1999):
Варианты использования продукта и варианты тестирования отлично взаимодействуют в двух случаях: если варианты использования написаны полно, аккуратно и ясно, то процесс составления вариантов тестирования становится крайне простым; а если варианты использования не в лучшей форме, то попытка составления вариантов тестирования поможет вам отладить вариант использования продукта.