Как тестировщик описывает баги для понимания места и причины ошибки
Что проверяют
Фронтендер должен уметь и написать хороший баг-репорт, и прочитать чужой. Интервьюеру важно, чтобы по вашему описанию разработчик нашёл место ошибки без переписки. Следом часто спрашивают, как вы отличаете баг фронтенда от бага бэкенда.
Как отвечать
Каркас репорта:
- заголовок: что сломалось и где, одной строкой: «Форма регистрации не отправляется при email с плюсом»;
- шаги воспроизведения: пронумерованные, с тестовыми данными, начиная с чистого состояния;
- ожидаемый и фактический результат: раздельно и без оценок;
- окружение: браузер и версия, ОС, размер окна, стенд, версия сборки или хеш коммита, фича-флаги, роль пользователя;
- частота: воспроизводится всегда или один раз из пяти.
Чтобы было понятно место и причина, на фронтенде нужны артефакты из DevTools:
- Console: текст ошибки со стеком. С source maps стек указывает на файл и строку исходника, а не на минифицированный бандл;
- Network: запрос, статус, тело ответа. Экспорт в HAR отдаёт разработчику весь обмен разом;
- состояние: содержимое
localStorage, куки, состояние стора из React DevTools или Redux DevTools; - запись экрана: для багов вёрстки и анимаций скриншота мало.
Граница между фронтендом и бэкендом часто видна прямо в Network. Если сервер вернул 500 или неверные данные, копать надо в бэкенде. Если ответ правильный, а интерфейс показал не то, ошибка в клиенте. Гипотезу о причине добавить можно, но отдельной пометкой, а не вместо фактов. Если подключён Sentry или аналог, приложите ссылку на событие.
Где спотыкаются
Пишут «не работает кнопка» без шагов и окружения. Разработчик тратит полчаса на то, что автор репорта знал сразу.
Смешивают несколько проблем в одном репорте. Одну исправят, а репорт закроют целиком.
Прикладывают скриншот консоли с обрезанным стеком вместо текста. Скопированный текст ищется поиском, картинка нет.