Как проверить сайт перед обращением к разработчику: практический чек-лист

Три уровня проверки: от внешнего до технического

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

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

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

Составьте список действий, которые посетитель выполняет на вашем сайте чаще всего. Для небольшого сайта в Санкт-Петербурге это обычно: открыть главную страницу, перейти в раздел «Услуги» или «О нас», найти контактные данные, отправить сообщение через форму обратной связи, позвонить по указанному номеру.

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

Как фиксировать результаты

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

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

Типичные ошибки самостоятельной диагностики

Частая ошибка — проверять сайт только в одном браузере и на одном компьютере. Если у вас стоит Chrome, а посетитель пользуется Safari или Яндекс.Браузером, поведение страницы может отличаться. По возможности откройте сайт в двух разных браузерах и на мобильном устройстве, чтобы увидеть, нет ли проблем, невидимых с вашего рабочего экрана.

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

Пример проверки: форма обратной связи

Представим, что вы проверяете форму обратной связи на сайте небольшой мастерской по ремонту мебели. Открываете страницу на компьютере, заполняете поля «Имя», «Телефон» и «Комментарий», нажимаете «Отправить». Ожидаемый результат: сообщение «Ваша заявка отправлена». Фактический результат: страница перезагружается, но сообщение не появляется, а в адресной строке виден код ошибки. Это сбой, и его стоит записать в таблицу.

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

Когда обращаться к специалисту

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

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