Часть I. Процесс быстрого тестирования. ным подходом в рамках реализации технологии FAST является разработанный ком­ панией IBM метод JAD (Joint Application Development — совместная разработка при­

ным подходом в рамках реализации технологии FAST является разработанный ком­ панией IBM метод JAD (Joint Application Development — совместная разработка при­ ложения) [43]. Другой метод, JAR (Joint Application Requirement — совместная разра­ ботка требований к приложению), был предложен Гэри Коббом (Gary Cobb) и описан в главе 8.

Обычно во время сеанса технологии FAST рекомендуется следовать тому или иному набору условий из числа приведенных ниже [43]:

• И заказчики, и разработчики принимают участие в совещании, посвященном вопросам определения требований.

• Установлены правила подготовки и участия в совещании, которым следуют обе стороны. Должна быть установлена атмосфера, содействующая успеху совеща­ ния.

• Совещание проводится под управлением посредника. Таким посредником мо­ жет быть заказчик, разработчик или кто-то посторонний, приемлемый для обеих сторон.

• Для фиксации требований используются такие средства, как лекционные пла­ каты с рейкой, настенные индикаторные панели или простая ленточная бумага.

• Цель совещания — определить задачи или потребности заказчика, предложить решение, обсудить различные подходы и определить набор требований.

Настоятельно рекомендуется участие в этом совещании специалиста по отладке или даже несколько упростить регламент совещания по технологии FAST с таким расчетом, чтобы в этом совещании могли использоваться элементы статического тестирования. Технология JAR, описанная в главе 8, особо благоприятствует встро­ енному статическому тестированию, которое в терминологии JAR называется " вспо­ могательная поддержка".

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

• Наиболее важные требования.

• Требования, выполнение которых крайне желательно.

• Требования, выполнение которых желательно, но не обязательно.

Благодаря такому распределению приоритетов упрощается выполнение плана разработок. Например, можно составить план, который ставит выполнение наиболее важных требований в рамках первой версии программного продукта, реализация же­ лательных требований во второй версии и всех остальных — в третьей версии. Ана­ логично, группа тестирования может начать разработку тестов для требований с наи­ большим приоритетом в первую очередь. Такой тип нарастающих поставок или по­ ставок версиями, часто используется в тех случаях, когда решающее значение имеет соблюдение временного графика работ.

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

упомянутые ситуации встречаются довольно часто; достаточно вспомнить данные группы Standish Group, приведенные в начале главы, в которых первой из причин неудачи проекта или нарушение сроков его разработки была названа неполнота тре­ бований. Один из авторов этой книги вспоминает исключительную ситуацию, когда специалисту по тестированию передали компакт-диск с программой и попросили вы­ полнить ее тестирование — но там не было никакой документации, не говоря уже об описании набора требований.

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