Responsive testing — проверка того, как интерфейс сохраняет смысл и управляемость при изменении доступного пространства. Важна не только красивая главная страница на телефоне. Пользователь должен читать длинный текст, открывать фильтр, исправлять ошибку формы и завершать действие при любом поддерживаемом размере окна.
Адаптивность включает расположение блоков, порядок контента, навигацию и состояния. Если карточки аккуратно перестроились в одну колонку, но кнопка оплаты оказалась под закреплённой панелью, интерфейс всё равно не выполняет задачу.
Viewport, разрешение и плотность пикселей
Viewport — область, в которой браузер размещает страницу. CSS-пиксели, используемые для layout, не равны физическим пикселям экрана один к одному. Поэтому разрешение устройства само по себе не описывает условия теста.
Фиксируйте размер viewport в CSS-пикселях, масштаб браузера, ориентацию и окружение. Проверка «на экране Full HD» без размера окна мало воспроизводима: окно может занимать половину дисплея, а масштаб — отличаться от стандартного.
Откуда брать размеры для проверки
Начните с требований и макетов, затем добавьте наиболее частые размеры из аналитики. После этого найдите breakpoints — границы, на которых интерфейс меняет структуру. Обычно они определяются условиями CSS, а не названием модели телефона.
Если меню перестраивается около 768 CSS-пикселей, проверьте 767, 768 и 769, затем несколько промежуточных ширин. Конкретная граница здесь лишь пример. Медленно меняя ширину окна, QA часто находит дефект между макетами, где ни один дизайнерский скриншот не показывает реальное поведение.
Что проверять в структуре страницы
- →Содержимое не перекрывает соседние блоки, важный текст не обрезается без способа прочитать его.
- →Порядок карточек и полей остаётся логичным после перестроения колонок.
- →Навигация сохраняет все необходимые действия; мобильное меню можно открыть и закрыть.
- →Закреплённые шапки, уведомления и нижние панели не закрывают контент и элементы управления.
- →Изображения сохраняют нужный смысл: обрезка не удаляет значимую часть инструкции или товара.
Проверяйте не только верх экрана. Ошибка часто появляется у длинной страницы, в подвале, открытом меню или последнем поле формы.
Контент как источник граничных случаев
Пустая карточка, длинное имя, цена с разрядами и перевод на другой язык создают разные нагрузки на layout. Подготовьте данные: короткий и длинный заголовок, непрерывную строку, несколько сообщений об ошибке, большое число элементов и отсутствие результата.
Для таблиц заранее уточните ожидаемый вариант: горизонтальная прокрутка внутри области, скрытие второстепенных колонок или преобразование строк в карточки. Сам факт прокрутки таблицы не доказывает дефект. Потерянный столбец с единственным действием без доступной альтернативы — гораздо более предметная проблема.
Почему ширины недостаточно
Высота окна влияет на диалоги, всплывающие меню и закреплённые кнопки. Сенсорный ввод меняет способ взаимодействия: действие, доступное только по hover, может оказаться недоступным. Экранная клавиатура сокращает видимую область и иногда меняет прокрутку.
Проверьте портретную и альбомную ориентации, если продукт их поддерживает, а также смену ориентации в процессе заполнения формы. Данные, выбранный фильтр и текущий шаг не должны теряться только из-за перестроения интерфейса, если требования не описывают особое поведение.
Увеличение и доступность
Проверяйте увеличение текста и browser zoom отдельно от выбора небольшого телефона. Пользователь может работать на большом мониторе с сильным увеличением. Содержимое должно перестраиваться без потери информации и действий.
WCAG 2.2, критерий 1.4.10 уровня AA, рассматривает для обычного вертикального контента ширину, эквивалентную 320 CSS-пикселям, без необходимости прокрутки в двух направлениях. Для содержимого, которому объективно нужен двумерный layout, предусмотрены исключения. Это полезная точка проверки, а не основание объявить весь сайт соответствующим WCAG.
Практический пример: фильтр каталога
Представь каталог, где боковая панель на узком экране превращается в выдвижной фильтр. Бизнес-результат — применить условия и получить соответствующие товары.
- 1.Открой каталог в широком окне, выбери два параметра и сузь окно через breakpoint. Ожидается сохранение выбора и понятный доступ к фильтру.
- 2.Открой фильтр на узком экране с длинными названиями. Ожидается прокрутка содержимого без перекрытия кнопок применения и сброса.
- 3.Сфокусируй текстовый поиск внутри панели на реальном телефоне. Ожидается доступ к результату и действиям при открытой клавиатуре.
- 4.Закрой панель и пройди страницу клавиатурой. Ожидается отсутствие фокуса на скрытых полях; после повторного открытия значения сохраняются.
- 5.Увеличь масштаб и повтори применение фильтра. Ожидается тот же набор товаров и доступная обратная связь.
Так один компонент проверяется как изменение состояния, а не серия неподвижных фотографий.
Эмуляция и реальные устройства
DevTools удобны для поиска границ и быстрого перебора размеров. Реальное устройство нужно для подтверждения сенсорного ввода, системной клавиатуры, динамической высоты браузерных панелей и поведения ОС. Сузить настольное окно полезно, но это не воспроизводит весь мобильный контекст.
Для автоматизации выбирайте несколько характерных размеров и состояния с высоким риском. Скриншотные проверки дополняйте действиями: открыть меню, применить фильтр, прочитать ошибку, дойти до кнопки.
Как оформлять дефекты
Укажите viewport, масштаб, устройство, браузер, тестовые данные и состояние компонента. Формулировка «верстка поехала» уступает описанию «при ширине 767 CSS-пикселей кнопка применения фильтра перекрыта клавиатурой, завершить выбор нельзя». Скриншот показывает расположение, короткая запись — последовательность, которая к нему привела.
Ошибки и рабочие выводы
Частые ошибки — проверять только размеры из макета, использовать исключительно идеальный короткий текст и оценивать страницу лишь в исходном состоянии. Ещё одна — автоматически запрещать любую горизонтальную прокрутку без понимания содержимого.
Сильная проверка адаптивности сочетает границы layout, реальные данные, взаимодействие, увеличение и подтверждение на устройствах. Критерий качества — сохранение задачи пользователя при изменении пространства.