Как был построен процесс разбора багов
Что проверяют
Были ли вы участником процесса или только заводили тикеты. Интервьюеру важно, понимаете ли вы путь бага от обнаружения до закрытия и кто на каждом шаге принимает решение. Следом часто спрашивают, чем severity отличается от priority и что делать с багом, который разработчик не может воспроизвести.
Как отвечать
Это вопрос про ваш опыт, поэтому рассказывайте про реальную команду, а каркас держите такой:
- заведение: где живут баги (Jira, YouTrack), обязательные поля шаблона: версия сборки, окружение, шаги, ожидаемый и фактический результат, логи, скриншот или видео;
- триаж: кто и как часто разбирает новые баги. Например, QA лид, тимлид и продакт раз в день или дважды в неделю ставят priority, назначают исполнителя, отсеивают дубли и «не баг»;
- severity и priority: первую ставит QA по влиянию на систему, вторую бизнес по срочности. Опечатка на главной бывает низкой severity и высоким priority;
- жизненный цикл: статусы от New до Closed с возвратом в Reopened, кто переводит баг в Ready for test и кто закрывает;
- после исправления: перепроверка на указанной сборке, регрессия рядом, автотест на найденный сценарий, чтобы баг не вернулся;
- разбор утечек: по багам, пойманным на проде, ищут, почему их не поймали раньше, и дописывают проверки.
Цифры называйте только свои и только те, которые реально считали: среднее время от заведения до триажа, доля переоткрытых. Если процесс строили до вас, скажите это прямо и опишите, что в нём работало, а что вы бы поменяли. Это честнее и звучит сильнее, чем чужая история от первого лица.
Где спотыкаются
Путают severity и priority или считают их одним полем. Для QA это базовое различие.
Приводят круглые проценты вроде «сократили время исправления на 30%» и не могут объяснить, как считали. Интервьюер обязательно уточнит.
Описывают только «нашёл, завёл, отдал разработчику». Не хватает триажа, критериев закрытия и работы с невоспроизводимыми багами: запрос логов, уточнение окружения, статус Need info вместо тихого закрытия.