Работа с ошибками

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

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

В этом разделе

• Рассмотрение ошибок

• Исправление ошибок

• Закрытие ошибки

Рассмотрение ошибок

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

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

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

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

На ранних этапах проекта обычно принимается решение об исправлении всех рассмотренных ошибок. Однако на последующих этапах проекта критерии рассмотрения (требования) можно ужесточить для уменьшения числа исправляемых ошибок.

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

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

Дополнительные сведения о заполнении рабочего элемента ошибки см. в разделе Ошибка (CMMI).

Исправление ошибок

После рассмотрения и определения приоритетности ошибки необходимо назначить разработчика для проведения дополнительного исследования.

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

После создания плана действий разработчик обязан зафиксировать принятые решения в рабочем элементе ошибки.

Принятие решения об исправлении

В ходе работы с другими участниками команды разработчик может порекомендовать способ исправления ошибки, который может повлиять на другие разделы кода и потребовать проведения многочисленных тестов регрессии. Любые обсуждения, связанные с оценкой рисков таких исправлений, должны фиксироваться в журнале рабочего элемента ошибки, так как это позволяет задокументировать важные аспекты анализа принятых решений и правления рисками для аудита и сертификации Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Дополнительные сведения о CMMI см. в разделе Сведения о CMMI.

Обновление и выполнение модульных тестов для исправлений ошибок

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

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

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

Выполните анализ и оптимизацию кода для исправления ошибки.

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

Закрытие ошибок

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

Проверка исправления

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

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

Закрытие рабочего элемента ошибки

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

См. также

Основные понятия

Отправка ошибок

Отладка с помощью IntelliTrace

Другие ресурсы

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