Как правило, все знают про severity и priority, но практически никто не говорит об urgency (срочности).  Например, если есть критичный баг S1 и его не нужно срочно исправлять, то у него может быть  более низкий приоритет, к примеру - P2, а менее критичный баг S2, но который нужно исправить срочно — может иметь более высокий приоритет P1.   Формула приоритета Приоритет — не что иное, как произведение критичности бага на срочность исправления.  Теперь, когда на собеседовании вас спросят, "а чем отличается severity от priority" - можете рассказать про формулу приоритета и urgency.  Кстати говоря, формула приоритета справедлива не только для багов, но и для любых продуктовых или технических задач, только вместо критичности будет использоваться importance (важность). В Jira, в зависимости от процессов в конкретной команде/компании для задач с типом Bug может устанавливаться как priority так и severity, и автор дефекта должен уметь правильно определять значения. Если с определением критичности у QA-инженеров вопросов возникнуть не должно, то со срочностью исправления не все так просто, поскольку этот показатель, напрямую связан с приоритетами бизнеса, задачами и sprint goals.  Управление приоритетом Фактически, на срочность исправления может влиять владелец продукта, технический руководитель и вся команда в целом. Наверное, вы сталкивались с ситуацией, когда дефекты, которые были занесены вами, были переоценены product-owner'ом или technical-lead'ером.  Я, как QA-инженер, ответственный за качество, и максимально приближенный к потребностям пользователя  хочу, чтобы баги исправлялись быстрее и в больших количествах, но такой подход может не получить поддержку со стороны владельца продукта и бизнеса. И на первый взгляд, если баги не берутся в работу — может показаться, что команда разработки, бизнес и product-owner не заинтересованы в качественном продукте, но это скорее ложное предубеждение, поскольку владелец продукта имеет больше вводных и видит картину в целом. Если с небольшим количеством багов проблема срочного исправления не стоит остро, то с ростом нужно будет решить какие баги брать в работу в первую очередь, собственно, этот вопрос решает правильная приоритизация.  Дам несколько рекомендаций, которые помогли мне навести порядок в общем беклоге и опишу способы решения типовых проблем, с которыми столкнулся. Если багов скопилось много — время пройтись по списку и переоценить ихДостаточно сравнить баги между собой и прислушаться к мнению со стороны бизнеса. Еще лучше, проводить переоценку регулярно, совместно с владельцем продукта или техническим руководителем.  Технический спринт Если багов скопилось слишком много — можно организовать технический спринт, на котором вся команда займётся исправлением багов. Пирамида приоритизации Мы знаем, что по-хорошему, в текущий спринт не рекомендуется добавлять новые задачи, но критические дефекты должны исправляться чем быстрее, тем лучше.  Баги с высоким приоритетом P0-P1  могут автоматически добавляться в текущий спринт и браться в работу любым из участников распределенной команды разработки. А баги с более низким приоритетом P2-P4 могут попадать в следующие спринты, пропорционально приоритету.  Значение приоритета может означать спринт, в котором баг будет взят в работу. Пирамида приоритетов показывает как сроки исправления, так и количественное соотношение.  Баг в спринте, но его не исправляют О зависших багах стоит напомнить  команде на стендапе, а если есть риск того, что баг может переехать в следующий спринт, возможно стоит задуматься о корректировке приоритета на более низкий, а при достижении самого низкого приоритета — принять решение о закрытии бага с резолюцией won't fix. При принятии такого решения стоит вспомнить о Zero Bug Policy, и постараться принимать решение не только в момент зависания дефекта, но и на этапе создания в будущем.  Если есть свободное время и желание, то можно разобраться и исправить баг самостоятельно. Это крутой способ прокачать свои навыки, но такой способ возможен только в кросс функциональных командах. И готовьтесь к пристрастному код-ревью со стороны разработчиков. Теневые спринты Я встречался с  теневыми спринтами, когда разработчик или группа разработчиков исправляла баги не находящиеся в спринте и передавала на тестирование. Как правило, это было связано с тем, что менее приоритетные баги не могли попасть в спринт, а разработчик, реализуя новый функционал или проводя рефакторинг мог махом исправить несколько багов.  В этом подходе может слегка перегружаться ответственный за тестирование, и могут страдать продуктовые показатели команды, ввиду того, что работа не учитывается в объём стори-поинтов, заложенных в спринт.   Скрытый конфликт интересовЕсли продукт находится на раннем этапе развития, а продуктовых задач слишком много, высока вероятность, что product-owner, несмотря на заинтересованность в качестве — будет отдавать предпочтение продуктовым задачам. Здесь нужно соблюсти баланс и обсудить этот момент с командой, чтобы и качество не просело и количество продуктовых задач, доставленных в продакшн было в норме.   QA Engineer