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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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