Производится ли анализ багов службой поддержки
Что проверяют
Видите ли вы поток дефектов целиком, от жалобы пользователя до правки и нового теста. Вопрос уместно задать и самому: ответ показывает, разбирает ли поддержка обращения или пересылает всё дальше, а значит, чем будет занята ваша неделя.
Как отвечать
Опишите нормальный маршрут обращения.
- Первая линия отсекает вопросы, известные проблемы и ошибки пользователя, собирает минимум данных: версия, платформа, время, идентификатор запроса, шаги, ожидаемое и фактическое поведение.
- Триаж. Обращение становится дефектом, только если воспроизведено или подтверждено логами. Здесь же дедупликация: одинаковые жалобы склеиваются в один дефект со счётчиком обращений.
- Оценка. Severity это техническая тяжесть, priority это очередь на починку. Массовая косметическая ошибка и редкая потеря денег встают в очередь по-разному.
- Обратная связь в тесты. На каждый утёкший в прод дефект отвечаете вопросом, почему его не поймали, и добавляете проверку в регресс или в мониторинг.
Полезно назвать метрики, которые смотрите: доля дефектов, найденных пользователями, а не тестами, время до воспроизведения, повторные открытия. Если спрашиваете вы, попросите показать одно живое обращение и путь, который оно прошло.
Где спотыкаются
Путают severity и priority, а вместе с ними и роли: поддержка приносит боль пользователя, но очередь задаёт владелец продукта с учётом рисков и сроков.
Берут в работу обращение без данных для воспроизведения и месяцами гоняют его между командами. Порог входа в дефект должен быть описан, иначе в трекер попадает пересказ телефонного разговора.
Чинят, не закрывая причину. Тест не добавлен, мониторинг не настроен, и та же ошибка возвращается в следующем релизе уже как «новый» дефект.