3

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Прочитал в сети аргументы, что, мол, раз Atlassian выпилило поле Severity из набора полей в JIRA по умолчанию, то это значит, что индустрия пришла к тому, что Severity никому не нужно.

Полная ерунда. Поле Severity ушло из стандарта JIRA потому что индустрия, пришла к тому, что JIRA чаще используется НЕ в качестве баг-трекера, а в качестве таск-трекера. Для тасков, в отличии от багов - поле Severity действительно не нужно. Я поддерживаю решение Atlassian оставить набор полей по умолчанию таким, чтобы большинство проектов не должны были что-то изменять. Но там где вы используете JIRA как баг-трекер, добавьте в большинстве случаев Severity для багов. Зачем и почему - описано в видео:

5

Недавно заметил, что могу давать для одного и того же бага в одном и том же софте разные оценки "Severity" в зависимости от "истории болезни".
Например появляется какой-то незначительный баг, неудобство для пользователя - никаких последствий для функциональности. Логично ставлю "Minor". Если же неудобство появилось в новой версии программы, а до этого было "удобно" - то рука чешется поднять до "Moderate", и обычно я себе в этом не отказываю.
Логика довольна простая -"проблема" обнаруженная в месте, в котором пользователь столкнётся с ней впервые - легче, чем та же самая "проблема", которую пользователь не испытывал в предыдущих версиях. Ухудшение существующего положение вещей - всегда хуже, чем неоптимальное нововведение.

Получается, что оценка Severity не всегда является статичной по отношению к текущему состоянию приложения.

3

Очередная критическая разборка доклада, на этот раз на очереди Андрей Ладутько с беседой об аудите:

В целом доклад мне показался интересным, но в некоторых моментах неполным или спорным. Мне показалось, что в начале Андрей несколько нервничал и спешил, затем темп стал лучше и ведение доклада стало очень уверенным.

Начну с критики по содержанию доклада:

  • "аудит - предпоследняя фаза проекта" - вообще говоря, я бы не включал аудит вообще в фазы проекта. По моему опыту, он чаще проводится после окончания проекта или его части, чтобы использовать опыт в следующих проектах. Или в середине проекта - когда все ужас-ужас. Или, упаси Болтон, назначается судом, когда заказчик не смог договорится с исполнителем, как полюбовно разрулить абсолютное недовольство заказчика результатом.
    Конечно, никто не запретит рутинно проводить аудит "предпоследним перед сдачей", но вроде и частью процесса он обычно не является. Для меня это полезный тул - который можно использовать (иногда).

    Update. Неправильно услышал, говорилось, что тестирование - предпоследняя фаза. Это тоже вещь довольно спорная, но то, что результаты тестирование ближе к концу наиболее полны и заметны - с этим не поспоришь.

  • "Жизненный цикл процесса", "надо обсуждать весь процесс" - тут возникла путаница, мне показалось, что докладчик в большинстве случаев имел ввиду полный процесс разработки (который включает тестирование). Но в заголовке доклада - "процесс тестирования", и на некоторых других слайдах тоже однозначно он. Местами было сложно понять, какой из процессов имеется ввиду в данный момент, следовало как-то лучше разграничить.

...читать далее Линч-пакет: Андрей Ладутько “Как оценить процесс тестирования на проекте”

2

В этот раз видео появилось быстро. Доклад вышел удачно, некоторый поток слов-паразитов мне сдержать не удалось, но тем не менее было динамично и весело, особенно вопросы (последние 12 минут). Спасибо модератору за 7 бонусных минут сверх положенного времени :).

Подробный разбор будет чуть позже, пока что в качестве тизера - комикс из доклада.

SevPrioComicsFull1
Смотрите, задавайте вопросы!

 

7

В пятницу 29 мая, в Минске буду читать доклад на SQA Days 17.

Приходите - я очень старался сделать доклад интересным!
Я предполагаю, что все зрители понимают основы использования, и уже так или иначе сталкивались с применением на практике.

Если применение у вас проходило не идеально - есть смысл послушать мой доклад. Я расскажу про не очень известные тонкости, которые помогут уменьшить стресс и проблемы с коммуникацией во всей  команде разработки. Я обещаю, каждый, кто прослушает доклад до конца услышит что-то новое, что он еще не слышал и не читал в других статьях по этой тематике.

Кто после доклада приведет мне линки на советы и приёмы аналогичные указанным - получит пиво/шоколадку 🙂

SeverityVsPriority_Рус_key

До встречи на докладе!