среда, 15 июля 2009 г.

Описание дефекта: Severity и Priority

У одного из тестировщиков возник вопрос по одному из полей в описании дефекта. А именно влияние на функциональность (там было два статуса: влияет/не влияет).

Вопрос был следующий: зачем это нужно, а если нужно, то по каким критериям оценивать влияние.

По каким причинам он появился у нас в описании дефекта в таком виде уже и не вспомнишь. Поэтому начали разбираться. Как оказалось, это был компромисс между добавлением/не добавлением поля Severity (а компромисс это зачастую наихудшее решение).

В итоге разобрались и документально зафиксировали следующее:

Severity и Priority - это две отдельные активности.

Severity - это оценка важности дефекта в контексте приложения в целом, и определяется тестировщиком.

Priority - это необходимость исправления этого дефекта в контексте текущего релиза, и устанавливается лицом, отвечающим за релиз, исходя из нескольких факторов (например - severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).

Слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority - это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

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

По большому счету, можно ограничиться тремя критериями:

а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно);

б) функциональная проблема (участок функционала работает неправильно);

в) блокирующая проблема (определенная функциональность отвалилась).

* В данном случае очень важно понимать что является функциональностью и что для каждого программного продукта набор функциональности различается. (Например таймауты это функциональность или нет, ну и т.д.)

 

Как резюме можно процитировать одного из участников обсуждения на форуме it4business:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность - добавляйте. Если внесет путаницу - не множьте сущности без необходимости :)

3 комментария:

  1. Вот определения, которые я выложил на сайте Про Тестинг, описывая "Важность и Приоритет Дефекта" (http://www.protesting.ru/testing/bugpriority.html ):

    Важность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

    Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.


    Вот... Так что, в принципе я согласен с автором - Severity определяет тестер, Priority - менеджер.

    ОтветитьУдалить
  2. В нашем багтрекере я поначалу заложил использование этих двух полей, однако же на практике оказалось, что достаточно одного общего.
    К этому многие приходят со временем, один из ярких примеров - разрабочики Jira:
    http://confluence.atlassian.com/pages/viewpage.action?pageId=192840

    ОтветитьУдалить
  3. olegko, разарботчики джиры - молодцы, т.к. создали неплохой продукт, но все же хочется отметить вот что. Я соглашусь, что для некоторых проектов хватит и одного параметра. Но как вы будете в этой "кухне" разбираться, если у Вас продукт за 3-4 года оброс сотней другой известных дефектов, и каждый раз находятся новые? Как вы будете приоритизировать какие исправления должны быть сделаны и в какой очередности?
    И вопрос уже не в Важности самого дефекта, а в важности того, как быстро он должен быть исправлен. Для этого на помощь и приходит "инструмент менеджера", а именно параметр - Приоритет.

    Спасибо.

    ОтветитьУдалить