Как тестировать адаптивный дизайн
Что проверяют
Понимаете ли вы, что адаптивность проверяется не списком популярных телефонов, а диапазоном ширин и точками перелома вёрстки. Следом часто спрашивают, чем эмуляция в DevTools отличается от реального устройства и что из этого можно автоматизировать.
Как отвечать
Начните с источника требований: макеты на ключевые ширины и брейкпоинты из CSS (@media) или дизайн-системы. Дальше:
- границы: ширина ровно на брейкпоинте и на пиксель меньше, плюс промежуточные значения, где макета нет и вёрстка ломается чаще всего;
- что смотреть: нет горизонтальной прокрутки, текст не вылезает и не обрезается, меню сворачивается и разворачивается, картинки нужного размера приходят через
srcset, таблицы и модальные окна помещаются; - ориентация и клавиатура: поворот экрана, экранная клавиатура перекрывает поле ввода или закреплённую кнопку, скачки высоты из-за
100vhв мобильном Safari (лечится единицамиdvhиsvh); - масштаб и доступность: увеличение текста до 200% и ширина 320 CSS-пикселей без потери контента (критерии WCAG 1.4.4 и 1.4.10), достаточный размер зон нажатия;
- инструменты: режим устройства в Chrome DevTools для быстрой проверки, фермы BrowserStack или Sauce Labs и живые телефоны для финальной, Playwright с
setViewportSizeили готовыми профилямиdevicesдля автотестов, скриншотное сравнение черезtoHaveScreenshot, Percy или BackstopJS.
Обязательно проговорите предел эмуляции: DevTools меняет размер окна, плотность пикселей и user agent, но движок остаётся Blink. Поведение Safari на iPhone так не увидеть, для этого нужен WebKit в Playwright или реальное устройство.
Где спотыкаются
Проверяют три или четыре модели телефонов и считают дело сделанным. Ломается обычно ширина между брейкпоинтами, например 820 или 1100 пикселей.
Верят эмулятору целиком и не проверяют настоящий iOS, где по-своему ведут себя клавиатура, адресная строка и position: fixed.
Приплетают A/B-тестирование. Оно сравнивает, какой вариант лучше конвертирует, и к проверке корректности вёрстки отношения не имеет.