Описание дефекта: Severity и Priority
У одного из тестировщиков возник вопрос по одному из полей в описании дефекта. А именно влияние на функциональность (там было два статуса: влияет/не влияет).
Вопрос был следующий: зачем это нужно, а если нужно, то по каким критериям оценивать влияние.
По каким причинам он появился у нас в описании дефекта в таком виде уже и не вспомнишь. Поэтому начали разбираться. Как оказалось, это был компромисс между добавлением/не добавлением поля Severity (а компромисс это зачастую наихудшее решение).
В итоге разобрались и документально зафиксировали следующее:
Severity и Priority – это две отдельные активности.
Severity – это оценка важности дефекта в контексте приложения в целом, и определяется тестировщиком.
Priority – это необходимость исправления этого дефекта в контексте текущего релиза, и устанавливается лицом, отвечающим за релиз, исходя из нескольких факторов (например – severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).
Слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой
Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority – это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.
Берем типового тестировщика. Его задача – узнать, как себя ведет программный продукт. Он в большинстве случаев взаимодействует с ним "снаружи", то есть без особых технических подробностей. Исходя из знания продукта и особенностей его применения, он оценивает важность обнаруженной проблемы.
По большому счету, можно ограничиться тремя критериями:
а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно);
б) функциональная проблема (участок функционала работает неправильно);
в) блокирующая проблема (определенная функциональность отвалилась).
* В данном случае очень важно понимать что является функциональностью и что для каждого программного продукта набор функциональности различается. (Например таймауты это функциональность или нет, ну и т.д.)
Как резюме можно процитировать одного из участников обсуждения на форуме it4business:
Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность – добавляйте. Если внесет путаницу – не множьте сущности без необходимости
Вот определения, которые я выложил на сайте Про Тестинг, описывая “Важность и Приоритет Дефекта” ( ):
Важность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Вот… Так что, в принципе я согласен с автором – Severity определяет тестер, Priority – менеджер.
В нашем багтрекере я поначалу заложил использование этих двух полей, однако же на практике оказалось, что достаточно одного общего.
К этому многие приходят со временем, один из ярких примеров – разрабочики Jira:
olegko, разарботчики джиры – молодцы, т.к. создали неплохой продукт, но все же хочется отметить вот что. Я соглашусь, что для некоторых проектов хватит и одного параметра. Но как вы будете в этой “кухне” разбираться, если у Вас продукт за 3-4 года оброс сотней другой известных дефектов, и каждый раз находятся новые? Как вы будете приоритизировать какие исправления должны быть сделаны и в какой очередности?
И вопрос уже не в Важности самого дефекта, а в важности того, как быстро он должен быть исправлен. Для этого на помощь и приходит “инструмент менеджера”, а именно параметр – Приоритет.
Спасибо.