Дмитрий Ланецкий – QA и разработка на одном языке: Репорты, уточнения, «не воспроизвёлось» (страница 7)
Покажите ввод:
Если это мобильное приложение, включите отображение касаний (если возможно). Если веб – чтобы было видно курсор.
Видео как протокол:
В тексте репорта добавьте 2–4 таймкода:
00:03 – нажимаю «Оплатить»
00:05 – появляется спиннер
00:18 – toast «Ошибка операции»
00:19 – кнопка «Повторить» не реагирует
Это превращает видео из «посмотрите» в инструмент.
Логи: почему «приложил лог» – это не всегда помощь
Логи – мощное оружие и столь же мощный способ утопить коллегу. Типичная проблема: человек прикладывает огромный файл, где 95% – нерелевантные события, и ещё 5% – релевантные, но без ориентира.
Чтобы лог был полезным, ему нужны два элемента:
временная рамка (например, 18:42:10–18:42:40),
связь с действием пользователя (что вы делали в этот момент).
Если репорт содержит точное время, разработчик может найти соответствующий кусок серверных логов даже без вашего файла. А если ещё есть request ID – это почти телепорт к причине.
Что считать логом в разных системах
У разных платформ разные «свидетели»:
Веб: консоль браузера, Network (HAR), статус-коды, payload, CORS-ошибки.
Мобильные приложения: crash logs, системные логи, внутренние логи приложения (если есть), аналитические события.
Backend/API: request ID, trace ID, логи ошибок, метрики latency/timeout.
Десктоп: логи приложения, системные события.
Полезная привычка: в репорте писать «что я могу предоставить» и «что недоступно». Это экономит круг вопросов.
HAR-файл и Network tab: золотая жила для веб-ошибок
Для веба самый часто недооценённый артефакт – это не скрин. Это сетевой след: какие запросы ушли, какие ответы пришли, какие коды статуса, сколько длилась загрузка.
Если у вас есть HAR:
разработчик видит endpoint,
видит время,
видит статус и иногда тело ответа,
видит заголовки и кэширование.
Это почти всегда ускоряет отладку интеграций, авторизации, кэширования и ошибок API.
Но тут есть важное: HAR может содержать токены, cookie, личные данные. Его нельзя разбрасывать без маскировки.
Приватность и безопасность: как не превратить баг-репорт в утечку
Баг-репорты – коварная зона. Они живут в трекерах, пересылаются, попадают в экспорт, иногда – в внешние системы. Артефакты часто содержат:
email, телефон, адрес,
номера заказов,
токены авторизации,
cookie,
персональные данные клиентов,
внутренние URL и ключи.
Правило: всё, что не нужно для отладки, – скрываем или редактируем.
Примеры:
замазываем токены и cookie,
обрезаем персональные поля,
в логах заменяем значения на [REDACTED],
вместо полного номера заказа – последние 4 символа.
ИИ может помочь подготовить текстовое описание так, чтобы оно сохраняло смысл, но убирало чувствительное. Но «окончательное решение» всегда должно быть осторожным: лучше скрыть больше, чем утечь.
Сколько артефактов – достаточно?
Идеально – минимум, который закрывает неопределённость.
Практическая формула:
один скрин с контекстом или короткое видео,
плюс один диагностический артефакт (консоль/лог/ID запроса), если есть.
Если вы прикладываете больше – объясните, зачем:
«Скрин показывает UI, HAR показывает 500 на /confirm».
«Видео демонстрирует гонку при возврате, лог содержит stack trace».
Без объяснения «пачка файлов» превращается в загадку.
Именование и упаковка: маленькая дисциплина, большая скорость
Разработчик открывает артефакты в хаосе вкладок и файлов. Помогите ему:
Имена файлов:
2026-02-21_checkout_spinner_ios17_iphone13.mp4
В репорте:
«см. видео 00:05–00:20»
«см. лог строки 120–160»
«см. HAR запрос #14 /payments/confirm → 500»
Это простая гигиена. Она работает.
ИИ как «сжиматель сигнала»: превращаем артефакты в смысл