Продолжаем изучать теорию. Начало тут и тут.
Сегодня я хочу рассказать о дефектах или же, так называемых багах.
Почему дефекты и ошибки называются багами, уже рассказано бесконечное количество раз самыми разными источниками. В двух словах перескажу статью из Википедии. Для обозначения именно программной ошибки «баг» был впервые употреблён американской ученой Грейс Хоппер, обнаружившей сгоревшего мотылька между замкнувшими контактами реле вычислительной машины Mark II. Этот самый мотылёк был приклеен скотчем в технической журнал и сопровожден записью «First actual case of bug being found». На самом деле, Грейс Хоппер - удивительная женщина, знаменита она не только этим случаем, обязательно почитайте о ней поподробнее. В той же статье говорится о том, что багами называли проблемы с радарной электроникой во времена Второй мировой войны. А ещё раньше этот термин употреблял Томас Эдисон, когда сетовал на то, что надо исправить много «жучков» - мелких ошибок и трудностей, перед тем, как изобретение получит коммерческий успех или провал.
Итак, минутка истории позади, возвращаемся к теории.
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Напомним, что ожидаемый результат - то, что мы должны были получить согласно требованиям, спецификации, здравого смысла и т.д. Фактический результат - то, что мы получили в результате взаимодействия с системой.
Во избежание путаницы в различных терминах можно ориентироваться на следующие определения:
* Error (ошибка) — это действие (чаще всего пользователя), которое порождает неправильный результат.
* Bug (дефект) — недостаток компонента/системы, который может привести к отказу определенной функциональности.
* Failure (сбой) — это несоответствие фактического результата работы компонента/системы ожидаемому результату.
У дефектов есть несколько свойств и характеристик (привыкайте к слову «атрибут»). Итак, атрибуты дефектов:
I. Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Имеет следующую градацию:
* Блокирующий (S1 – Blocker) - простыми словами, это ошибка, приводящая ПО в нерабочее состояние.
* Критический (S2 – Critical) - критический дефект, приводящий некоторый ключевой функционал в нерабочее состояние. Также сюда можно отнести существенное нарушение бизнес-логики приложения, потеря пользовательских данных и тому подобные «неприятности».
* Значительный (S3 – Major) - серьезная ошибка, не имеющая критического воздействия на трестируемое ПО.
* Незначительный (S4 – Minor) - незначительный дефект, функционал приложения не нарушает, но и не соответствует ожидаемому поведению ПО.
* Тривиальный (S5 – Trivial) - дефект, не имеющий влияния на функционал, который может быть обнаружен визуально. Чаще всего сюда относятся дефекты GUI (графического пользовательского интерфейса) - опечатки, несоответствие шрифта, цветов и т.п.
II. Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
Имеет следующую градацию:
* Высокий (P1 - High) - баг должен быть исправлен в первую очередь и как можно быстрее, поскольку имеет критическое влияние на функционал ПО.
* Средний (P2 - Medium) - дефект необходимо обязательно исправить, но он не имеет критического влияния на функционал ПО.
* Низкий (P3 - Low) - ошибка должна быть исправлена, но ее исправление может быть отложено для устранения более приоритетных дефектов.
Чтобы лучше понимать разницу понятий «серьезность» и «приоритет», мне нравится следующий утрированный пример. На главной странице сайта крупного банка появилась небольшая опечатка. Серьезность этого дефекта - S5 trivial, самая низкая; но приоритет будет P1 high, самый высокий, потому что из-за досадной опечатки сильно пострадает репутация банка.
Отчёт о дефекте (bug report) — отчёт, подробно описывающий ситуацию, которая привела к появлению дефекта с описанием причин и ожидаемого результата.
Для управления и учета дефектов используются баг-трекинговые системы (Jira, Redmine, Bugzilla и др.)
Атрибуты отчета о дефекте:
1. ID (уникальный идентификатор) — присваивается автоматически системой при создании баг-репорта.
2. Summary (тема, краткое описание) — краткое и ёмкое описание дефекта, отвечающее на вопросы: Что? Где? Когда?
3. Description (подробное описание) — более развёрнутое описание дефекта.
4. Steps to reproduce (шаги для воспроизведения) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах для воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
5. Actual result (фактический результат) — описывается поведение системы на момент обнаружения в ней дефекта.
6. Expected result (ожидаемый результат) — описание того, как именно должна работать система в соответствии с документацией.
7. Attachments (вложения) — скриншоты, видео или лог-файлы.
8. Severity (серьёзность дефекта, важность) — характеризует влияние дефекта на работоспособность приложения (мы рассматривали это понятие выше).
9. Priority (приоритет дефекта, срочность) — указывает на очерёдность выполнения задачи или устранения дефекта (также рассматривали выше).
10. Status (статус) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
11. Environment (окружение) – окружение, на котором воспроизвелся баг.
Жизненный цикл дефекта - это путь дефекта от статуса к статусу. Статусы в разных баг-трекинговых системах могут отличаться. Но чаще всего встречаются следующие:
New (новый) - тестировщик обнаружил дефект, описал его и занёс в баг-трекинговую систему.
Opened (открыт) - автоматически или вручную назначен сотрудник, который должен проанализировать дефект.
Deferred (отложен) - исправление данного дефекта не несёт ценности на данном этапе, поэтому его рассмотрение отложено.
Rejected (отклонён) - по разным причинам то, что тестировщик посчитал дефектом, таковым не является. Либо дефект неактуален. В этих случаях его отклоняют.
Duplicate (дубликат) - если дефект уже был ранее обнаружен и занесён в баг-трекинговую систему.
Assigned (назначен) - если дефект актуален и требует исправления, на его устранение назначается ответственный разработчик.
Fixed (исправлен) - после исправления дефекта назначенным разработчиком.
Verified (проверен) - статус выставляется после того, как тестировщик убедился, что баг действительно исправлен.
Reopened (открыт повторно) - статус выставляется после того, как тестировщик убедился, что баг не был исправлен назначенным разработчиком.
Closed (закрыт) - дефект окончательно устранён.
