Приоритет в магазине и в баге

Понятное дело, что для своей задачи хочется всегда поставить высокий приоритет. Ведь это же такой страшный баг, надо срочно исправить! Особенно когда речь идет о новичках ツ

Но представьте, что вы пришли в магазин за продуктами. И оказалось, что банковские карты временно не принимаются, банкомата рядом нет, а налички очень мало. 

И вот тут начинается приоритезация. Что действительно важно купить? Кошке корм хотели, но он ещё есть, зато молока совсем нету, лучше взять его. Высокий приоритет получают те продукты, без которые важно купить именно сейчас. А всё, что можно отложить на потом (завтра / в среду / через неделю) — это уже не высокий приоритет.

Аналогично в багах. Высокий приоритет — это когда задачу нужно исправлять срочно! Вот у нас на курсе для новичков ребята тестируют реальные приложения, то есть PROD (система, с которой работают реальные пользователи).

И если они находят баг с действительно высоким приоритетом, то ко времени зачета (пока нормально оформят, опишут результат, обоснуют... Занимает около недели обычно) она уже исправлена и не воспроизводится. Такие задачи мы тоже принимаем, если в них есть подтверждения (скриншоты).

Но смысл в том, что, если ваша задача так и висит пару недель или месяц — то для разработчиков это явно невысокий приоритет ツ Ну или в компании нет тестировщиков, и о баге они просто не знают...

См также:

Severity и Priority. Заполняем приоритет в баге

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков