Приведите пример бага с высоким уровнем серьезности и низким приоритетом

Что проверяют

Развели ли вы в голове серьёзность и приоритет и можете ли привести случай, где они расходятся. Заодно смотрят, понимаете ли, кто эти поля заполняет: серьёзность ставит тестировщик по влиянию на систему, приоритет назначает владелец продукта, исходя из сроков и пользы для бизнеса.

Как отвечать

Сначала два определения по одной строке, потом пример, потом обратная пара.

Пример: выгрузка отчёта, которую бухгалтерия делает раз в год, падает с ошибкой и обходного пути не имеет. Функция не работает совсем, данные получить нельзя, значит серьёзность высокая. Но до следующей выгрузки далеко, поэтому в ближайший спринт задача не идёт и приоритет низкий.

Такого же рода случаи:

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

Покажите и обратную пару: опечатка в названии компании на главной странице. На работу системы не влияет, серьёзность низкая, а чинят первым же делом.

Закончите тем, что приоритет не приколочен гвоздями: когда до годовой выгрузки останется неделя, тот же дефект станет срочным, хотя серьёзность не изменится ни на шаг.

Где спотыкаются

Приводят пример, где серьёзность на самом деле не высокая. Сдвиг вёрстки или опечатка остаются низкой серьёзностью, как бы сильно они ни бросались в глаза, и вопрос выходит без ответа.

Второе: назначают приоритет сами и спорят, когда его меняют. Оценка влияния ваша, очередь исправления нет. Правильная реакция это принести данные о частоте сценария и о том, кого он задевает, а не настаивать на значении поля.

Третье: объясняют низкий приоритет тем, что починка долгая. Трудоёмкость это отдельная оценка, она влияет на планирование, но не на срочность. Если смешать их, дорогие и важные дефекты осядут в бэклоге навсегда.