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

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

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

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

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

Составьте список потенциальных идей тестирования для каждой пары "мотивационный фактор тестирования" - "тестируемый объект".

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

На этом этапе большой список лучше, чем маленький. Улучшайте его, добавляя требуемые элементы и удаляя повторяющиеся.

Обновите параметры отслеживания в соответствии с требованиями возможности отслеживания, которые содержатся в плане тестирования.

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

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

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