Дмитрий Ланецкий – QA и разработка на одном языке: Репорты, уточнения, «не воспроизвёлось» (страница 5)
чистый кэш ↔ прогретый кэш
другой браузер ↔ текущий
регион RU ↔ EU (если применимо)
включённые эксперименты ↔ выключенные (если у вас есть доступ)
Если баг резко меняет частоту при щелчке – вы нашли след.
Важно: не делайте «пакетное шаманство» (включил всё и сразу). Меняем одну переменную, иначе вы узнаете только то, что мир сложный.
Репорт для плавающего бага: «набор наблюдений», а не один сценарий
Иногда невозможно дать шаги «1-2-3 и всегда ломается». Тогда репорт должен выглядеть как компактная карта местности:
Сценарий: что вы делали в целом.
Наблюдаемые условия: что чаще всего совпадает, когда баг появляется.
Что вы уже пробовали: какие переключатели проверены.
Как часто: частота по разным условиям.
Маркер времени: когда именно было, чтобы найти логи.
Артефакты: видео/логи/ID запросов.
То есть репорт становится не инструкцией, а отчётом о расследовании. И это нормально. Для плавающих багов это даже честнее.
Логи, ID запросов и «мне бы точку привязки»
Плавающий баг без привязки к логам – как преступление без отпечатков. Чтобы разработчик мог поднять события на сервере или в аналитике, ему нужны якоря:
точное время (с таймзоной),
идентификатор пользователя/сессии (если можно безопасно),
request ID / correlation ID (если продукт его показывает),
номер заказа/операции (с маскированием чувствительных данных),
crash report ID.
Если у вас нет доступа к логам, ваша роль – дать время и условия. Если доступ есть – репорт становится «золотым»: вы приносите не только симптом, но и след.
Видео лучше скрина: потому что время – половина бага
Скриншот фиксирует состояние. Плавающий баг часто живёт в переходе: кликаете – спиннер – двойной запрос – возврат – падение. Это динамика.
Поэтому:
видео 10–20 секунд часто полезнее пяти скриншотов;
если можно, включайте отображение касаний/кликов;
захватывайте момент до действия и после, иначе у разработчика не будет контекста.
ИИ здесь может помочь превратить видео в текст: выделить таймкоды, где что произошло, и превратить это в шаги.
Классы плавающих багов: самые частые биологические виды
Понимание «какой это зверь» помогает собирать нужные данные.
1) Сетевые/таймауты
Проявляются при медленной/нестабильной сети. Часто завязаны на повторные запросы, ретраи, несогласованность между клиентом и сервером.
Признаки: долго грузит, потом ошибка, иногда проходит со второй попытки.
2) Состояние/кэш
Проявляются только после определённой истории действий: «после выхода-входа», «после смены языка», «после добавления 20 товаров».
Признаки: лечится очисткой кэша/перезагрузкой/выходом из аккаунта.
3) Гонки (race conditions)
Проявляются при «быстрых» действиях или при переключении экранов/вкладок/фона.
Признаки: «если нажать быстро дважды», «если сразу назад», «если свернуть приложение во время загрузки».
4) Память/производительность
Проявляются на слабых устройствах, при нагреве, в фоне, после долгой работы.
Признаки: лаги, фризы, краши «out of memory».
5) Серверные нагрузки/время
Проявляются в определённые часы, при пиках.
Признаки: вечером хуже, утром лучше; корреляция с релизами/акциями.
Для каждого вида важен свой набор данных. Если вы хотя бы классифицировали зверя – вы уже не в тумане.
Мини-лаборатория QA: как собирать доказательства без специальных инструментов
Даже если вы не тестировщик, вы можете сделать три вещи, которые резко повышают ценность репорта:
Повторяемость в числах
10 попыток → сколько успехов/провалов.
Матрица условий
Wi-Fi vs LTE, VPN on/off, чистый кэш vs прогретый.
Три условия × десять попыток = уже маленькая статистика.
Временные метки
Записывайте точное время каждого проявления и добавляйте в репорт.
Разработчики будут вам благодарны, даже если не скажут.
Как ИИ помогает именно с плавающими багами
ИИ особенно хорош в трёх задачах:
Допрос с умом: он задаёт уточняющие вопросы по осям «состояние-окружение-время», а не просто «расскажите подробнее».
Построение гипотез: «похоже на гонку при возврате из фона» – как рабочая теория, которую можно проверить переключателями.
Превращение хаоса в отчёт: собирает наблюдения, группирует, формирует репорт «как для инженеров».
Важно держать границу: ИИ может предложить гипотезы, но мы честно помечаем их как гипотезы. Не выдаём предположения за факты. Так сохраняется доверие.
Артефакт: шаблон репорта для плавающего бага