Часть I. Процесс быстрого тестирования. • Описание среды, используемой для распределения программного продукта (например, компакт-диски, Web- или ftp-сайты)

• Описание среды, используемой для распределения программного продукта (например, компакт-диски, Web- или ftp-сайты)

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

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

4. Характеристики и свойства, которые должны тестироваться. Стандарт IEEEStandard 829 предлагает следующее определение свойства программного обеспечения (software feature): это отличительная характеристика программного компонента, на­пример, производительность, переносимость или функциональные возможности.

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

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

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

5. Характеристики и свойства, которые не должны тестироваться. Этот разделпредназначен для того, чтобы заблаговременно и однозначно определить, какие объ­ екты не должны охватываться тестированием. В число объектов, объявляемых как " не подлежащие тестированию", могут входить следующие:

• Функции, реализация которых отложена до последующих инкрементальных версий продукта

• Конфигурации компьютерных средств, которые невозможно проверить по причине отсутствия необходимого оборудования. Иногда используются на­ столько дорогостоящие конфигурации компьютерного оборудования, что их невозможно продублировать в условиях испытательных лабораторий. Если вы не можете воспроизвести операционную среду, но в то же время можете ее смоделировать, об этом потребуется сообщить в разделе " Подход". Если вы во­ обще не можете проводить испытания в операционной среде, этот вопрос сле­ дует рассмотреть в разделе, в котором обсуждаются " риски".

• Комбинации настроек или конфигурации аппаратных средств, которые не мо­ гут быть испытаны за время, выделенное для выхода программного продукта на рынок. Если принято решение ограничить объем тестирования некоторого конкретного свойства, необходимо обсудить данные ограничения и обосновать их в этом разделе.

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

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

• Статическое тестирование требований и проектная документация

• Статическое и динамическое тестирование, которое должно проводиться на стадиях тестирования программных кодов, модулей и проверки взаимодейст­ вия и функционирования компонентов системы

• Тестирование свойств

• Испытания при перегрузках/испытания под нагрузкой/тестирование произ­ водительности

• Проверка средств защиты

• Тестирование установки/обновления программного продукта

• Тестирование средств дублирования/восстановления

• Тестирование GUI-интерфейса