Кто определяет приоритеты в багрепортах
Что проверяют
Знаете ли вы разницу между серьёзностью и приоритетом и понимаете ли, что последнее слово в приоритете не за тестировщиком. Почти всегда следом просят пример бага с низкой серьёзностью и высоким приоритетом, и наоборот.
Как отвечать
Сразу разведите два поля:
- серьёзность (severity): насколько сильно баг ломает систему технически. Её выставляет QA, потому что лучше всех видит последствия. Шкала обычно такая: blocker, critical, major, minor, trivial;
- приоритет (priority): насколько срочно чинить с точки зрения бизнеса. Окончательно его определяет продакт, владелец продукта или лид на триаже, с учётом релизного плана, числа затронутых пользователей и денег. QA предлагает стартовое значение.
В Jira из коробки есть только поле Priority со значениями от Highest до Lowest, серьёзность добавляют отдельным полем. Многие команды используют шкалу P0, P1, P2 с договорённостью о сроках: например, P0 чинится хотфиксом, P2 попадает в следующий спринт.
Примеры, которые стоит держать наготове:
- низкая серьёзность, высокий приоритет: опечатка в названии продукта на главной или неверная цена на промостранице перед акцией;
- высокая серьёзность, низкий приоритет: падение при экспорте в редком формате, которым пользуются единицы, при наличии обходного пути.
Расскажите и про процесс: регулярный триаж, куда QA приносит новые баги с серьёзностью, шагами и оценкой охвата, а продакт расставляет приоритет. Если вы не согласны с решением, приносите аргументы: сколько пользователей затронуто, есть ли обходной путь, что пишут в поддержку.
Где спотыкаются
Смешивают поля и говорят «критичный баг, значит самый приоритетный». Интервьюер сразу попросит контрпример.
Считают, что приоритет выставляет QA единолично. Предложить можно, решить без продакта нельзя.
Приносят MoSCoW как способ приоритизации багов. Это техника для требований и объёма релиза, а дефектам нужна шкала приоритетов с договорённостью о сроках исправления.