Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Тема В соответствии с гра фиком, составленным председателем Вводное заседание 1-й день 2-й день 3-й день 4-й день 5-й день 6 день Члены комиссии и заинте ресованные лица Члены комиссии Члены комиссии Члены комиссии Члены комиссии и группы экспертов по исходным материалам Члены комиссии и группы экспертов по исходным материалам Члены подкомиссии Инструктаж 2 заседания с участием экспертов по исходным материалам 4 заседания с участием экспертов по исходным материалам 4 заседания с участием экспертов по исходным материалам 2 заседания с участием экспертов по исходным материалам 2 рабочих заседания 4 рабочих заседания Организация и встреча с оформителем техниче ской документации Совершенная поддержка Совершенная поддержка Совершенная поддержка Совершенная поддержка Глава 8. Совместная разработка требований к приложению (JAR) 177 Опытный председатель комиссии JAR запасется, по меньшей мере, несколькими сотнями чистых листов бумаги формата 8,5x11 дюймов (А4), десятком катушек лип кой ленты, несколькими десятками разноцветных шариковых ручек, подставкой для документов, разноцветными маркерами, ножницами, наклейками и целлофановой лентой. Эти материалы будут использоваться во время подготовки и поддержки на стенных плакатов, на которых отражаются требования. Расположение плакатов на стенах конференц-зала должно соответствовать струк туре документа описания требований. На заглавных листах могут быть напечатаны названия разделов этого документа. Они могут подвешиваться на верхней части сте ны, через равные промежутки, и должны располагаться по часовой стрелке в соот ветствии со структурой документа. Каждый плакат будет иметь соответствующий заглавный лист. На шаблоне плака та, приведенном на рис. 8.2, показано, как вводить требование и с помощью клейкой ленты прикреплять этот лист под соответствующим заглавным листом. Инструктаж по созданию подобного плаката из чистого листа бумаги, должен проводится на уста новочном заседании. Шаблон не должен содержать заранее впечатанной информа ции, поскольку это будет препятствовать спонтанности, которую автор должен про являть во время заполнения плаката с требованиями. Прикреплять листы формата 8,5x11 дюймов на стенку следует только за верхние углы, соблюдая альбомную ориен тацию. Это позволит при необходимости поднимать плакаты вверх и перемещать их на другую часть стенки, если потребуется сгруппировать их с другим требованием. 178 Часть II. Технологии быстрого тестирования и советы Строка названия темы должна совпадать с заглавным листом, помещенным на стенку. Если плакат перемещается в набор плакатов, расположенных под другим за главным листом, эта строка должна быть изменена. Формулировка — это краткое из ложение формулируемого требования. Она может представлять собой уточнение об ласти действия требования, описание применяемых интерфейсов или касаться лю бых других вопросов, требующих прояснения. В правой части плаката размещается диаграмма, в которой требование представляется в графическом виде. В одном слу чае это может быть диаграмма взаимодействий, в которой показаны соединения ме жду элементами. В другом случае это могут быть фигурки беседующих людей, изобра жающие процесс опроса вручную. В третьем — диаграмма взаимодействия одной под системы компьютерной программы с другой через базу данных. Обычно под графи ческой диаграммой помещается ее название. Выполняя действия по совершенной поддержке, членам комиссии приходится часто подходить к стенам помещения. Эти действия не отражаются в календарном графике JAR, поэтому по мере необходимости председатель должен время от време ни требовать от членов комиссии, чтобы они подходили к стенам, внимательно изу чали каждый плакат и фиксировали предложения по изменениям, наклеенные непо средственно на плакаты. Эта форма ревизии тесно связана с процессом выработки требований. Обоснование написания наклеек приведено на рис. 8.3. Они служат для того, чтобы всем участникам стало понятно, что пора оказать помощь в обнаружении ошибок в требованиях или же четче сформулировать требования, а то и вовсе изме нить их расположение на стенке. На этом этапе совершенной поддержки изменения в самих плакатах не допускаются. • Совершенная поддержка - "Наклейки" - Полезный критицизм - Полнота - Четкость изложения - Допустимая сложность - Избыточность - Накопление - Классификация/определение приоритетов Рис. 8.3. Механизмы совершенной поддержки. В процессе выполнения этих действия стенка обычно приобретает цвет приколо тых примечаний, поэтому председатель приостанавливает выполнение всех дейст вий, дабы перейти к следующему этапу процесса совершенной поддержки. Первона чальный владелец плаката, на котором имеются наклейки, выполняет указанные ими обновления, периодически восклицая: "Чье это предложение по такому-то требова нию?" Часто автор наклейки и автор плаката обмениваются мнениями с целью выра ботки приемлемого решения. Этот процесс обеспечивает достижение двух важных целей: формулировки требований улучшаются в смысле четкости выражений и неза висимости от других требований, а вклад всех членов комиссии и экспертов по ис ходным материалам реализуется совершенно естественным образом. Подобная со вместная работа благотворно сказывается на проекте, гарантируя соответствие про дукта реальным требованиям пользователей. Во время создания программного про дукта будет возникать множество ситуаций, когда команда разработки должна взаи- Глава 8. Совместная разработка требований к приложению (JAR) 179 модействовать с группой пользователей или с экспертами по исходным материалам. Такие ситуации отражаются в следующем списке: • Организация работы рабочей группы управления взаимодействием • Организация работы рабочей группы технического управления • Выполнение промежуточных пересмотров программы • Работа с опросными листами, интервью, эксплуатационными сценариями, по лученными от конечных пользователей (случаи использования на языке UML) • Создание прототипов и моделей • Наблюдение за существующей системой, средами и конфигурациями техноло гических процессов • Принятие или заимствование решений и осуществление последующего выбора • Альфа-тестирование • Бета-тестирование Это взаимодействие будет более плодотворным и качественным, если все члены этой сборной команды научатся работать вместе и будут знать основные требования. Результатом работы комиссии JAR должен быть набор плакатов, содержащих функ циональные и некоторые нефункциональные требования, предъявляемые к новому проекту. Напряженная работа участников JAR по уточнению формулировок, графи ческого материала, приоритетов и заголовка каждого требования позволяет опытно му техническому оформителю без особого труда заполнить шаблон для создания за вершенного документа с требованиями. ПРИМЕР: УСПЕШНАЯ РАЗРАБОТКА JAR (ГЭРИ КОББ (GARY COBB)) Несколько лет назад мне довелось столкнуться с разработкой очень важного проекта по электроиной торговле, календарный план которого был очень плотным. Этот проект был явным кандидатом на применение технологий быстрого тестирования. Основная задача формулировалась как быстрая разработка интерфейса программирования приложений (API) между системой заказов товаров по Internet и стандартной системой размещения заказов компании. Выделенные руководством денежные средства предполагали ведение разработки шестью разработчиками, включая руководителя/ведущего разработчика, в течение 3 месяцев. Руководитель проекта выделил б недель из 16-недельного календар ного плана на документирование требований и поручил эту работу двум разработчикам, в то время как остальные должны были приступить к созданию прототипа API. Тогда я выступил с заявлением, что если бы в проекте был использован процесс JAR, то я смог бы предоставить полностью протестированный документ описания требований за 2 неде ли — на целый месяц раньше планового срока. При этом в нем были бы полностью уч тены пожелания пользователей, и было бы меньше ошибок, чем при выполнении 6- недельной работы, за которую они были готовы взяться. В четверг руководитель проекта и его подчиненные согласились принять мое предложе ние по применению JAR, и пятницу я начал с проведения вводного собрания, во время которого группа составила список из 28 экспертов по исходным материалам. Во время вводного собрания было выбрано также рабочее помещение, а четыре наиболее знаю щих эксперта были рекомендованы как члены команды на следующую неделю (еже дневно с 8:00 до 17:00). Были расписаны также часы бесед с остальными 24-мя экспер тами (12 бесед с двумя экспертами ежедневно, с понедельника по среду следующей недели) 180 Часть II. Технологии быстрого тестирования и советы Легкий утренний завтрак и послеобеденные освежающие напитки должны были пода- ваться в общем помещении, однако промежуток с полудня до 13:00 оставался свобод- ным, чтобы члены группы могли пообедать и ответить на сообщения. Утром в понедельник члены комиссии мучались над созданием плакатов для ряда фун даментальных требований. Ряд споров велось по поводу элементов архитектуры систе мы, эксплуатационных характеристик и применимости, производительности и требований к внешним коммуникациям. Затем после полудня состоялись два первых интервью с экспертами по исходным материалам. По завершении интервью, во вторник состоялась первая половина заседания по совершенной поддержке. В результате вся стена окраси лась в розовый закатный цвет, поскольку председатель располагал только розовыми на клейками. До проведения первого интервью с экспертом по исходным материалам в среду авторы плакатов обработали поставленные вопросы и стена вновь стала белой. За вторую половину среды, в процессе подготовки к первому рабочему заседанию, кото рое должно было состояться в четверг, сеанс совершенной поддержки был завершен, и члены комиссии сложили часть плакатов под поручнями кресел, тем самым признав, что эти требования имеют более низкий приоритет и должны быть выполнены позже. Одно временно один из членов комиссии завершил уточнение глоссария. В полдень четверга двум менеджерам было предложено оставить свои замечания на стене с пустыми розо- ' выми наклейками. Члены комиссии были весьма горды похвальными отзывами, остав- ленными обоими менеджерами. К пятнице помещение JAR было проветрено, а комиссия, за исключением председателя и руководителя проекта, которые остались для беседы с техническим оформителем, была распущена. Руководитель проекта согласился к понедельнику пересмотреть кален- дарный план с учетом более раннего начала проектирования. Технический оформитель согласился ко вторнику подготовить черновик документа с требованиями и новый кален- дарный план разработки проекта. Во время этой разработки JAR были запланированы три последовательных поставки вер- сий программы, причем первая должна была быть создана по истечении первых трех месяцев. Эта версия должна была, как и планировалось ранее, передавать Internet- заказы в систему размещения заказов. Второй этап, разработка которого должна была выполняться параллельно первому, ориентировался на создание ASP-системы, запускае- мой во время формирования Internet-заказа, как средства предотвращения попадания неверно оформленных заказов в систему размещения заказов. На третьем этапе, раз рабатываемом параллельно с первым и вторым этапами, планировалась разработка. Web-системы отслеживания заказов, предназначенной для автоматизации получения ин- формации о состоянии заказов Internet-клиентов. Поставки версий программы на всех этих этапах выполнялись своевременно и были с радостью встречены перегруженным работой персоналом отдела обработки заказов, котором до этого приходилось вводить и обрабатывать заказы вручную. Наиболее примечательное замечание, впоследствии услышанное мною от одного из об работчиков заказов, звучало так: "После получения программы члены этой команды разработчиков учили нас выполнять работу с помощью данного программного обеспе- чения, но даже сами разработчики не смогли заставить программу работать во время обучения. Когда они поставили программу, мы и сами знали, как ее использовать, по- скольку она полностью соответствовала нашим потребностям. Удивляло лишь то, что в программе было очень мало ошибок, и что на всех этапах поставка выполнялась точно по графику." Отойдя в сторону, я сказал себе: "Да! Вот вам результат одновременного выполнения разработки и тестирования!" Иначе говоря, таков результат быстрого тести- рование в действии. Глава 8. Совместная разработка требований к приложению (JAR) 181 Роль специалистов по тестированию в процессе JAR В процессе JAR специалисты по тестированию играют три роли. О н и (1) участвуют в совершенной поддержке, (2) знакомятся с требованиями к тестированию, которые должны стать обоснованием требований по выделению ресурсов для персонала про ведения испытаний и (3) во время интервью с экспертами по исходным материалам задают вопросы относительно используемых в настоящее время процедур тестирова ния. Один из разделов документа с требованиями должен быть посвящен требовани ям к тестированию продукта, и именно специалист по тестированию должен первым ратовать за то, чтобы этот раздел был максимально полным и точно сформулирован ным. Вполне вероятно, что впоследствии он окажется тем тестировщиком, которому придется преобразовывать эти требования к тестированию в требования к ресурсам по обеспечению тестирования, общий план тестирования и множество тестовых слу чаев со сценариями и результатами тестирования. Во время интервью с экспертами по исходным материалам тестировщик должен прояснить каждый из перечисленных ниже вопросов: • Расскажите о режимах, приводящих к отказам используемых систем, наиболее часто отмечаемые пользователями. • Пожалуйста, опишите методику взаимодействия пользователей с группой раз работки во время документирования, исправления и тестирования ошибок в используемой системе. • Опишите, как пользователи осуществляют переход к новой версии, выпущен ной группой разработчиков. • Назовите некоторые из стандартов, которые пользователи желают выдвинуть разработчикам нового продукта. • Пожалуйста, помогите описать некоторые платформы и языки, в сочетании с которыми новый продукт должен функционировать, а также любые конкрет ные соображения по поводу окружающей среды компьютерных систем, вклю- 'чая доступность для обслуживания, ремонта и т.п. П р и рассмотрении тестирования на этапе выработки требований в рамках жиз ненного цикла разработки следует помнить, что во время JAR-сеанса выбираются и помещаются в итоговый документ как функциональные, так и нефункциональные требования, при этом они должны быть максимально полными и четко сформулиро ванными. Но они не являются единственными, которые должны быть удовлетворены во время разработки, равно как и единственными, которые должны тестироваться. Ниже приведен перечень ряда дополнительных требований, которые должны быть учтены персоналом разработки: • Стандарты разработки проекта. Это требования к процессам и процедурам, которым персонал разработки должен будет следовать на этапах разработки проекта. Весьма вероятно, что эти установки и процедуры будут стандартными для всех разрабатываемых проектов, поэтому персонал тестирования должен располагать инструментальными средствами и тестовыми случаями, которые позволят проверить каждый продукт на предмет соответствия этим требованиям. 182 Часть II. Технологии быстрого тестирования и советы • Производные требования. В течение JAR-сеанса эксперт по исходным мате риалам может заявить, что новый продукт должен быть выполняемой про граммой, запускаемой на одном из сетевых клиентских компьютеров, рабо тающих при нормальных рабочих условиях окружающей среды. Видя это тре бование, проектировщики программного обеспечения могут включить в код параметр для комнатной температуры и поискать значения верхней и нижней границ температуры в стандарте, который определяет нормальные рабочие ус ловия окружающей среды. При создании тестового случая для проверки соот ветствия исходному требованию, чтобы воспроизвести испытательные условия окружающей среды для тестируемого продукта, специалистам по тестированию придется обратиться к производному требованию, выдвинутому проектиров щиками программного обеспечения. • Требования к интерфейсу. Занимаясь реализацией нового продукта, проекти ровщики программного обеспечения могут принимать решения по созданию или приобретению тех или иных компонентов. Чтобы можно было взаимодей ствовать с приобретенными подсистемами, конструкция должна удовлетворять дополнительным нефункциональным требованиям. При создании тестовых случаев для тестирования интерфейсов на предмет их соответствия специфи кациям тестировщики будут применять тесты к интерфейсу этой подсистемы так, как это определено в документации, поставляемой вместе с подсистемой. Резюме Подводя итоги сказанному в этом разделе, который был посвящен объединению тес тирования с выработкой требований, следует отметить, что в действительности JAR — всего лишь один из множества методов выработки требований. Основная идея состоит в том, что вся команда разработки оценит роль тестирования только тогда, когда с самого начала оно будет интегрировано в процесс разработки. Разработчики смогут оценить преимущества того, что не придется проектировать и реализовать сложный программный продукт лишь для того, чтобы выяснить, что основные поль зователи не в состоянии понять принципы его применения, а покупатели не желают расставаться со своими деньгами. Тестировщики системы также оценят избавление от необходимости разрабаты вать и реализовывать сложные тестовые случаи для этой сложной конструкции. Пер сонал отдела маркетинга оценит отсутствие необходимости конкурировать с более дешевым продуктом, появившимся на рынке раньше, поскольку он не содержит сложных компонентов. И, наконец, поэтапная поставка версий продуктов является общепринятой нормой в промышленности программного обеспечения, а сложные компоненты, исключенные из первоначальных требований, могут послужить реаль ным усовершенствованием, которое привлечет симпатии клиентов, если они будут добавлены и реализованы в форме существенной модернизации. Технологии статического тестирования и советы Темы, рассматриваемые в главе: Цикломатическая сложность и ее взаимосвязь с выполнением тестирования Пример представления проекта модуля в виде графа Формальная оценка Применение контрольных перечней Аудит Инспекции/критический анализ/экспертные оценки Распределение ролей и обязанностей в группе выполнения инспекций Отчетность о процессе выполнения инспекций Показатели процесса инспекции Использование электронной почты или другого электронного приложения для ускорения процесса инспекции Формальная верификация Языки на основе спецификаций Автоматизированное доказательство теорем Средства автоматизации тестирования Прослеживаемость требований Программа контроля единиц измерения физических величин Символьное выполнение Листинги перекрестных ссылок Программы улучшенной печати Средства сравнения версий Тестирование алгоритмов Диспетчер тестирования Базы данных материалов совместного использования Резюме 184 Часть II. Технологии быстрого тестирования и советы Существует множество технологий, в которых используется анализ архитектуры и структуры программных разработок. В этой главе описан ряд таких технологий. В соответствии с концепцией быстрого тестирования эти технологии должны приме няться на максимально ранних этапах жизненного цикла разработки, и большинство из них может использоваться еще до начала создания каких-либо кодов. Известно, что высокая сложность неизбежно приводит к большому количеству ошибок, поэтому в этой главе внимание уделяется, прежде всего, вопросам уменьшения сложности. Основной побочный э ф ф е к т измерения цикломатической сложности состоит в том, что оно позволяет группе тестирования оценить количество прогонов программного объекта, которое потребуется для хотя бы однократного тестирования каждой ветви программы. Это может служить ориентиром как для планирования трудозатрат на тестирование, так и для создания упорядоченных наборов случаев использования. Формальные оценки, инспекции и аудиты позволяют убедиться в том, что каждый из разработчиков придерживается наборов установок, процедур, руководств по сти лю и других стандартов, используемых в организации. Кроме того, они являются эф фективным средством обнаружения ошибок. В главе также рассматриваются техно логии, которые должны применяться для организации и проведения оценок и ин спекций. Цикломатическая сложность и ее взаимосвязь с выполнением тестирования Наличие нескольких ветвей в программе существенно повышает вероятность оши бок, и поэтому тестировщики уделяют им особое внимание. Вполне естественно, что многие разработчики программного обеспечения считают операторы G O T O , т.е. безусловные переходы, конструкцией языка, которая затрудняет понимание кода. Оператор G O T O исключен из большинства структурированных языков программи рования. Тем не менее, точки принятия решений являются обязательными конст рукциями даже в таких языках. Например, и конструкция IF(...), и конструкция DO WHILE(...) содержит точку принятия решения. В процедурных языках ветвь определяется как переход в процессе вычислений, начинающийся от точки входа в модуль или точки принятия решения и заканчиваю щийся точкой выхода из модуля или точкой принятия решения. В некоторых рабо тах, посвященных этой теме, авторы называют ветвь DD-ветвью (от decision-to- decision path — ветвь "от-решения-до-решения"). Поэтому типичная конструкция IF- THEN-ELSE-ENDIF содержит две ветви, которые обычно называются ветвями THEN и ELSE, причем обе они завершаются ключевым словом ENDIF конструкции. В мате матике и в теории графов было показано, что граф структурированной программы является планарным (плоским). И наоборот, все неструктурированные программы имеют непланарные графы. Уже на заре программирования стало привычным для упрощения понимания логики вычислений вычерчивать линии, соединяющие точки принятия решений. Тогда же стал привычным отказ от попыток разобраться в про граммах, содержащих слишком много ветвей, и разбиение их на доступные для пони мания фрагменты. Вполне естественно, что проблема сложности программного обеспечения уже давно привлекает внимание испытателей. Руководители различных рангов весьма |