Просмотрите План итерации и определите специфические потребности оценки для предстоящей работы. Спросите у заинтересованных лиц, что они хотят получить от оценки и трассируемости.

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

Так как обычно существует бесконечный список "пожеланий", вы можете ошибочно принять их за требования для стратегий трассируемости и оценки. Важно сосредоточится на самых важных "потребностях", которые: а) Предоставляют существенную информацию для коллектива проекта; б) Действительно могут быть измерены и отслежены. Маловероятно, что у вас будет достаточно ресурсов для удовлетворения тех потребностей, которые не являются действительно необходимыми.

Подразделы:

• Приемлемый уровень качества
• Включение процесса и инструментария

Приемлемый уровень качества

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

Просмотрите План QA, План разработки программного обеспечения и пообщайтесь самостоятельно с заинтересованными лицами, чтобы определить, какой уровень качества они считают приемлемым.

Включение процесса и инструментария

Хотя вы можете представить себе, что трассируемость и оценку можно без усилий обеспечить на низком уровне дискретности, в реальности трудно и обычно невыгодно применять такой подход. Даже с помощью изощренных инструментальных средств трудно и затратно по времени управлять низкоуровневым подходом к трассируемости, а без поддерживающего инструментария это почти невозможно. Сам процесс проектирования программного обеспечения может наложить ограничения на трассируемость. Например, если желательно обеспечить трассируемость тестов для мотивации требований, но сами требования не управляются тщательно, то реализовать такую трассируемость может оказаться невозможным.

Рассмотрите ограничения как процесса проектирования программного обеспечения, так и инструментальных средств, а затем выберите подходящий работоспособный подход к оценке и трассируемости.

Теперь, когда вы лучше понимаете требования к оценке и трассируемости, а также ограничения, налагаемые на них желаемым уровнем качества и доступной инструментальной и технологической поддержкой, вам необходимо рассмотреть возможные стратегии оценки, которые вы могли бы применить. Мы рекомендуем вам получить более подробную информацию о возможных стратегиях в статье Сэма Канера (Cem Kaner) "Measurement of the Extent of Testing," Октябрь 2000. (Получить Adobe Reader)

Подразделы:

• Анализ охвата теста
• Анализ результатов теста
• Анализ дефекта

Анализ охвата теста

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

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

Анализ результатов теста

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

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

Анализ дефекта

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

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

С помощью применения изощренных инструментальных средств вы сможете выполнить сложный анализ данных дефектов относительно легко, но без соответствующей инструментальной поддержки это будет сделать гораздо сложнее.

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

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

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

Представьте стратегию оценки для окончательного согласия и утверждения.

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

Решите, какие инструменты вам будут необходимы для следующих категорий: Охват и Трассируемость, Анализ дефектов.

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

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

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