Краткие теоретические сведенья

Лабораторная работа 2

Составление отчетов об ошибках

Баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

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

Тип ошибки (Type)

Functional – ошибка, затрагивающая функциональность, то есть, нарушение работы той или иной функции.

GUI – ошибка, затрагивающая графический интерфейс пользователя, его дизайн.

Error Handling – ошибка в обработке некорректных действий пользователя или коллизий в процессе выполнения программы.

Setup – баги при инсталляции и настройке программы.

Documentation – ошибки в документации.

Серьезность ошибки (Severity)

Cosmetic – ошибка дизайна графического интерфейса (например, не тот цвет линии или шрифт), такая ошибка не мешает программе работать, но портит ее «товарный вид».

Minor – теоретически малозначимая ошибка, почти не влияющая на работу программы.

Major – ошибка, которую не стоит игнорировать, так как она заметно влияет на работу программы.

Critical – серьезная ошибка, способная «повесить» программу или лишить ее важной функциональности.

Causes crash – очень серьезная ошибка, которая может привести к краху системы.

Приоритет ошибки (Priority)

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

Low – приоритет низкий, не требует срочного исправления, возможно «откладывание» исправления на определенный срок.

Medium / Normal – приоритет данной ошибки является нормальным (срочность исправления оценивается самим разработчиком). Исправляется в порядке основной очереди.

High – требует срочного, иногда немедленного исправления.

Стиль названий приоритетов может быть и таким:

ASAP (as soon as possible) – исправление требуется так скоро, как это возможно. Обычно это равнозначно Medium или Normal.

Before next build – ошибку нужно исправить до следующей сборки программы.

Before release 2 – ошибку нужно исправить до выпуска версии 2.

Статус ошибки (Status)

В практике чаще всего используются следующие статусы ошибки:

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

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

Когда разработчик ошибку исправляет, ее статус превращается разработчиком в Resolved / Fixed (исправлена). В этом случае тестировщик обязан перепроверить факт исправления.

В случае, если ошибка изначально не повторяется на стороне разработчика (по его мнению, ошибки нет), он превращает ее статус в Rejected (отклонена)и «переправляет» тестировщику обратно (с комментариями своего решения).

Если тестировщик получает «свою» ошибку со статусом rejected, он обязан перепроверить ее, после чего или закрывает ошибку, или присваивает ей статус Re-Open (открыта заново), когда ошибка все же существует (но ему следует улучшить описание ошибки, чтобы разработчик ее, наконец, обнаружил). Также этот статус получает ошибка, которая была объявлена как fixed, но при перепроверке оказалась не исправленной вследствие тех или иных причин.

Если ошибка о той же проблеме уже есть (внесена другим тестировщиком или разработчиком), то ее статус помечается как Duplicated (аналогичная уже имеющейся).

In Process / Open (в процессе) – ошибка зарегистрирована и принята, сообщение разработчиком прочитано, понято (или обсуждено), работа над ошибкой ведется.

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

Cannot Reproduce (невозможно воспроизвести) – часто аналогично rejected, статус ошибки, которая воспроизводится у тестировщика, но не воспроизводится у разработчика (или наоборот) по ряду причин.

Deferred / Postponed (отложена) – исправление ошибки отложено до выхода новой версии, обновления версии или на определенный/неопределенный срок.

Verified, Closed (проверена и закрыта) – статус тех ошибок, которые были исправлены разработчиком, и этот факт подтвержден тестировщиком.

Searching Conditions (поиск условий) – статус ошибки, появление которой было зафиксировано тестировщиком, но условия ее воспроизведения не ясны. Требуется дальнейшая работа по локализации условий воспроизведения ошибки. Может быть «понята» разработчиком при наличии дополнительных инструментов тестирования (дополнительных логов, специальных утилит) или фрагментов кода программы, написанного другим разработчиком.

Will not be fixed (не будет исправлена) – ошибка, которая по различным причинам не может быть исправлена ответственным за нее разработчиком. Такой статус требует аргументированного комментария разработчика.

Not a bug (не баг) – ошибка на самом деле ею не является. Как правило, это касается тех особенностей программы, которые не были описаны в документации и были восприняты тестировщиком как ошибки.

Verified (исправление подтверждено) – ошибка исправлена и перепроверена тестировщиком, однако пока не закрыта (например, историю ошибки должен изучить еще кто-то перед тем, как она будет закрыта).

Closed (закрыта) – ошибка исправлена, перепроверена, исправленный код помещен на живую систему, или выпущен новый билд (сборка). Запись об ошибке отправляется в архив.

Пример формы для оформления бага системы Trac.

Краткие теоретические сведенья - student2.ru