Home

Автор: Андрей Петров

Оригинальная публикация

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.

• P1 – Высокий (High) – требуется исправить в первую очередь;
• P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом;
• P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется тестировщиком или техническим специалистом, который может оценить степень влияния дефекта на работу системы.

• S1 – Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти. Если провести аналогию с закрытым помещением и дверью – то дверь закрыта, у вас нет никакой возможности её открыть и покинуть помещение. Окон нет, ключ к двери не подходит.
• S2 – Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода. По аналогии с помещением и дверью: вы можете покинуть помещение через окно, хотя дверь по-прежнему закрыта и ключ к ней не подходит.
• S3 – Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности. Так, вы можете покинуть помещение без использования ключа (дыра в безопасности), через вентиляцию (другая точка входа) или дверь открывается не в ту сторону (как следствие, упирается в угол и открывается только частично – некорректная реализация). Наиболее часто встречаются дефекты, которые можно отнести именно к этому уровню серьезности.
• S4 – Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу. По аналогии с помещением и дверью – на двери написано «От себя», хотя она открывается на себя, неудобное расположение замочной скважины и т.д.
• S5 – Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня «minor». Обычно это грамматические дефекты в сопроводительной документации к системе. Иногда дефект относится к «невидимым» проблемам с точки зрения пользователя или пользовательского интерфейса и рассматривает сторонние библиотеки или сервисы, не относящиеся к самой разработанной системе. По аналогии с помещением и дверью – замок и ключ не одного производителя, в помещении слышится шум сверху (не относится к самому помещению) и т.д.

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

Подводя итог, нужно помнить, что проставление описанных выше атрибутов является важной частью процесса разработки и тестирования программных продуктов, поскольку атрибуты однозначно классифицируют все дефекты по типу: степень влияния на систему и последовательность их исправления. Как следствие, это позволяет проводить быстрый поиск или делать сортировку, формировать наглядные отчеты и не тратить время на излишние коммуникации. Проставляйте атрибуты правильно и да пребудут ваши системы в добром здравии!

Обсудить в форуме