- Серьезность
- Приоритет
- Глобальный приоритет
- Высокий приоритет и низкая серьезность
- Высокая серьезность и низкий приоритет
Для отслеживания багов в программах используются различные инструменты. В крупных компаниях эти инструменты объединяются в общую систему, которой пользуется много сотрудников. И все эти люди должны как-то ориентироваться в срочности работы над багами.
Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.
Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.
Серьезность (Severity) бага
Severity — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.
Степень серьезности бага больше касается функциональности, поэтому она присваивается тестировщиком. Именно он чаще всего оценивает, насколько конкретная функция может влиять на общую работу тестируемого продукта.
Пример классификации серьезности багов:
- Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
- Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
- Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
- Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование дополнительных функций. Для обхода этого бага могут быть очевидные пути.
- Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.
Приоритет (Priority) бага
Приоритет — атрибут, определяющий скорость устранения бага.
Приоритет бага сперва определяет инициатор, но в дальнейшем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.
Виды приоритетов:
- Top. Наивысший приоритет. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
- High. Высокий приоритет. Назначается багам, которые должны быть устранены в первую очередь.
- Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
- Low. Низкий приоритет. Назначается багам, не влияющим на функционал. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.
Также нужно упомянуть о частоте проявления бага.
Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.
Частота бывает:
- High. Высокая: с багом сталкиваются больше 80% пользователей.
- Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
- Low. Низкая: баг проявляется у 10-30% пользователей.
- Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.
Глобальный приоритет бага (Global Severity)
Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.
Таким образом, для определения глобального приоритета бага нужно:
- Определить серьезность бага.
- Отдельно от серьезности определить приоритет.
- Определить частоту (независимо от серьезности и приоритета).
- Рассчитать влияние частоты на изначально определенный приоритет.
Если частота у бага высокая, приоритет возрастает на одну позицию. Скажем, если изначально приоритет был Normal, но частота высокая, приоритет определяется как High.
Средняя частота бага меняет приоритет только с низкого на обычный.
Низкая или незначительная частота вообще не меняет приоритет бага.
Для определения глобального приоритета можно пользоваться следующей таблицей:
| Приоритет/Серьезность | Blocker | Critical | Minor | Trivial |
|---|---|---|---|---|
| High | Critical | Critical | Minor | Trivial |
| Medium | Critical | Critical | Minor | Trivial |
| Low | — | — | Trivial | Trivial |
Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.
Высокий приоритет и низкая серьезность
Такое сочетание бывает, когда баг на функционал влияет незначительно, но зато на пользовательский опыт влияет очень сильно. Также в эту категорию попадают баги, не влияющие на программу, но требующие исправления.
Вот пара примеров:
- Кнопки перекрывают друг друга. Они кликабельны, но визуальное впечатление портится.
- Логотип компании на главной странице содержит орфографическую ошибку. На функционал это вообще не влияет, но портит пользовательский опыт. Этот баг нужно исправить с высоким приоритетом, несмотря не то, что на продукт он влияет минимально.
Высокая серьезность и низкий приоритет
Такое сочетание бывает у багов, которые возникают в отдельных функциях программы. Эти баги не позволяют пользоваться системой, при этом обойти их невозможно. Но сами функции, содержащие эти дефекты, конечным потребителем используются редко.
Примеры:
- Домашняя страница сайта ужасно выглядит в старых браузерах. Перекрывается текст, не загружается логотип. Это мешает пользоваться продуктом, поэтому серьезность бага высокая. Но так как очень мало пользователей открывают сайт при помощи устаревшего браузера, такой баг получает низкий приоритет.
- Допустим, у нас есть приложение для банкинга. Оно правильно рассчитывает ежедневный, ежемесячный и ежеквартальный отчет, но при расчете годового возникают проблемы. Этот баг имеет высокую степень серьезности. Но если сейчас формирование годовой отчетности не актуально, такой дефект имеет низкий приоритет: его можно исправить в следующем релизе.
Итоги
Приоритет и серьезность багов — ключевые атрибуты, в соответствии с которыми определяется очередность исправления. Если неверно присвоить багу приоритет и серьезность, эффективность исправления ошибки сильно снизится. Это может нанести вред бизнесу и привести к финансовым потерям. Поэтому очень важно, чтобы и тестировщики, и разработчики понимали суть этих терминов и пользовались ими правильно.
