Приёмка сайта перед запуском: что проверить заказчику

Принимайте сценарии, которые нужны бизнесу

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

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

Пройдите путь нового посетителя

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

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

Проверьте удачный и неудачный ввод

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

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

Посмотрите сайт в разных условиях

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

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

Записывайте замечание так, чтобы его можно было повторить

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

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

Закройте проверку понятным решением

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

• Основные сценарии пройдены на согласованной версии, результат каждого записан.
• Исправления проверены повторно; открытые замечания и их влияние на запуск видны обеим сторонам.
• Назначены ответственный за выкладку и сотрудник, который проверит публичный сайт сразу после неё.
• Согласован порядок действий, если на публичном адресе основной сценарий не заработает.