Ответственный за исправление дефекта

Ответственный за проверку дефекта

} Ответственный за проверку дефекта –лицо, в задачу которого входит проверка успешности устранения дефекта} Ответственный за проверку не обязательно автор дефекта!

} В зависимости от политики управленияответственный за проверку дефекта◦ Может назначаться автоматически (например,тестер проекта)◦ Может назначаться вручную

 

Состояние дефекта

Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.

При регистрации дефекта он приобретает статус Open, резолюция Unresolved. Лидер команды разработки или менеджер проекта (в некоторых случаях и лидер команды тестирования) выставляет приоритет дефекта и назначает разработчика ответственного за выполнение задачи.

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

Менеджер проекта, руководители подразделений до назначения разработчика на исправление или ответственный разработчик после детального изучения проблемы могут поменять статус дефекта с Open или In Progress на Resolved в случаях:

· Описанный дефект не может быть устранен, описанный случай не является дефектом, данную проблему не нужно устранять. В данном случае выставляется резолюция Won‘t Fix и адресуется создателю отчета. Отчет должен сопровождаться комментарием с информацией о причинах закрытия дефекта. Создатель отчета или любой другой представитель команды тестирования переводит статус дефекта с Resolved на Testing. Резолюция остается прежней. После исследования специалист по тестированию закрывает дефект, статус меняется с Testing на Closed. Резолюция остается прежней. Никто кроме представителей отдела тестирования не может самостоятельно закрыть дефект. Специалист по тестированию может повторно открыть дефект, предоставив аргументацию с причинами необходимости исправления. Статус меняется с Testing на Reopened, резолюция меняется с Won‘t Fix на Unresolved.

· Данный дефект дублирует уже существующий. В данном случае выставляется резолюция Duplicate и адресуется создателю отчета. Автор отчета или любой другой представитель команды тестирования переводит статус дефекта с Resolved на Testing. Резолюция остается прежней. Должна быть установлена связь между дефектами. После того, как создатель отчета или руководитель команды тестирования убедился, что данные отчеты действительно являются дублирующими, дефект должен быть закрыт, статус меняется с Testing на Closed. Резолюция остается прежней. В случае если дефект не является дублирующим, то он должен быть возвращен команде разработки. Статус меняется с Testing на Reopened, резолюция меняется с Duplicate на Unresolved. Никто кроме представителей команды тестирования не может самостоятельно закрыть дефект.

· Описанная ситуация не воспроизводится. В данном случае выставляется резолюция CannotReproduce и адресуется создателю отчета. Автор отчета пытается воспроизвести ошибку. Статус дефекта меняется с Resolved на Testing. Резолюция остается прежней. Если дефект воспроизводится, специалист по тестированию детализирует описание проблемы, указывает дополнительную информацию. Статус меняется с Testing на Reopened, резолюция меняется с Cannot Reproduce на Unresolved. Дефект должен быть возвращен разработчику. В случае, если описанная ситуация не воспроизводится и у специалиста по тестированию, то создатель отчета или руководитель команды тестирования закрывает дефект, статус меняется с Testing на Closed. Резолюция остается прежней. Никто кроме представителей команды тестирования не может самостоятельно закрыть дефект.

Примечание: в некоторых процессах разработки изначальный статус созданного дефекта является New. После одобрения менеджера или руководителя комнады тестирования статус дефекта меняется на Open. После назначения разработчика на исправление статус меняется с Open на Assigned.

После устранения дефекта разработчик выставляет версию приложения, для которой будет доступно исправление. Статус дефекта должен быть изменен с In Progress на Resolved. Резолюция меняется с Unresolved на Fixed. Разработчик снимает назначение с себя на создателя отчета. В комментарии разработчик должен указать всю важную информацию по исправлению. Если создатель отчета не является участником проекта тестирования, то назначение адресуется лидеру команды тестирования, который, назначает ответственного специалиста по тестированию за верификацию дефекта.

Желательно, чтобы проверку исправления выполнял создатель отчета о дефекте (если автор является участником команды тестирования).

Специалист по тестированию, назначенный на проверку исправления переводит статус дефекта в Testing, резолюция остается прежней.

После окончания проверки исправления, в случае если дефект исправлен корректно, то статус дефекта меняется с Testing на Closed. Резолюция меняется с Fixed на Verified.

В случае если дефект не исправлен или исправлен в не полном объеме, то статус дефекта меняется с Testing на Reopened, резолюция меняется с Fixed на Unresolved. Назначение адресуется разработчику, работавшему над исправлением проблемы. В случае возврата ошибки специалист по тестированию должен указать комментарием причину ошибку и версию приложения, для которого производилась проверка исправления. Жизненный цикл дефекта повторяется.

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

 

Зависимости дефекта

Дефект – обнаруженная в процессе разработки, тестирования или эксплуатации ошибка в разрабатываемом приложении.

 

 

Можно разделить ошибки на три уровня:

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

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

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

К группе факторов, влияющих на сложность ошибок комплексов программ, относятся:

- величина – размер модифицируемой программы, выраженная числом строк текста, функциональных точек или коли­чеством программных модулей в комплексе;

- количество обрабатываемых переменных или размер и структура памяти, используемой для размещения базы данных корректировок;

- трудоемкость разработки изменений комплекса программ;

- длительность разработки и реализации корректировок;

- число специалистов, участвующих в ЖЦ комплекса программ.

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

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

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

Технологические ошибки документации и фиксирования программ в памяти ЭВМ составляют иногда до 10% от общего числа ошибок обнаруживаемых при тестировании. Большинство технологических ошибок выявляется автоматически статическими методами. При ручной подготовке текстов машинных носителей при однократном фиксировании исходные данные имеют вероятность искажения около–на символ.