Comments 2
Кстати про "приоритеты". Недавно была в команде (команда новая) дискуссия, мол зачем поле приоритета ведь заказчик и так сортирует бэклог по приоритету. Так вот, major, minor, critical, это не приоритеты, это тяжесть бага - severity, степень его влияния на пользователя. И это не одно и то же что и приоритет. Но создатели джиры решили отказаться от этого разделения.
В опенсорсе задолго до повсеместного распространения джиры, были поля priority и severity. И первое это приоритет задачи выставляемый разработчиком, или продакт менеджером, а степень тяжести (т.е. степень влияния на пользователя) проставляет пользователь.
По аналогии с примером остюда - если система крашится для нескольких человек с экзотическим сетапом, то это высокая степень тяжести, но более низкий приоритет, чем если двадцать тысяч пользователей нажимают не на ту кнопку из-за плохо подобраных цветов или размеров элементов управления.
В коммерческой разработке часто можно заметить такое. Когда компания ставит приоритет задачам приносящим деньги, и расширяющим клиентскую базу, а решение багов по приоритету занижает. Хотя баги затрудняют пользование программой для существующих клиентов.
Спасибо за комментарий!
Насчет теории использования понятий severity и priority полностью согласна. Раньше я старалась внедрять на проектах и приоритет, и важность бага (в качестве системы управления проектами использовали не Jira). Но на практике со временем и я, и команда приходили к тому же заключению - удобнее использовать только одно поле "приоритет", которое объединяет в себе 2 понятия и говорит за общую важность задачи и скорость ее исправления.
Поэтому в статье я говорю только про приоритет. По выбору приоритета я пользуюсь следующим принципом. Сначала тестировщик устанавливает приоритет, исходя из степени влияния бага на работоспособность приложения. А далее сам тестировщик, ПМ, PO или другое ответственное лицо может изменить приоритет бага в зависимости от влияния на бизнес.
Какую градацию приоритетов выбрать - думаю, это вопрос договоренностей в команде.
Как организовать процесс тестирования с 6 шагов