Как проверить мобильную версию сайта: сценарии и журнал ошибок

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

Уменьшенная картинка страницы показывает только часть проблем — меню может перекрывать ссылку, клавиатура закрывать кнопку, а таблица уезжать за край уже после загрузки

Ниже — порядок самостоятельной проверки без автоматического сканера — на выходе получится журнал, по которому разработчик сможет повторить ошибку и проверить исправление

С какого сценария начать

Выберите один адрес и понятную цель — например, на странице мастерской найти условия приёма техники и скачать памятку о подготовке устройства

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

Запишите адрес, модель телефона, браузер, ориентацию и дату — если ошибка возникает только после перехода из мессенджера, отметьте и этот способ открытия

Для формы заранее согласуйте тестовую отправку с владельцем — проверка кнопки и получение обращения в почте или CRM являются разными результатами

Можно ли проверить всё на компьютере

Для первого прохода в Chrome откройте нужную страницу и подготовьте изменяемую область просмотра

1. Откройте меню с тремя точками → «Дополнительные инструменты» → «Инструменты разработчика» — альтернативы: Ctrl+Shift+I в Windows/Linux или Cmd+Option+I в macOS, как описано в инструкции Chrome
2. В верхней панели DevTools нажмите значок телефона и планшета — его подсказка называется Toggle device toolbar
3. В списке Dimensions выберите Responsive — появятся поля ширины и высоты
4. Для учебного прохода задайте ширину 360 и высоту 800 — затем перезагрузите страницу и повторите выбранный маршрут
5. Постепенно меняйте поле ширины, включая промежутки между макетами — записывайте значение, на котором появилась проблема

Поля задают размер области просмотра в CSS-пикселях — масштаб самого предпросмотра в DevTools помогает разместить её в окне, но не превращает этот тест в проверку физического телефона

Так удобно заметить переносы, тесную сетку и выход элементов за экран — но Chrome описывает Device Mode как приближение, а не запуск сайта на настоящем мобильном устройстве

Вернитесь к телефону для проверки касаний, экранной клавиатуры, ориентации и поведения браузера — особенно у фиксированных панелей, меню и полей ввода

Если второго телефона нет, честно запишите ограничение — результат «проверено в Chrome на Android» точнее, чем «работает на всех устройствах»

Как выбрать страницы и условия проверки

Перед началом подготовьте небольшой набор страниц — проверка только главной пропускает проблемы других шаблонов

Как выбрать страницы для проверки

Возьмите страницу основного предложения, материал с длинным текстом и страницу с важным действием — добавьте отдельный пример с таблицей или документом, если таких блоков нет на выбранных адресах

У одного шаблона полезно проверить два наполнения — обычное и сложное — например, короткое название услуги и длинный заголовок со списком условий

Страницы, на которые уже приходят посетители из поиска или рекламы, поставьте раньше редко используемых — если статистики нет, начните с основного маршрута бизнеса и запишите, что выбор пока сделан без данных посещений

Для учебной мастерской маршрут может выглядеть так: статья о неисправности → услуга ремонта → условия передачи устройства → памятка о подготовке — в проверке участвуют четыре разных результата, а не четыре одинаковых просмотра

Не обязательно исправлять всё сразу — задача первого прохода состоит в том, чтобы найти место, где посетитель теряет возможность продолжить путь

Как выбрать телефоны и условия

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

Без таких данных можно согласовать стартовый набор, например Chrome на доступном Android и Safari на доступном iPhone — это набор проверки, а не утверждение о составе вашей аудитории

Внутри каждого браузера пройдите страницу в обычной вертикальной ориентации, затем поверните телефон — при возможности добавьте устройство с меньшей доступной областью экрана

Отдельно запишите сеть — проблема на домашнем Wi-Fi и проблема в мобильной сети могут иметь разные причины — не меняйте одновременно устройство, браузер и подключение, если хотите понять, какое условие влияет на сбой

Для проверки нового посетителя используйте чистый сеанс браузера или согласованный тестовый профиль — выходить из рабочих аккаунтов и очищать все личные данные телефона ради этого не нужно

Что проверить на первом экране

Откройте страницу заново — сначала оцените, понятно ли, куда вы попали и что здесь можно сделать, затем дождитесь загрузки изображений и шрифта

Текст должен оставаться читаемым без постоянного увеличения страницы — заголовок не должен терять слова, а кнопка закрытия уведомления перекрывать основное действие

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

Отдельно проверьте баннер согласия и другие плавающие элементы — у посетителя с уже сохранённым выбором и у нового посетителя будут разные состояния

Как пройти содержимое и действие

Читайте страницу в обычном темпе — ищите не только обрезанные блоки, но и места, где непонятно, какая подпись относится к изображению или что означает ссылка «Подробнее»

У таблицы проверьте последний столбец и связь значений с заголовками — допустимая прокрутка внутри таблицы отличается от бокового смещения всей страницы

Откройте предусмотренный файл и убедитесь, что это нужная версия — видимая кнопка скачивания ещё не подтверждает содержание документа

У телефона или почты проверьте, какой адрес передаётся приложению — совершать реальный звонок или отправлять письмо для этого не обязательно

Если есть форма, проверьте подписи, обязательные поля и понятное сообщение об ошибке — затем по согласованному сценарию проверьте успешный путь и доставку результата

Какие состояния проверить дополнительно

Как проверить текст и увеличение

Прочитайте не только первый абзац, но и подписи, условия, примечания к цене и текст в кнопках — в этих местах чаще заметен слишком мелкий шрифт или потерянный перенос

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

Для проверки перестроения на компьютере можно использовать узкую область просмотра — W3C объясняет критерий Reflow на эквиваленте ширины 320 CSS-пикселей, с исключениями для содержимого, которому необходима двумерная компоновка

Это полезный ориентир для проверки текста, но один просмотр на такой ширине не подтверждает выполнение всех требований доступности — у таблицы отдельно проверяются доступ к данным и понятная прокрутка

Если увеличение отключено, не принимайте это за решение проблемы вёрстки — у посетителя должна сохраняться возможность прочитать содержание подходящим ему способом

Как проверить ввод и сообщения

Если на проверяемом сайте есть форма, сначала нажмите на каждое поле — подпись должна оставаться понятной после ввода, а экранная клавиатура не должна лишать доступа к следующему шагу

Попробуйте исправить неверное значение — сообщение должно объяснять, какое поле требует внимания и что именно исправить — общий красный цвет без пояснения оставляет посетителя в догадках

Проверьте длинное значение и перенос подсказки — важная часть ошибки не должна уходить за экран или накладываться на соседнее поле

При согласованной тестовой отправке дождитесь результата — отдельно отметьте состояние кнопки во время ожидания, сообщение на странице и факт получения обращения ответственным

Если интерфейс сообщил об успехе, а обращение не получено, оставьте задачу открытой — скриншот зелёной плашки не завершает проверку доставки

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

Пример полного прохода по сайту мастерской

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

Сначала он открывает услугу из статьи — проверяющий записывает адрес назначения и убеждается, что ссылка привела к нужному виду ремонта, а не в общий каталог

Затем посетитель ищет условия передачи устройства — важен не только читаемый текст, но и возможность добраться до него через меню или ссылку на раздел

На последнем шаге он открывает памятку — нужно проверить название и содержание файла, а затем возврат на страницу, чтобы продолжение сценария не зависело от случайно закрытой вкладки

В результате получилось две разные задачи — одна относится к поведению интерфейса, вторая к содержанию файла — фраза «исправить мобильную версию» скрыла бы это различие

В журнал не нужно добавлять неисправности, которых вы не наблюдали — работающие шаги тоже полезны как контрольные, особенно при повторной проверке после изменения общего меню

Как завершить этот учебный разбор

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

Для меню он повторяет переход к условиям, затем закрытие без перехода и обычную ссылку на другую страницу — этого достаточно, чтобы проверить затронутые соседние состояния, а не только один клик

Для памятки он открывает файл заново и сравнивает условия с текстом услуги — одинаковое имя скачивания не подтверждает, что внутри новая версия

В своей записи проверяющий указывает фактический результат и дату — например, «якорный переход завершён, условия видны, прокрутка доступна, повторено на исходном устройстве и соседней контрольной ширине»

Если устройство или часть маршрута недоступны, строка остаётся с ограничением — другой участник должен видеть, какую часть проверки ему ещё нужно выполнить

Что делать, если ошибка появляется не каждый раз

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

Если страница была открыта внутри другого приложения, сравните этот маршрут с открытием того же URL в обычном браузере — сохраните оба результата, не называя причину до диагностики

Для ошибки после возврата важна последовательность: откуда пришли, какое действие сделали, как вернулись — запись «после второго открытия» без этих шагов сложно повторить

Если воспроизведение пока неустойчивое, передайте его как наблюдение с условиями и записями — не закрывайте проблему только потому, что один повтор оказался удачным

Как оформить замечание, чтобы его не угадывали

Фраза «на мобильном всё съехало» не даёт исполнителю точки входа — нужны действия, наблюдение и ожидаемый результат

Учебный пример: «На странице условий ремонта в Chrome на Android открываю меню и выбираю “Документы” — меню остаётся поверх страницы, ссылка на памятку недоступна — ожидается переход к документам и закрытие панели»

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

Если проблема появилась после загрузки или поворота телефона, снимок первого экрана её не объяснит — допишите последовательность и состояние до ошибки

В журнале разделяйте наблюдение и гипотезу — «кнопка не реагирует» вы проверили, а «мешает прозрачный слой» ещё должен установить разработчик

Что исправлять первым

Сначала разберите сбои, которые прерывают выбранный маршрут: нельзя открыть раздел, прочитать условия или выполнить действие — затем визуальные недочёты, которые не мешают пройти сценарий

Порядок зависит от задачи страницы — у справочного материала обрезанная инструкция может быть существеннее неровного изображения в начале

Не назначайте полный редизайн по одному дефекту — локальный сбой меню или переполнение таблицы может потребовать отдельной frontend-доработки

Как назначить ответственного

Если ссылка ведёт на неверный документ, сначала уточните, кто владеет его содержанием — разработчик может заменить файл, но не должен самостоятельно придумывать новые условия услуги

Если текст не помещается в блок, проверьте обе стороны задачи — иногда нужно исправить вёрстку, иногда редактор действительно передал в кнопку весь абзац вместо названия действия

Проблему загрузки передавайте с условиями сети и замером, проблему поведения — с шагами и состоянием интерфейса — одному снимку трудно объяснить оба случая

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

Когда закончить первый проход

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

Это не означает, что весь сайт исследован — в отчёте перечислите проверенные адреса и отдельно оставшиеся шаблоны, браузеры или устройства

Если времени мало, такой ограниченный результат полезнее общего вывода «мобильная версия проверена» — следующему проверяющему будет понятно, что уже сделано и с чего продолжить

Чтобы договориться об объёме работ, используйте матрицу приёмки адаптивной вёрстки — она связывает шаблоны, состояния и способ проверки

Как принять исправление

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

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

Скорость проверяйте отдельным проходом — статья о медленной загрузке на телефоне поможет отделить сетевую задержку от долгой отрисовки и реакции на касание

На странице услуги вёрстки описан состав работ — к обсуждению конкретной доработки пригодится журнал с адресами и воспроизводимыми замечаниями

Скачать журнал мобильной проверки — с заполненным примером и полями для своего сценария

Готов ли журнал к передаче

Без JavaScript используйте те же пункты: условия, полный сценарий, воспроизводимые замечания и критерий приёмки — отметки не являются автоматическим тестом сайта

Источник проверен 31 октября 2026 года — план проверки и учебный журнал подготовлены редакцией KEIVO