Как проверить адаптивность собственного B2C-сайта на мобильных устройствах?

Приёмку адаптивной версии B2C-сайта нельзя считать успешной только потому, что сайт открывается на телефоне и страницы не искажены. Нужно убедиться, что пользователи могут рассмотреть товары, корректно взаимодействовать с сайтом и пройти весь процесс оформления заказа на целевых устройствах, на нужном языке и при соответствующих условиях сети. Нормальное масштабирование страницы ещё не означает, что мобильная версия готова обеспечить полноценный процесс покупки.

Приёмка должна включать подтверждения корректного отображения страниц, работы интерактивных элементов и результатов тестирования производительности. Проверка только скриншота главной страницы может не выявить такие проблемы, как невозможность выбрать вариант товара, перекрытие клавиатурой кнопки оплаты или выход цены за пределы экрана после смены языка. Даже если эти дефекты не мешают работе на компьютере, они могут препятствовать запуску мобильной версии.

Сначала определите объём приёмки, чтобы не ограничиваться проверкой на одном телефоне

Объём тестирования зависит от целевых рынков, источников переходов и способов оформления заказов. Если есть данные о посещаемости, в первую очередь проверьте наиболее распространённые устройства и браузеры. Если сайт новый и данных пока нет, начните с iOS Safari, Android Chrome и встроенных браузеров социальных платформ, которые планируется использовать. Эмулятор браузера удобен для быстрой проверки вёрстки, но не заменяет тестирование на реальном устройстве: только так можно проверить экранную клавиатуру, сенсорное управление, прокрутку и переход к оплате.

Как минимум следует проверить главную страницу, страницу категории или результатов поиска, страницу товара, корзину и страницу оформления заказа. Если реклама ведёт непосредственно на целевую страницу акции, её также нужно включить в приёмку. Необязательно проверять каждый товар на страницах одного типа, но следует выбрать примеры со сложными для вёрстки характеристиками: длинными названиями, несколькими вариантами, акционной ценой или отсутствием товара в наличии.

Для тестирования можно выбрать репрезентативные ширины, например 360, 390 и 430 CSS-пикселей, а также непрерывно изменять ширину рядом с точками переключения макета. Проверки нескольких фиксированных размеров из дизайн-макета недостаточно. В условия тестирования также следует включить альбомную ориентацию, увеличенный текст в браузере и языки с длинными текстами. Конкретный объём проверки нужно заранее зафиксировать в соглашении о приёмке, чтобы при сдаче не спорить о том, какие устройства входят в обязательства по адаптации.

При проверке вёрстки оценивайте полноту отображения контента, а не только его выравнивание

За исключением специально предусмотренных областей с горизонтальной прокруткой, например каруселей товаров, на странице не должно быть неожиданной горизонтальной прокрутки. Особое внимание уделите тому, не обрезаны ли название товара, цена, валюта, описание скидки, варианты товара и сведения о доставке, а также не теряются ли важные детали изображения из-за кадрирования. На мобильных устройствах порядок информации можно изменить, но нельзя скрывать сведения, влияющие на решение о покупке, ради более лаконичного оформления страницы.

Проверяйте в сочетании фиксированную панель покупки внизу экрана, верхнюю навигацию, уведомление о файлах Cookie и плавающее окно поддержки. То, что каждый элемент работает нормально по отдельности, не гарантирует, что при их одновременном отображении цена или кнопки действий не окажутся перекрыты. На устройствах с нижней безопасной областью также проверьте, что между кнопками и системной областью жестового управления достаточно места.

Сенсорное управление нужно проверять пальцем, а не имитировать щелчок мышью. Соседние кнопки выбора варианта, количества и закрытия не должны легко срабатывать при случайном касании. В качестве ориентира для важных элементов управления можно использовать размер около 44×44 CSS-пикселей, однако окончательную оценку следует делать с учётом расстояния между элементами и удобства управления на реальном устройстве. Навигация, фильтры и описание товара также не должны открываться только при наведении указателя мыши.

Пройдите путь покупателя и проверьте, что переходы между состояниями работают корректно

Тестирование процесса покупки следует начинать с реального источника перехода и продолжать до подтверждения заказа: открыть страницу товара, выбрать вариант, добавить товар в корзину, изменить количество, ввести адрес, выбрать доставку и способ оплаты. На каждом этапе проверяйте реакцию интерфейса, особенно при загрузке, ошибке, возврате на предыдущий шаг и повторном нажатии.

• Можно ли прокручивать и закрывать панель фильтров или окно выбора варианта и возвращается ли страница после закрытия в прежнее положение.
• Обновляются ли цена, наличие и изображения товара при смене варианта, и есть ли понятное уведомление для недоступных вариантов.
• Остаются ли видимыми текущее поле ввода и сообщение об ошибке после появления клавиатуры, не становится ли недоступной кнопка отправки.
• Сохраняются ли корзина, адрес и статус заказа после перехода к оплате и возврата, не приводит ли несколько последовательных нажатий к повторной отправке заказа.

При оформлении международных заказов также используйте примеры адресов, почтовых индексов и телефонных номеров для целевого рынка, чтобы проверить правила заполнения полей, отображение валюты, стоимости доставки и налогов. Оплату рекомендуется тестировать в песочнице платёжного сервиса. Если перед запуском требуется проверка в рабочей среде, её следует проводить по контролируемому плану. Сам по себе успешный переход на страницу оплаты не означает, что транзакция завершена.

Проверяйте скорость загрузки в условиях, близких к рабочей среде

Оценивать производительность только по первому впечатлению от просмотра сайта через офисный Wi-Fi недостаточно. В тестовой среде должны быть включены изображения товаров, шрифты, скрипты аналитики, рекламные теги и компоненты поддержки, запланированные к использованию после запуска. Фиксируйте устройство, условия сети, регион тестирования и состояние кэша. Иначе высокий балл, полученный на пустой странице, не будет отражать качество готового сайта.

Для выявления проблем можно использовать такие инструменты, как Lighthouse, и ориентироваться на хорошие пороговые значения основных веб-показателей: LCP — не более 2,5 секунды, INP — не более 200 миллисекунд, CLS — не более 0,1. Эти показатели оценивают соответственно отображение основного контента, отзывчивость интерфейса и стабильность макета. Реальные пользовательские данные оцениваются по 75-му процентилю; один локальный тест не позволяет заявлять, что весь сайт соответствует требованиям.

Если на новом сайте ещё нет данных о реальных пользователях, основанием для запуска должны стать многократные лабораторные тесты и записи взаимодействия на реальных устройствах. Мониторинг следует добавить после запуска. Важно оценивать не только баллы: проверьте, своевременно ли появляется изображение товара на первом экране, быстро ли становится доступной кнопка покупки и не смещает ли загрузка изображений кнопку, на которую уже нажимает пользователь. При обнаружении проблем выясните, связаны ли они с размером изображений, блокировкой скриптов или сторонними компонентами, вместо того чтобы просто отключать функции тестовой среды ради повышения оценки.

Превратите выявленные дефекты в чёткие критерии допуска к запуску

В отчёте о приёмке как минимум должны быть указаны адрес страницы, версия устройства и браузера, шаги для воспроизведения, снимок экрана или запись видео, ожидаемый результат и вывод повторной проверки после исправления. Между многоязычными версиями одной страницы, общими компонентами и платёжными плагинами могут быть взаимосвязи. После исправления нужно повторно проверить связанные сценарии, а не только отдельную страницу, на которой была обнаружена проблема.

Невозможность выбрать вариант товара или отправить заказ, перекрытие важных расходов и повторное создание заказа — дефекты, влияющие на корректность транзакции, — должны блокировать запуск. Для небольших расхождений в отступах или некритичных декоративных элементов можно согласовать срок исправления, но необходимо зафиксировать область их влияния. Основанием для итоговой приёмки должны быть успешное прохождение процесса покупки в согласованных условиях, устранение критических дефектов, а также наличие ответственных лиц и сроков по всем незакрытым вопросам, а не просто заявление «адаптивная версия готова».