У любой ошибки (очевидное несоответствие между реальностью и ожидаемым результатом в поведении ПО) есть определенные атрибуты: «серьезность» и «приоритет» с цифровым или буквенным обозначением.
Но далеко не все могут с уверенностью сказать, в чем именно заключается разница между этими понятиями.
Так, серьезность это больше относится к технической интерпретации вопроса, а приоритетность – к управленческой (менеджерской).
Дабы внести ясность, далее в статье будет дан анализ формального определения, которое сейчас используется во многих стандартах тестирования.
Разделение приоритетов и серьезности по уровням
Сегодня приоритеты принято делить на три уровня, а серьезность – на пять.
Приоритет бага – это специальный атрибут, демонстрирующий очередность выполнения задачи или устранения ошибки. Приоритет проставляется исключительно менеджером проекта или руководителем компании.
Уровни приоритетности:
- Р1 – Высший (High) – дефект необходимо исправить в первую очередь;
- Р2 – Средний (Medium) – можно исправить во вторую очередь, когда в содержании отчета об ошибке не останется багов с высшим уровнем приоритетности;
- Р3 – Низкий (Low) – исправляется в самую последнюю очередь, когда все баги с более высоким уровнем приоритетности были устранены.
Серьезность (Severity) – специальный атрибут, который характеризирует влияние бага на общую функциональность разрабатываемого приложения. Проставляется QA специалистом или техническим сотрудником, который в состоянии оценить уровень влияния бага на общую работу тестируемого ПО.
- S1 – Блокирующий (Blocker) – баг полностью блокирует выполнение поставленного функционала, и нет никакой возможности его обойти. Если провести аналогию с комнатой с закрытой дверью – то если дверь закрыта, и у вас нет от нее ключа, вам никак ее не открыть и не покинуть помещение. Окна отстутствуют, а ключи потеряны;
- S2 – Критический (Critical) – ошибка блокирует некоторую часть функционала, но существует альтернативный способ для ее обхода. Также аналогия с помещением и дверью: вы можете выбраться из комнаты посредством окна, хотя дверь все еще закрыта, и ключ не найден;
- S3 – Значительный (Major) – баг, демонстрирующий некорректную работу определенной части созданного функционала. Обычно связан не с тем, что определенная функция не работает, а с тем, что она работает некорректно. Как бы то ни было, есть сразу несколько точек инициации необходимого функционала. Другими словами, вы можете покинуть помещение без использования ключа и замка (определенная дыра в безопасности), посредством вентиляционного канала (другая точка входа) либо же дверь открывается не в ту сторону (как итог, упирается в угол и может открыться только частично – яркий пример некорректной реализации задуманного функционала). Очень часто встречаются баги, которые можно сопоставить именно с этим уровнем критичности;
- S4 – Несущественный (Minor) – баг, который по факту не относится к внутреннему функционала продукта. Обычно серьезность Minor ставится для тех ошибок, которые в большей степени относятся к удобству использования разработанного ПО (графический интерфейс и логика взаимодействия с фронт-енд частью). Обычно это определенные грамматические дефекты в технической документации продукта. Порой может относиться к невидимым проблемам с точки зрения использования продукта клиентом. В аналогии с комнатой и дверью — ключ и засов от разных производителей, в помещении можно уловить незначительный шум (никоим образом не относится к строению этой комнаты).
Но почему нужно использовать подобное деление, почему не можно обойтись всего лишь одним базовым атрибутом, к примеру, понятием серьезности?
Допустим, в определенной системе перестал функционировать модуль отчетности. Это баг с номинальным уровнем серьезности – «Блокирующий».
Но, работать с этим модулем клиент начнет только в конце года. На дворе лето, а значит, данная функциональность не будет востребованной еще минимум полгода.
Как итог, менеджер проекта запросто устанавливает самый низкий приоритет исправления подобного функционала.
Иная ситуация: в графической составляющей веб-сайта некорректно отображается слоган компании. Данный баг может существенным образом ударить по будущему доверию со стороны клиентов к услугам фирмы, которые она предлагает: круг потенциальных клиентов запросто может заподозрить, что качество услуг фирмы низкой пробы, раз даже в названии их слогана допущена вопиющая грамматическая ошибка – и категорически отказаться от дальнейшего сотрудничества.
С точки зрения подхода к качеству ПО, даже нефункциональные баги с отметкой серьезности «Тривиальный» могут существенно повлияют на текущую репутацию фирмы. А значит, подобной ошибке будет проставлен самый высокий уровень приоритетности.
Резюмируя вся вышесказанное, необходимо понимать, что процесс проставления атрибутов приоритетности и важности бага является неотъемлемой частью процесса создания любого ПО, ведь атрибуты красноречиво классифицируют все баги по виду: степень негативного влияния на работу системы и последовательность их исправления.
Как итог, есть возможность быстро проводить поиск багов и совершать сортировку, формировать понятные отчеты об ошибках и не тратить драгоценное время на лишнюю коммуникацию.
Ставьте атрибуты серьезности и приоритетности верно и да пребудет ваше ПО в «добром здравии» и оптимальном функционировании!
Оставить комментарий