Серьезность и приоритет Дефекта (Severity & Priority)
Bug management включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении - баги, запросы на улучшения и даже целые релизы - обычно отслеживаются и управляются с помощью баг-трекинговых систем. Добавленные элементы могут называться дефектами, заявками, проблемами или, в соответствии с парадигмой гибкой разработки, эпиками и сторями (stories and epics). Категории могут быть объективными, субъективными или комбинированными, такими как номер версии, область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как фича-реквест или баг.
Критичность (severity): Важность воздействия конкретного дефекта на разработку или функционирование компонента или системы. (IEEE 610)
Приоритет (priority): Степень важности, присваиваемая объекту. Например, дефекту. (ISTQB)
Иными словами, серьезность представляет техническое влияние ошибки в контексте работоспособности самого ПО, а приоритет указывает на очередность выполнения задачи или устранения дефекта, т.е. точку зрения бизнеса. Приоритет выставляется любыми business stakeholders, включая project managers, business analysts, product owner, а серьезность сам тестировщик (или в сложных случаях тот, кто лучше разбирается). Разработчик берет таски исходя из приоритета.
Градация Серьезности (Severity):
Критическая (critical) - существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.;
Высокая (major) - существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы;
Средняя (medium) - существование дефекта слабо влияет на типичные сценарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы;
Низкая (minor) - существование дефекта редко обнаруживается незначительным процентом пользователей и (почти) не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов.
Градация Срочности/приоритета (Priority):
Наивысшая (ASAP, as soon as possible) срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут;
Высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем;
Обычная (normal) срочность означает, что дефект следует исправить в порядке общей очередности. Такое значение срочности получает большинство дефектов;
Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
Сочетания Severity и Priority
High Priority and High Severity: Любой Critical/major сбой бизнес-модели, критическая проблема, при которой полностью не работает большая часть функциональности или основной компонент системы:
нажатие на определенную кнопку не запускает саму функцию, например, не работает кнопка отправки на странице входа, и клиенты не могут войти в приложение;
выполнение определенной функции постоянно приводит к 500 ошибке сервера и потере данных;
система дает сбой после того, как вы совершили платеж или когда вы не можете добавить товары в корзину;
функция банкомата, при которой после ввода правильного имени пользователя и пароля автомат не выдает деньги, но списывает их с вашего счета;
на веб-сайте банка появляется сообщение об ошибке, когда клиент нажимает кнопку перевода денег.
High Priority and Low Severity: Любые minor severity дефекты, которые влияют на взаимодействие с пользователями / репутацию:
ожидается, что функция покажет пользователю конкретную ошибку по коду ответа. В этом случае функционально код выдает ошибку, но сообщение должно быть более релевантным коду;
ошибка в логотипе или названии компании на главной странице, или опечатки, бросающиеся в глаза и способные повлиять на репутацию компании;
опечатки в контактных данных;
важные ошибки в соглашениях и юридических документах.
Low Priority and High Severity: Проблема, которая пока не повлияет на бизнес, но имеет большое влияние с точки зрения функциональности:
присутствует серьезный баг, но есть workaround и исправление уже может быть запланировано в следующем релизе или функция будет удалена;
функция генерации годового отчета, которая будет использована только через полгода;
редкость проявления дефекта/сложность воспроизведения для юзеров.
Low Priority and Low Severity: Любые орфографические ошибки / начертание / несовпадение шрифта в абзаце 3-й или 4-й страницы заявки, а не на главной или титульной странице / заголовке. Эти дефекты возникают, когда это не влияет на функциональность, но все же в небольшой степени не соответствует стандартам. Обычно сюда классифицируются косметические ошибки или, скажем, размеры ячейки в таблице пользовательского интерфейса:
в политике конфиденциальности веб-сайта есть орфографическая ошибка;
страница часто задаваемых вопросов загружается очень долго;
семейство шрифтов, размер шрифта, цвет или орфографическая ошибка в приложении или отчетах.
Источники:
Доп. материал:
Last updated
Was this helpful?