Как общаться с разработчиками при баг-репортах
Что проверяют
Умеете ли вы описывать дефект так, чтобы его чинили, а не спорили с вами. Это про содержание отчёта и про тон.
Как отвечать
Начните с содержания. Хороший отчёт закрывает вопросы разработчика заранее:
- короткий заголовок по сути: что сломалось и где, а не «не работает»;
- шаги воспроизведения от чистого состояния, с указанием данных и учётной записи;
- ожидаемое и фактическое поведение, со ссылкой на требование, если оно есть;
- окружение: стенд, версия сборки, браузер или устройство;
- доказательства: скриншот или запись, ответ сервера, идентификатор запроса, время, фрагмент лога;
- частота: воспроизводится всегда или иногда, и при каких условиях;
- влияние: сколько пользователей затронуто и есть ли обходной путь. Это и определяет приоритет.
Теперь про тон, ради которого вопрос и задают. Дефект описывается как факт о системе, а не как претензия к человеку: «при таких шагах сервер отвечает 500» вместо «ты сломал форму». Приоритет предлагается, а не назначается ультиматумом, и обсуждается с командой.
Что делать в типичных ситуациях: «не воспроизводится» это повод сесть вместе и пройти шаги, а не спор в комментариях; «это не баг, так задумано» это повод поднять требование и уточнить у аналитика; спорный приоритет решается влиянием на пользователя, а не громкостью.
И правило вежливости, экономящее время всем: проверить, нет ли уже такого дефекта, и приложить всё сразу, а не дозаливать по одному файлу после каждого вопроса.
Где спотыкаются
Пишут «не работает регистрация» без шагов и окружения.
Обсуждают дефекты в личных сообщениях, и договорённости теряются.
Переходят на личности или, наоборот, соглашаются закрыть реальный дефект без аргументов.