Сообщений в теме: 12

[hiverise]

Всем привет. Объясните простыми словами что же такое на самом деле серьезность и приоритет дефекта. Будет здорово прочесть пример из "жизни". Хочется понять, как же правильно указать серьезность и тем самым не обидеть баг) Интересно прочесть (по крайней мере мне уж точно) как правильно выработать в себе навык правильно определять серьезность дефекта. Другими словами: хочу знать то, что знаете Вы   (сразу прошу прощения, ведь возможно повторяю тему)

[Freiman]

Недавно Алексей Лупан в блоге писал про это
http://testitquickly...ica-prioritate/
(да, тема заезженная вообще :) )

[clipsa]

Всем привет. Объясните простыми словами что же такое на самом деле серьезность и приоритет дефекта. Будет здорово прочесть пример из "жизни". Хочется понять, как же правильно указать серьезность и тем самым не обидеть баг) Интересно прочесть (по крайней мере мне уж точно) как правильно выработать в себе навык правильно определять серьезность дефекта. Другими словами: хочу знать то, что знаете Вы   (сразу прошу прощения, ведь возможно повторяю тему)

Имхо, нарабатывается только опытом, при чем для каждого конкретного проекта критерии могут быть разные. Для определения "серьезности" необходимо понимать, насколько критичен данный баг для бизнеса, для определения "приоритета" необходимо понимать насколько критично данный баг исправить быстро.

[Garm]

 

 

Для определения "серьезности" необходимо понимать, насколько критичен данный баг для бизнеса

Разве? В моём понимании северити — степень влияния на продукт/систему. Если кто-то забыл убрать плейсхолдер с матами на главной, это будет high priority но low severity. Или наоборот, если есть серьёзная техническая проблема, но шанс того что конечными пользователями она будет воспроизводиться очень низок, то это low priority и high severity. Или я не прав? Всегда расценивал эту классификацию именно в таком ключе.

[clipsa]

Зависит от того, как принято в конкретно взятом проекте.

[3lll]

Priority – степень важности, присваиваемая конкретному объекту (дефект, задача), с целью указания очередности (исправления дефекта или выполнения задачи).Чем выше приоритет, тем быстрее нужно исправить дефект или выполнить задачу.

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

[hiverise]

Спасибо за разъяснения. Значит,  я думаю, мне кажется, что джуны частенько допускают ошибки при правильной оценки серьезности дефекта. И если вдруг другие товарищи по команде "проворонят" эту ситуацию, то как это повлияет на проект? И кто будет наказан? Как собственно все происходит на реальных проектах, или это считается нормальной практикой менять серьезность/приоритет существующего дефекта?  

[Freiman]

Во многих компаниях вообще не заморачиваются и оставляют только Приоритет, без всяких там Северити.
И да, можно ошибаться, можно менять. Это нормальная практика, но, конечно, делается это нечасто и по особым случаям.
То Мажора понизят до Минора и далее до ВонтФикс, то Тривиал внезапно менеджер поднимет до Критикал, если важный клиент на него случайно наткнется :)

[SHINNOK]

Решение о том какой выбрать уровень severity и priority не принимается единолично. Как правило, нужно обязательно с кем-нибудь обсудить, что лучше поставить

[Vasiliy]

Принимается)

Только не всегда тестировщиком))

[SALar]

Посмотрите "Варианты управления требованиями". Не серебряная пуля, просто перечень различных способов управления.

[hiverise]

На форумах и в книгах пишут что используется градация серьезности дефекта от 1 до 5 (Blocker, critical, major, minor, trivial) но так ли это на практике? Скорее всего на эту оценку влияют многие факторы. Можно сократить к примеру к 3? И правильно ли это?

[Freiman]

Можно сократить к примеру к 3? И правильно ли это?

Сократить можно. А можно добавить еще. Я видел оба варианта. Сколько их должно быть - зависит от продукта и процесса.