2

Продолжительное время я допускал классическую ошибку. Определения в духе

Severity - определяет степень влияния на работоспособность приложения

казались мне логичными и правильными.

Не работает одна из функций без workaround-a - major. Сбился текст до нечитаемости - minor. Просто и понятно. Но, как оказалось - неверно.

Чтобы понять почему, давайте вспомним, зачем нужно Severity дополнительно к Priority. Самое популярное применение - это предварительный фильтр, помогающий лицам принимающим решения об устранении. Когда поток дефектов велик, удобно концентрироваться на важных проблемах (major), и только пробегать по неважным (minor). Второе популярное применение - метрика качества продукта (много мажорных - плохо, мало - хорошо).

Последние годы происходит переосмысление тестирования, индустрия переходит от "верификации спецификации" к широкому "изучению влияния проблемы на прибыльность бизнеса". Несомненно существует корреляция, и нерабочие функции, чаще обходятся дороже, чем проблемы с вёрсткой. Но в каждом конкретном случае находятся исключения. Зачем же тогда мы автоматически призываем ставить функциональные проблемы выше нефункциональных?

Я предлагаю скорректированное определение:

Severity - определяет степень влияния проблемы на прибыльности бизнеса

Классический (неверный) пример: "На лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании)." Данный дефект принято считать минорным, но "имеющим большие репутационные риски, а значит - высокоприоритетным". Согласно новому определению, дефект, который несёт большие риски для бизнеса, не может быть минорным. Данный дефект - самый настоящий мажор, требующий повышенного, а не пониженного внимания.

Еще один пример - "неработающие функции, которыми практически не пользуются пользователи" против "время отклика приложения для платных пользователей увеличилось в 3 раза (но всё работает)". Какой из дефектов более мажорный?

Важный вопрос - в каких случаях Severity не нужна вовсе? Так как Severity используется для фокусировки и измерения промежуточного состояния, она не нужна, когда команда своевременно справляется со всеми найденными дефектами. Если мы успеваем внимательно прочитать и пофиксить (или решить, что с дефектом можно жить без фикса) всё - то вполне достаточно оперативной приоритезации, и Severity не нужна.

Другие заметки про Severity в этом блоге
В данной заметке присутствуют цитаты из этой статьи

 

 

Если вы используете maven для сборки (альтернатива - gradle), то вы можете легко сгенерировать примерный проект с помощью публичного архетипа selenide-junit5-archetype.

Выберите groupId (обычно домен компании в обратном порядке), и artifactId - (название проекта).

Проект создастся в папке указанной в artifactId. Его можно открыть с помощью IDE, на данный момент он состоит из 3 небольших классов и файла конфигурации pom.xml

Мы можем запустить тесты с браузером по умолчанию (Chrome)

Запустить с браузером Firefox

Запустить Chrome в невидимом режиме (headless)

Подробная инструкция со списком опций генерации и дополнительными примерами находится на Github.