Как проверить сайт в разных браузерах и что включить в задание подрядчику

Проверять нужно действия, а не только внешний вид

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

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

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

Такой подход помогает ограничить работу разумным объёмом. Требование «проверить во всех браузерах» невозможно принять: нет конечного списка версий, устройств и настроек. Вместо него подготовьте матрицу условий и набор пользовательских сценариев с ожидаемым результатом.

Откуда взять список браузеров для проверки

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

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

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

Согласуйте, какие версии проверяют полностью, где достаточно основных действий и какие устаревшие условия не входят в текущий объём. Исключения должны быть видны заказчику до приёмки. Фраза «у нас современный сайт» не объясняет, сможет ли клиент с рабочим ноутбуком оформить обращение.

Как составить матрицу без сотен случайных сочетаний

В строке матрицы указывают устройство или его класс, систему, браузер и фактическую версию проверки. Далее — сценарии, результат, ссылка на замечание и дата повторного просмотра. Одна запись «Chrome — работает» слишком коротка: неизвестно, что именно проверили и на какой платформе.

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

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

Укажите, что выполнялось на реальном устройстве, что — на удалённом устройстве сервиса тестирования, а что — в эмуляции. Эти результаты нельзя объединять одной отметкой «мобильный протестирован». У каждого способа свои ограничения, которые должны оставаться видны в акте приёмки.

Какие сценарии включить в обязательный набор

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

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

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

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

Чем эмуляция отличается от настоящего телефона

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

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

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

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

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

Как описать ошибку, чтобы разработчик её повторил

Начните с короткого наблюдения: «На iPhone в указанной версии Safari после выбора доставки кнопка закрыта клавиатурой». Затем укажите адрес, начальное состояние и последовательность действий. Ожидаемый и фактический результаты запишите отдельно. Это лучше, чем оценка «мобильная версия неудобная».

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

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

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

Как отличить блокирующую проблему от допустимого различия

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

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

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

Не назначайте одинаковый срок всем замечаниям. В отчёте разделите блокирующие ошибки, существенные неудобства и принятые отличия. Для каждого открытого пункта укажите решение: исправить до запуска, исправить отдельно к согласованной дате или принять с объяснением ограничения.

Что должно остаться после повторной проверки

После правок повторите исходные шаги в том же сочетании устройства и браузера. Если версия за время работы изменилась, запишите новую и объясните, можно ли ещё проверить первоначальную. Без этого отметка «исправлено» может относиться к другим условиям.

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

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

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

Как поставить задачу и поддерживать совместимость дальше

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

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

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

ШТАБ ИТ может помочь с проверкой и доработкой сайта. Сервис проверки адаптивности полезен для первичного просмотра расположения элементов на разных размерах, но интерактивные сценарии и совместимость с конкретными браузерами проверяют отдельно. Для начала приёмки подготовьте три главных действия клиента и список устройств, которыми он пользуется.