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