кого четкие критерии, по которым вы выставляете багам приоритет?
Через гугление нашел пару формул. Например:
"Глобальный приоритет (Global priority) = Серьезность(Severity) * Частоту возникновения (Frequency) * Локальный приоритет (BasePriority)"
Но, во-первых, определение локального приоритет довольно субъективно, а, во-вторых, хотелось бы чего-то более простого и однозначного.
Может, кто поделится своими практиками, как у них это принято?
По тем же критериям, по которым мы бухгалтерскую отчётность составляем. Т.е. никак. Тестировщик, согласно роли, приоритеты не выставляет.
Тут вопрос немного шире, чем чисто про тестировочную деятельность. Хочется сформулировать четкие , не субъективные критерии, которые как раз и будут юзать те, кто приоритеты выставляет
1. Блокер - работа модуля/сервиса блокирована. Или потеря данных пользователя. 2. Критикал - блокер, который можно обойти. Например, есть другое меню еще и можно вызвать нужный функционал. 3. Средний 4. Низкий - опечатки, мелкие баги.
Это почему? Через пару месяцев работы вполне можно понять какой приоритет у бага в продукте.
Ето ты про северити )
Спасибо за ответ, но, мне кажется, это скорее Severity. С его определением у нас особенных проблем нет, есть весьма четкие и понятные правила определения. А хотелось бы обсудить именно приоритет взятия в работу
Я привык к баг-трекерам, где один атрибут, а не два.
Ага, вот мы так и жили до недавних пор) Ориентировались чисто на Северити. Но сейчас дошли до момента, когда в бэклоге скопилось порядочно багов с одинаковым Северити. И пришла мысль, что недурно бы их разграничить по порядку взятия в работу. И внезапно оказалось, что расстановка приоритета не такое элементарное дело, как кажется на первый взгляд)
Тогда вам к бизнесу))
Приоритет определяет лицо принимающее бизнес решение - «как срочно нужно пофиксить баг». Если на вашем проекте вы занимаетесь проставлением приоритетов, значит вы знаете потребность бизнеса и готовы принимать такие решения. Не совсем понятно тогда, какие четкие критерии вам нужны :)
А можно и не понять. Зависит от продукта, от доступа к специфической информации, доступа к коммуникациям с клиентом, к анализу рынка, к финансовой информации. Много у нас тестировщиков имеют доступ и изучают бухгалтерский баланс компании-работодателя (утрирую, конечно, ПО тоже туда не часто пускают)? Плюс, это уже зона ответственности и компетенций ПО. Я не имею в виду частные случаи, когда от ПО приходит информация вида "фича N очень важна для нас, все баги в фиче N серьёзнее minor имеют первый приоритет"
В общем виде это решается подключением к обсуждению того, кто аккумулирует ответственность за проект/продукт
Например, есть два бага: "кнопка желтого цвета, а не красного" и "кнопка с круглыми краями, а не с квадратными". И вот какую багу брать в приоритетную разработку? С точки зрения бизнеса они примерно одинаковы. 🤷♂️ В случае с двумя багами проблем нет, просто взять любую, да и все. Но когда их несколько десятков, вопрос встает острее
2 баги или 10, не важно, как по мне, загребайте бэклог просто вытаскивая по порядку или выберете любой удобный для команды критерий (не знаю, допустим баг в функциональности логина будет приоритетнее бага в функциональности форума), если прямо сейчас какой-то баг не афектит продукт или не достаточно данных для принятия решения повысить приоритет до «горит жёпа»
Обсуждают сегодня