Системные требования или сценарии использования системы обычно сопровождаются с помощью инструмента управления требованиями. После определения тестовых процедур во время планирования тестирования или проектирования тестов они заносятся в базу данных инструмента управления требованиями и привязываются к соответствующим системным требованиям или сценариям использования системы. Позднее, когда ведется отслеживание тестов, результаты их применения фиксируются и привязываются к соответствующим тестовым процедурам. (more…)

Группа тестирования должна расставить требования к тестам в порядке приоритетов. Также необходимо провести анализ функций системы, критичных для приложения, и функций повышенного риска, и использовать это в качестве входной информации для определения порядка, в котором будут выстроены группы требований. Лучший способ — сгруппировать требования по степени критичности функциональности, начиная с наиболее критичных и заканчивая наименее критичными. Когда будете определять, какая функция более критична, а какая — менее, не забудьте учесть информацию от конечных пользователей. Еще одно преимущество классификации требований таким образом состоит в том, что упрощается распределение задач между тестировщиками.
Ниже приводятся критерии, позволяющие определить порядок группировки требований к тестам. Это рекомендации Rational Corporation: (more…)

После определения требований к тестам группа тестирования должна измерить риски, присущие различным требованиям, оценив требования по следующим характеристикам:
? Степень влияния. Оценивается значение требования. Предположим, что определенное требование к тестам не вошло в рамки тестирования, в результате чего соответствующая этому требованию функциональность не работает после установки системы. Какое влияние может оказать эта проблема на функционирование системы и способность пользователя работать с системой? Является ли эта проблема потенциальной помехой в деятельности компании?
? Вероятность. Оценивается вероятность возникновения проблем в случае, если определенное требование к тестам не войдет в рамки тестирования. Анализируется частота, с которой конечный пользователь будет сталкиваться с соответствующей функциональностью системы. Оценивается опыт работы пользователя с данной функциональностью.
? Сложность. Определяются функции, являющиеся наиболее сложными. Ресурсы тестирования должны быть направлены на проверку этой функциональности.
? Источники проблем. Оценивается возможность возникновения проблем, и определяются требования к тестам, которые с наибольшей вероятностью могут породить эти проблемы.

Применение специальных автоматизированных инструментов, полезно, в частности, при решении утомительных и трудоемких задач. К таким задачам относится управление требованиями к тестам. Группа тестирования должна проверить, есть ли в компании стандартный инструмент для поддержки управления требованиями. Затем нужно выяснить, будет ли этот инструмент применяться в проекте и можно ли его установить в среде системной разработки исключительно для управления требованиями к тестам. Если в компании нет стандартного инструмента или его использование не запланировано в проекте, возможно, групйе тестирования придется показать, что его отсутствие порождает проблемы в управлении, или выступить с инициативой проведения оценки и подбора такого инструмента. Из представленных на рынке внимания заслуживают такие инструменты, как Requisite Pro от Rational, DOORS от QSS, и RTM от Integrated Chipware. (more…)

Планирование тестирования предполагает как определение требований к тестам, так и выработку подхода к управлению ими. Управление требованиями к тестам включает в себя хранение требований, отслеживание связей, оценку рисков требований к тестам, выстраивание последовательности требований к тестам и определение методов верификации тестов. Отслеживание связей предполагает отображение тестовых процедур на требования к тестам и дефектов на тестовые процедуры. (more…)

В предыдущих главах было показано, насколько важно иметь тестопри-годные системные требования или сценарии использования системы. Теперь системные требования необходимо проанализировать и определить в терминах требований к тестам. (Анализ требований к тестам и проектирование тестов подробно описываются в главе 7.) При анализе требований к тестам решаются следующие проблемы: что нужно искать при определении требований к тестам для целевого приложения, как преобразовать архитектуру приложения, системные требования или сценарии использования в требования к тестам, как провести анализ документации приложения для формулировки требований к тестам. Требования к тестам представляют собой подробный перечень того, что должно быть протестировано. (more…)

 Для выяснения того, насколько полным является покрытие системных требований или сценариев использования системы тестовыми процедурами, группа тестирования применяет матрицу отслеживания требований. Матрица показывает явным образом каждое требование, которое исследует группа тестирования, что в результате приводит к успешной реализации всех требований.
ермин «исследует» в этом контексте означает, что группа тестирования проводит проверку (или оценку) реализации системы. Способы проведения исследования обычно называют методами верификации. К ним относятся демонстрация, анализ, инспекция, тестирование (автоматизированное или ручное) и сертификация.Демонстрация, к примеру, может использоваться при тестировании следующего утверждения: «Разрешить запросы в режиме онлайн всех регистрирующих записей по номеру case.» (more…)

К определяемым параметрам тестирования относятся рамки, допущения, предварительные условия, критерии приемки системы и риски в зависимости от фазы тестирования. Рамки тестирования, обозначенные в плане тестирования, описывают ожидаемое покрытие тестами. В этом описании представлена система, предназначенная для тестирования, и содержатся указания, нужно ли помимо самого приложения включать в тестирование сеть, аппаратное обеспечение и базы данных.
Рамки должны определять, нужны ли тесты, нацеленные на проверку объектов, не являющихся результатами текущей разработки, таких как интегрированные COTS-приложения. (more…)

Группа тестирования должна выяснить, какие инструменты тестирования будут применяться в проекте. Обдумывая вопрос об использовании инструмента автоматизированного тестирования, группа должна прежде всего определить, нужно ли автоматизировать процесс. В результате этой работы по планированию появляется документ, объясняющий причины того или иного решения. Оценка и выбор инструментов автоматизированного тестирования для проекта описаны. Раздел «Инструменты» всегда присутствует в плане тестирования. В нем перечисляются применяемые инструменты, их функциональность, цель использования в проекте и причины выбора. Группа тестирования должна провести исследование инструмента тестирования, чтобы выяснить, работает ли данный инструмент в проектной среде. Результаты проверки совместимости инструмента фиксируются в плане тестирования.

Следующим шагом является определение рамок тестирования системы. Нужно провести анализ процесса тестирования, а также целей и задач тестирования. Затем готовится отчет о результатах проведенного анализа, в котором отражается работа по уточнению целей, задач и стратегий тестирования. (more…)