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

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

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

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

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

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

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

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

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

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

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

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