Продолжительное время я допускал классическую ошибку. Определения в духе
Severity - определяет степень влияния на работоспособность приложения
казались мне логичными и правильными.
Не работает одна из функций без workaround-a - major. Сбился текст до нечитаемости - minor. Просто и понятно. Но, как оказалось - неверно.
Чтобы понять почему, давайте вспомним, зачем нужно Severity дополнительно к Priority. Самое популярное применение - это предварительный фильтр, помогающий лицам принимающим решения об устранении. Когда поток дефектов велик, удобно концентрироваться на важных проблемах (major), и только пробегать по неважным (minor). Второе популярное применение - метрика качества продукта (много мажорных - плохо, мало - хорошо).
Последние годы происходит переосмысление тестирования, индустрия переходит от "верификации спецификации" к широкому "изучению влияния проблемы на прибыльность бизнеса". Несомненно существует корреляция, и нерабочие функции, чаще обходятся дороже, чем проблемы с вёрсткой. Но в каждом конкретном случае находятся исключения. Зачем же тогда мы автоматически призываем ставить функциональные проблемы выше нефункциональных?
Я предлагаю скорректированное определение:
Severity - определяет степень влияния проблемы на прибыльности бизнеса
Классический (неверный) пример: "На лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании)." Данный дефект принято считать минорным, но "имеющим большие репутационные риски, а значит - высокоприоритетным". Согласно новому определению, дефект, который несёт большие риски для бизнеса, не может быть минорным. Данный дефект - самый настоящий мажор, требующий повышенного, а не пониженного внимания.
Еще один пример - "неработающие функции, которыми практически не пользуются пользователи" против "время отклика приложения для платных пользователей увеличилось в 3 раза (но всё работает)". Какой из дефектов более мажорный?
Важный вопрос - в каких случаях Severity не нужна вовсе? Так как Severity используется для фокусировки и измерения промежуточного состояния, она не нужна, когда команда своевременно справляется со всеми найденными дефектами. Если мы успеваем внимательно прочитать и пофиксить (или решить, что с дефектом можно жить без фикса) всё - то вполне достаточно оперативной приоритезации, и Severity не нужна.
Другие заметки про Severity в этом блоге
В данной заметке присутствуют цитаты из этой статьи