Статья
Что проверить перед запуском сайта
Рабочий запуск проверяет не только страницы, но и весь путь заявки до человека, который должен на неё ответить.
Пройдите сайт как новый посетитель
Не начинайте приёмку с перечня экранов. Выберите несколько реалистичных задач: найти подходящую услугу, понять ограничения, сравнить варианты, отправить форму, позвонить с телефона. Проходите их без административной учётной записи и устных подсказок команды. Технически успешная отправка формы ещё не означает успех: уведомление должно прийти ответственному, данные — читаться, а посетитель — увидеть понятное подтверждение и срок следующего контакта. Зафиксируйте ожидаемый результат каждого маршрута до проверки.
Пять слоёв приёмки
- 01. СодержаниеНазвания, цены, телефоны, адреса, ограничения, орфография и юридические документы.
- 02. ИнтерфейсМеню, ссылки, состояния форм, клавиатура, фокус и читаемость на разных экранах.
- 03. ТехникаHTTPS, скорость ключевых страниц, страница ошибки, резервные копии и журнал ошибок.
- 04. ПоискЗаголовки, description, canonical, sitemap, robots и корректные адреса страниц.
- 05. ОперацииДоставка заявок, ответственный, резервный канал и порядок срочного исправления.
Проверьте разные условия, а не любимый браузер
Откройте ключевые страницы на небольшом телефоне, широком экране и при медленном соединении. Увеличьте текст, пройдите меню и форму клавиатурой, убедитесь, что у полей есть понятные подписи, ошибки не обозначены одним цветом, а активный элемент виден. Проверьте изображения и длинные реальные названия, а не только аккуратные тестовые строки. Ссылки на телефон и почту должны запускать ожидаемое действие. Если используются внешние карты, виджеты или расписание, предусмотрите понятный текст на случай их недоступности.
Пример: заявка дошла, но процесс не сработал
Перед запуском сайта сервисной компании тестировщик отправил запрос на вечерний выезд. Страница показала «Спасибо», письмо пришло на общий адрес, и формально форма работала. Однако этот ящик никто не проверял после шести часов, а клиент ожидал быстрый ответ. Команда добавила уведомление дежурному, явно указала рабочее время и предложила телефон для срочной ситуации. Второй тест выявил, что в письме не было выбранной услуги. Поле добавили в уведомление и CRM. Один сквозной сценарий обнаружил больше, чем повторное нажатие кнопки в административной панели.
Подготовьте первые дни после публикации
Сохраните предыдущую рабочую версию и способ быстро откатить критическую ошибку. Назначьте канал для сообщений, владельца контента и человека, принимающего технические решения. После публикации проверьте реальные события аналитики, доставку заявок и ошибки сервера, не собирая лишние персональные данные. Составьте короткий журнал изменений: что исправлено, кем и почему. Не откладывайте обновление контактов или условий до большого редизайна. Сайт начинает устаревать в день запуска, поэтому ответственность за поддержку — часть качества, а не последующая опция. В первые дни полезно ежедневно сверять количество обращений в интерфейсе, почте и CRM. Расхождение быстро обнаружит потерянный канал или повторную отправку. Потом частоту контроля можно снизить, оставив автоматическое уведомление о сбоях.
Частые вопросы
Нужно ли проверять все страницы вручную?
Критические маршруты — обязательно. Повторяемые технические проверки можно автоматизировать, но смысл и обработку заявки оценивает человек.
Кто принимает решение о запуске?
Владелец бизнеса подтверждает факты и процесс, разработчик — техническую готовность. У решения должен быть один ответственный.
Что можно исправить после публикации?
Некритичные детали — да. Ошибки контактов, форм, безопасности, индексации и обязательных документов должны быть закрыты заранее.