Дмитрий Ланецкий – QA и разработка на одном языке: Репорты, уточнения, «не воспроизвёлось» (страница 6)
Заголовок:
[Модуль/Экран] – плавающий баг: [симптом] (примерные условия)
Кратко:
Что происходит и почему важно.
Наблюдаемый сценарий:
Что вы делаете в целом (без претензии на 100% воспроизведение).
Частота:
Базово: X из 10
Wi-Fi: X/10
LTE: X/10
VPN on: X/10
VPN off: X/10
(или любые ваши переключатели)
Подозреваемые условия (наблюдения):
чаще появляется когда…
исчезает когда…
Что уже проверено:
пробовал A → результат
пробовал B → результат
Ожидаемое:
…
Фактическое:
…
Окружение:
(версии, устройство, ОС, сеть, аккаунт, регион)
Временные метки:
2026-02-21 18:42 UTC+…
2026-02-21 18:57 UTC+…
Артефакты:
(видео/логи/ID запросов/crash report)
Плавающий баг – это не «неуловимый». Это просто баг, у которого ещё не названо условие. Когда вы собираете данные системно, вы постепенно выдавливаете «иногда» в конкретику. И как только условие названо – баг перестаёт быть привидением и становится обычной задачей, которую можно чинить.
Следующая глава логично продолжит охоту: как писать репорты так, чтобы они не были одиночными историями, а сразу превращались в систему – шаблоны, базы знаний и автоматизация с ИИ.
Глава 4. Доказательства, не украшения: скриншоты, видео, логи и искусство не утопить разработчика
Баг-репорт без артефактов – это свидетельские показания. Иногда их достаточно. Но чаще всего команда хочет ещё и отпечатки пальцев: скриншот с контекстом, видео с таймкодами, логи, трассировку, ID запроса. Проблема в том, что артефакты легко превратить либо в мусор (красивый скрин без смысла), либо в информационный потоп (пятьдесят файлов «посмотрите тут»).
Эта глава – про золотую середину: как приносить доказательства, которые ускоряют отладку, и не приносить шум, который её замедляет.
Артефакт – это ответ на конкретный вопрос
Самый правильный способ думать об артефактах: каждый из них должен отвечать на один из вопросов:
Что именно увидел пользователь?
Что система делала в этот момент?
Где в цепочке произошло отклонение?
В каком контексте это происходило (экран, состояние, аккаунт, сеть)?
Как привязать событие к логам/метрикам?
Если артефакт не отвечает ни на один вопрос – он декоративный. А декоративные артефакты делают репорт тяжелее, но не полезнее.
Скриншоты: как сделать их «читабельными» для инженера
Скриншот кажется простым: нажал кнопку – приложил картинку. Но именно скрины чаще всего бесполезны, потому что на них отсутствует контекст.
Полезный скриншот содержит:
место (какой экран/раздел/страница),
состояние (что выбрано, какие поля заполнены),
событие (ошибка, сообщение, неактивная кнопка),
якорь (время/версии/URL – если применимо).
И главное: скрин должен быть сделан до того, как вы ушли со страницы. Момент после ошибки иногда уже «другой мир»: система откатилась, сообщение исчезло, состояние изменилось.
Аннотация важнее красоты.
Один красный прямоугольник и подпись «кнопка неактивна после выбора доставки» ценнее, чем скрин в 4K без отметок. ИИ тут хорош как редактор: вы можете попросить его сформулировать подписи к скрину, чтобы они не были «тут сломалось», а были конкретными.
Частая ловушка: обрезка «до ошибки».
Если вы обрезали верхнюю часть, и не видно названия экрана/URL – разработчик теряет координаты. Лучше оставить чуть больше интерфейса, чем лишить скрин смысла.
Видео: когда динамика важнее статического кадра
Видео нужно, когда баг живёт во времени:
зависание/фриз,
спиннер бесконечно крутится,
анимация ломается,
двойной клик даёт двойной запрос,
при возврате назад происходит сбой,
проблема «появляется через 15 секунд».
Правило 10–20 секунд:
Снимайте так, чтобы было 3–5 секунд до действия и 5–15 секунд после. Если видео начинается с уже случившейся ошибки, оно теряет половину ценности.