История одного баг-исследования: как одна цифра в DevTools может изменить всё
- Sarov+
- 13 hours ago
- 3 min read
Иногда самые «простые» баги оказываются самыми коварными. На первый взгляд — это мелкий визуальный дефект, который не влияет на функциональность. Но чем глубже начинаешь разбираться, тем больше понимаешь: проблема вовсе не в «косметике», а в логике отображения, окружении или даже в настройках устройства.
Эта история как раз о таком случае — расследовании бага в продукте с интеграцией Google Maps в CRM. Казалось бы, обычная задача: проверить отображение контактов на карте. Но всё оказалось чуть интереснее.
А узнать больше можно в нашем видео:
Старт тестирования и первый баг
Мы тестировали внутренний продукт — интеграцию Google Maps в CRM-систему. Его задача — отображать контакты пользователей прямо на карте вместе с маркерами и радиусами.
Мы начали с базового сценария:
создали контакт
заполнили FirstName и LastName
оставили адрес пустым
Как и ожидалось, карта была пустой — данных для геолокации нет.
Затем мы добавили ZIP-код, сохранили контакт и вернулись на карту. И вот здесь появился первый интересный момент: маркер отобразился, но при масштабировании карты начали проявляться странности — радиусы и лейблы «поехали». Они оставались функциональными, но визуально выглядели смещёнными и некорректными.
Баг, который «не воспроизводится»
Мы оформили баг-репорт, но получили классический ответ от разработчика:
«У меня не воспроизводится».
Это всегда означает одно — нужно найти точные условия, при которых проблема проявляется стабильно.
Мы начали проверку:
на другом девайсе баг не воспроизводится
на основном девайсе он воспроизводится стабильно
Значит, дело не в логике приложения, а в окружении.
Поиск причины: где ломается отображение
Дальше мы начали сравнивать параметры:
данные одинаковые
браузер одинаковый
масштаб страницы 100%
Но визуально результат отличался.
И тут стало понятно: проблема не в данных и не в API, а в том, как браузер рендерит интерфейс.
В веб-разработке «съехавшая верстка» почти всегда означает проблему с координатами или масштабированием.
Ключевая находка — device pixel ratio
Мы открыли DevTools и проверили параметр Windows Device Pixel Ratio.
Суть гипотезы была следующая:если данные одинаковые, браузер одинаковый, но визуальный результат разный — значит, отличается способ отрисовки пикселей на экране.
Всё сводилось к масштабированию дисплея:
при DPR = 1 каждый CSS-пиксель соответствует одному физическому пикселю
при DPR = 1.25 браузер начинает пересчитывать координаты и масштабировать элементы
И вот здесь и была причина:
на нашем устройстве DPR = 1.25
на другом устройстве DPR = 1
После изменения масштабирования системы до 100% баг исчез.
Но история на этом не закончилась
Интересный момент: даже при 125% масштабировании баг не всегда проявлялся.
После обычного обновления страницы всё начинало отображаться корректно.
Это привело к следующему выводу: проблема была не постоянной, а связанной с тем, когда именно карта и её элементы пересчитывали координаты.
Финальное понимание проблемы
После анализа сценариев стало понятно:
карта создаётся один раз
затем в неё динамически добавляются элементы
именно в момент динамического обновления происходит пересчёт координат
При DPR = 1 ошибка была незаметнаПри DPR = 1.25 — проявлялась как смещение лейблов
То есть масштабирование экрана не ломало систему, а лишь «подсвечивало» слабое место в логике отрисовки.
Заключение
Этот кейс хорошо показывает важную вещь в тестировании и разработке: если баг не воспроизводится — это не значит, что его нет. Это значит, что не найдены условия, в которых он проявляется.
Иногда причина скрывается не в коде, а в окружении:
настройках экрана
масштабировании
особенностях рендера браузера
или комбинации этих факторов
И в таких случаях одна строка в DevTools — например, device pixel ratio — может сэкономить часы споров и повторных проверок.
Так что если в следующий раз интерфейс «поехал» без очевидной причины — стоит начать именно с этого параметра.
Comments