![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть 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-сеанс с генеральным разработчиком и, желательно, с представителями группы маркетинга и заказчиком. По меньшей мере, можно будет взять интервью у предста вителей разработчика и группы маркетинга и сформулировать по возможности пол ные определения требований, насколько это позволяет отпущенное вам время.
|