Исследуйте план итерации и определите намеченные цели и область действия.

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

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

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

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

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

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

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

Ниже приведено несколько идей для описаний целевых задач, которые вы можете применить, адаптируя их для данной итерации:

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

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

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

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

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

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

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

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

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