Начните со сбора данных в Протоколах тестирования, внесенных в них в процессе реализации и выполнения тестов. Источники подходящих протоколов могут быть разными: они могут быть собраны используемыми вами средствами (как выполнения тестов, так и диагностических средств), собраны пользовательскими процедурами, разработанными в вашем коллективе, получены из самих Целевых элементов теста, или записаны вручную тестировщиком. Соберите все доступные источники Тестовых протоколов и проверьте их содержимое. Проверьте, все ли запланированные тесты полностью выполнены, и все ли необходимые тесты запланированы.

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

Внесите в протокол как можно больше подробностей, но укажите, что инцидент пока еще не решен.

Довольно часто количество неполадок зависит от ошибок, внесенных в процессе реализации теста или при управлении тестовой средой. Определите и исправьте эти ошибки.

При неправильном завершении теста, до выполнения других тестов необходимо исправить ошибку, а затем продолжить выполнение тестов.

Чем больше признаков неполадки вы найдете, тем вероятнее ее определить и понять.

Попытайтесь выделить неполадку, устранив Целевые элементы теста, которые скорей всего не связаны с ней, а затем найти тенденции и характеристики в оставшихся элементах, состояние системы и т.д.

Произведите анализ неполадки, воспроизведя ее в управляемых условиях, если ее нельзя достаточно исследовать без воспроизведения. Там, где это полезно, примените средства диагностики и отладки.

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

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

Более подробная информация о составлении эффективных отчетов об инцидентах и Запросов на изменение находится в разделе Задача: Определение результатов тестирования - Создание и поддержка Запросов на изменение.

Более подробная информация о составлении эффективных отчетов об инцидентах и Запросов на изменение находится в разделе Задача: Определение результатов тестирования - Создание и поддержка Запросов на изменение.

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

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

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