Наткнулся на ветку случайно, но вмешаюсь, хоть и с опозданием.
Я поддерживаю Алексея.
Одна из целей тестирования - получение информации от свойствах ПО.
Создание баг-репорт - это фиксирование полученной информации.
В небольших проектах допустима однозначная обработка сигналов (завели баг - нужно пофиксить до релиза).
В этом случае допустимо связывать северити и приорити линейно. И проектом фактически начинают управлять тестировщики :-)
В больших и сложных проектах уже начинают учитываться другие факторы. Напрмер, ROI на изменение кода, риски изменений кода на данном этапе и т.п.
Пример.
В середине проекта нам нужно получть демо-версию для презентации нового GUI заказчикам.
Меняется ли от этого северити заведенных багов? Нет.
Меняестя ли приоритет? Да, нам нужно выбрать определенные баги в GUI и пофиксить их до презентации.
Понятно, что в конечном итоге все сводится к фиксим - не фиксим.
Но решение принимается на основании анализа различных факторов. Северити - один из них.
Для больших проектов лучше разделять в баг-трекере сущности баг-репорта и реквеста на изменения кода, северити и приоритета.
Скажем, у нас они достаточно большие - несколько тысяч багов фиксится и релизимся мы с несколькими сотнями известных.
Баги было решено не фиксить по различным соображениям, т.е. приоритет у них idle.
Северити даст нам более объективную информацию о качестве того, что мы релизим.
В общем, северити имеет смысл в контексте свойств продукта, а приоритет в контексте проекта.
Да не придираюсь я к словам, чего ты :)
Разве я недостаточно убедительно объяснил, что баг-репорт может приводить к появлению нескольких тасков на разных исполнителях, которые могут выполняться параллельно, так что линейность работы по устранению дефекта нарушается?
Это таск и сабтаск. При чём тут коренное изменение сути проектного артефакта отображающего его характеристики и как следствие задающее формат его описания?