Ответ.

История вопроса:

С момента появления систем отслеживания ошибок тестировщики столкнулись с задачей: как передавать баги так, чтобы разработчик без лишних вопросов мог их воспроизвести и исправить? Именно отсюда появилась культура четкой фиксации шагов, окружения, условий возникновения и фактического результата.

Проблема:

Плохо оформленный баг-репорт — это причина затяжных холиваров и недопонимания в команде. Часто баг теряется, не повторяется, и закрывается "как не воспроизведен", из-за чего дефект остается жить в системе.

Решение:

Строго следовать структуре оформления: шаги воспроизведения, ожидаемый и фактический результат, окружение, severity, при необходимости — вложение скриншотов или логов.
Проверять баги "чистыми руками": с новым пользователем, пустым кэшем, чистым браузером.
Использовать шаблоны баг-репортов и чек-листы для самоприки.

Ключевые особенности:

Необходимость четкости шагов (исторически — чтобы баг мог воспроизвести кто угодно).
Указание минимального набора информации: окружение (версия ПО, браузер, ОС).
Иллюстрация багов (скриншоты, логи, видео).

Вопросы с подвохом.

Можно ли оформлять баг только на словах, если все в команде "и так поняли"?

Нет. Даже в устоявшихся командах всегда важно фиксировать баг формально: история изменений, ротация состава и память о баге не бесконечны.

Нужно ли писать каждый баг с "нулевого" состояния (логин/разлогин/тд)?

Если шаги до бага тривиальны (стандартный логин) — их можно опускать, но если сессия, профилирование или настройки специфичны — полное воспроизведение критично.

Все ли баги нужно снабжать скриншотами/видео?

Не всегда. Если баг очевиден по описанию (орфографическая ошибка), скриншот полезен но не обязателен. Но если баг связан с визуальным отображением/версткой, обязательно приложить визуальное подтверждение.

Типовые ошибки и анти-паттерны

Нечеткое или неполное описание багов («что-то не работает»)
Отсутствие информации об окружении
Отсутствие шагов воспроизведения

Пример из жизни

Негативный кейс

Тестировщик заводит баг "Не работает кнопка" без шагов и окружения. Разработчик не может повторить ошибку.

Плюсы:

Экономия времени на заведение тикета.

Минусы:

Баг остается не закрытым или возвращается тестировщику, портится коммуникация.

Позитивный кейс

Тестировщик формализует баг: указывает шаги, версию приложения, браузер, добавляет скриншот и системный лог.