Как боролись с багами и жалобами от пользователей
Что проверяют
Замыкаете ли вы цикл от жалобы пользователя до регрессионного теста или просто пересылаете тикеты разработчикам. Следом обычно просят разобрать один конкретный баг: как воспроизвели, кто решал приоритет, что поменяли в процессе.
Как отвечать
Вопрос про ваш опыт, поэтому каркас наполняйте своими примерами и цифрами:
- поток жалоб: откуда приходят (поддержка, отзывы в сторах, Sentry, Crashlytics) и как вы их разбирали: дедупликация, группировка по причине, связь обращения с тикетом в Jira или YouTrack;
- воспроизведение: логи в Kibana или Grafana, версия приложения и устройство, HAR-файл, запись экрана. Баг-репорт с шагами, ожидаемым и фактическим результатом, окружением;
- приоритет: разделяйте severity (насколько сломано) и priority (как срочно чинить) и объясните, кто принимал решение;
- закрытие цикла: проверка исправления, регрессионный автотест или кейс в Test IT или Qase, ответ поддержке, чтобы она закрыла обращение;
- выводы: разбор, почему дефект дошёл до пользователей и что добавили: новую конфигурацию в тестах, проверку на стейдже, алерт в мониторинге.
Цифры называйте только настоящие: доля багов с прода, crash-free rate, время от жалобы до фикса. Если точных данных нет, скажите, что считали, а не придумывайте «минус 40% жалоб».
Если с живыми пользователями вы не работали, так и скажите и расскажите про баги из внутреннего тестирования: как искали причину, как договаривались с разработчиком, что изменили в чек-листах. Это честнее и звучит убедительнее выдуманной истории.
Где спотыкаются
Рассказывают только «завёл баг в Jira». Интервьюеру интересен путь дальше: кто исправил, как проверили, что сделали, чтобы такой баг больше не прошёл.
Путают severity и priority или считают, что приоритет тестировщик выставляет единолично. Обычно это решение вместе с продактом или тимлидом.
Обвиняют разработчиков или пользователей. Даже если причина была в чужом коде, говорите о процессе и о том, что вы поменяли у себя.