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

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

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

Подразделы:

• Проверить факты инцидентов
• Прояснить подробности Запроса на изменение
• Указать относительную серьезность влияния и приоритет разрешения
• Внести отдельно дополнительные Запросы на изменение

Проверить факты инцидентов

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

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

Прояснить подробности Запроса на изменение

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

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

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

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

Указать относительную серьезность влияния и приоритет разрешения

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

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

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

Внести отдельно дополнительные Запросы на изменение

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

Подразделы:

• Распределение инцидента
• Охват выполнения теста
• Статистические данные Запроса на изменение

Распределение инцидента

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

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

Охват выполнения теста

Для оценки охвата выполнения теста необходимо просмотреть протоколы тестирования и определить:

• Отношение между количеством тестов (Сценариев тестирования и Вариантов использования), выполненных в этом цикле тестирования, и общим количеством тестов для всех Целевых элементов теста.
• Коэффициент успешно выполненных тестовых сценариев.

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

• Риска качества или приоритета
• Охвата, основанного на спецификации (требования и т.д.)
• Потребностей бизнеса или приоритета
• Охвата, основанного на коде

Более подробная информация находится в разделе Концепция: Ключевые измерения теста, охват теста, основанные на требованиях.

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

Статистические данные Запроса на изменение

В ходе анализа дефектов необходимо просмотреть и проанализировать выбранные измерения. Наиболее часто используются следующие измерения (иногда показываемые в форме графика):

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

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

Рекомендуется придать результатам форму диаграммы с поддержкой поиска по запросу.

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

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

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

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

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

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

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

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

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

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