Приёмка готового сайта начинается с согласованных требований и заканчивается подтверждением конкретных результатов. Красивой главной страницы и сообщения «Спасибо» после отправки формы для этого недостаточно: важно увидеть, что посетитель может выполнить задачу, а бизнес получает правильные данные.
Ниже — рабочий чек-лист владельца для проверки сайта перед запуском. Выберите сценарии своего проекта и заранее запишите ожидаемый результат каждого. Общий порядок работы от постановки задачи до публикации описан в статье об этапах разработки сайта.
Подготовьте версию, среду и тестовые данные
Попросите разработчика назвать адрес проверяемой версии и способ её идентификации: номер выпуска или дату сборки. Запишите дату проверки. Если во время приёмки сайт изменился, выясните, какие сценарии нужно пройти снова. Замечания к разным версиям трудно сопоставить.
До начала проверки подготовьте:
- Основания для сравнения. Актуальные требования, утверждённые макеты, список страниц и согласованное содержимое. Для спорного пункта должна находиться конкретная формулировка: что сайт обязан делать и при каких условиях.
- Рабочее место. Компьютер и настоящий телефон, браузеры из согласованного списка, обычный пользовательский режим без входа в админку. Модель устройства, версию браузера и размер окна записывайте вместе с замечаниями.
- Данные для прохода. Тестовую учётную запись, если она нужна, подготовленные товары или услуги и уникальную метку обращения, например «УЧЕБНЫЙ ТЕСТ ПРИЁМКИ А». Используйте принадлежащие вам тестовые контакты и вымышленные имена вместо данных клиентов.
- Место получения результата. Доступ к тестовой почте или соответствующему разделу CRM, а также к нужному счётчику аналитики. Разработчик должен объяснить, где искать запись и какой срок доставки предусмотрен.
- Безопасный маршрут теста. Подтверждение, что обращения не запускают работу менеджеров, отгрузку, платные SMS или другие настоящие операции. На рабочем домене заранее согласуйте тестовый маршрут и предупредите получателей.
Проверяйте только свой проект или среду, для которой вам разрешено тестирование. Отправлять заявки на чужие сайты ради проверки не нужно. Успешный проход в тестовой среде также не подтверждает настройки рабочего домена: после публикации потребуется согласованный контрольный проход на нём.
Если сценарий включает оплату, попросите специалиста показать, что подключён именно sandbox или тестовый магазин платёжного сервиса. Используйте тестовые реквизиты из его документации. Например, ЮKassa описывает тестовый магазин, специальные карты и отдельный адрес для тестовых уведомлений; настоящие карты в этом режиме использовать нельзя. Проверка должна обходиться без реальной оплаты и отгрузки. Переход на страницу «Оплата успешна» сам по себе не подтверждает платёж: сопоставьте тестовый статус в сервисе с состоянием заказа на сайте.
Запишите ожидаемый результат до нажатия кнопки
Для каждого важного сценария достаточно короткой записи: исходные условия, действия, ожидаемый результат, фактический результат и подтверждение. Условие «форма работает» замените описанием того, что должно произойти после её отправки.
Учебный пример согласованного требования: посетитель выбирает услугу, отправляет обращение с корректным контактом, видит подтверждение; в тестовой CRM появляется одна запись с выбранной услугой, контактом и текстом обращения. После принятия обращения сайт передаёт согласованное событие аналитики. Это пример для объяснения проверки, а не описание функций конкретного проекта Студии Вебирус.
Если ваш сайт отправляет письма вместо записи в CRM, ожидаемым результатом будет письмо в согласованном ящике. Если доставка происходит через очередь, учитывайте предусмотренное время и состояние ожидания. Не назначайте проекту интеграцию или срок, которых нет в требованиях.
Если ожидаемый результат неизвестен, пометьте пункт «Нужно уточнить» и согласуйте поведение. Галочка «Пройдено» в такой ситуации ничего не подтверждает.
Пройдите основной путь посетителя до результата у бизнеса
Начните с типичной входной страницы: это может быть страница услуги, карточка товара или лендинг рекламной кампании. Открывайте её прямой ссылкой в новой вкладке, чтобы не зависеть от уже пройденных страниц.
- Найдите нужное предложение. Пройдите меню, поиск или фильтр, если они входят в сценарий. Сверьте название, условия, доступность и цену с утверждённым содержимым. Запишите адрес страницы и выбранный вариант.
- Откройте целевое действие. Нажмите предусмотренную кнопку и убедитесь, что форма относится к нужной услуге или товару. В нашем учебном примере выбранная услуга должна сохраниться при переходе к обращению.
- Заполните форму подготовленными данными. Добавьте уникальную тестовую метку. Если предусмотрено вложение, используйте файл допустимого типа и размера. Зафиксируйте отправляемые значения; не помещайте пароли и настоящие клиентские данные в скриншоты.
- Отправьте один раз и наблюдайте состояние. Понятно ли, что запрос выполняется? Видно ли подтверждение или сообщение об ошибке? Соответствует ли текст тому, что действительно произошло? Запишите время отправки и номер обращения, если сайт его показывает.
- Проверьте получателя. Найдите запись по метке в CRM или письмо в тестовом ящике. Сопоставьте выбранную услугу, контакт, сообщение и вложение. Для примера с одной записью проверьте, что она не продублировалась. Сообщение на странице при отсутствии ожидаемой записи означает, что сценарий ещё не подтверждён.
- Проверьте связанное событие аналитики. Сверьте действие и название события с планом измерения. Проверка аналитики описана ниже: её результат фиксируется отдельно от доставки обращения.
Для магазина тот же принцип действует от выбора товара до тестового заказа: сверяйте состав, количество, согласованный расчёт стоимости и условия доставки. Успех, отказ оплаты и отмену проверяйте только в подготовленной тестовой среде. Не считайте возврат покупателя с платёжной страницы доказательством, что заказ оплачен.
Повторите путь для функций, которые действительно отличаются: например, отдельной формы с вложением или другого способа оформления. Если несколько страниц используют одну форму, технический проход можно объединить, но контекст каждой страницы всё равно нужно проверить: выбранный товар и получатель могут различаться.
Проверьте ошибки и отклонения от обычного пути
Обсудите ожидаемые состояния с разработчиком до проверки. Недоступность внешней системы пусть воспроизводит специалист в тестовой среде; отключать рабочую CRM или оплату ради эксперимента нельзя.
| Что сделать | Что наблюдать | Что зафиксировать |
|---|---|---|
| Отправить пустую форму | Понятно, какие обязательные поля нужно заполнить; сообщение об успехе не появляется | Поля и сообщения, скриншот; наличие неожиданной записи у получателя |
| Ввести заведомо неверный контакт, затем исправить | Ошибка объясняет допустимый ввод; корректное значение проходит по согласованным правилам | Введённое тестовое значение, текст ошибки, итог повторной попытки |
| Проверить согласованные форматы телефона | Допустимые номера принимаются, значение сохраняется правильно и без потери значимых символов | Значение до отправки и в полученной записи; не расширяйте список стран самостоятельно |
| Дважды быстро нажать отправку | Поведение соответствует договорённости о повторной отправке; для учебного требования не создаются два обращения | Число записей и отправленных событий, тестовая метка |
| Пройти согласованную имитацию сбоя доставки | Сайт показывает предусмотренное состояние: ошибку, ожидание или принятие в очередь; дальнейшая судьба обращения понятна | Сообщение на экране, статус записи и результат восстановления |
| Повторить действие после сбоя | Возможность повтора и сохранность введённых данных соответствуют требованиям; результат можно связать с первой попыткой | Шаги повтора, потерянные поля, итоговые записи |
| Получить пустой результат поиска или фильтра | Сайт объясняет отсутствие результатов и позволяет изменить условия | Запрос, фильтры, текст сообщения и путь возврата |
| Приложить недопустимый файл, если загрузка предусмотрена | Ограничение объясняется; запрещённый файл не принимается | Тип и размер тестового файла, сообщение; проверку содержимого выполняет специалист |
Отдельно попробуйте исправить ошибку и завершить сценарий. Проверка только отказа не показывает, сможет ли посетитель продолжить работу.
Проверьте телефон, управление и реальный контент
На настоящем телефоне повторите основной путь целиком. Откройте меню, форму и сообщения об ошибках; вызовите экранную клавиатуру и попробуйте дойти до кнопки отправки. Убедитесь, что клавиатура, закреплённые панели и уведомления не перекрывают нужные элементы. Проверьте длинное название, несколько строк текста и большие изображения из подготовленного набора. Записывайте экран, на котором проблема проявилась, и положение устройства.
По нажатию на номер телефона должен открываться набор именно согласованного номера; на email — нужный адрес; ссылка в мессенджер должна вести к правильному контакту. Для проверки достаточно увидеть адрес назначения или подготовленный экран: звонить и отправлять сообщение не требуется. Если приложения нет, проверьте предусмотренный запасной путь.
На компьютере пройдите меню и форму клавишами Tab и Shift+Tab, попробуйте активировать элементы с клавиатуры. Видно ли, какой элемент выбран? Можно ли выйти из открытого окна и продолжить путь? Увеличьте масштаб страницы до 200% и проверьте читаемость и доступ к действиям. Такие первичные проверки опираются на рекомендации W3C WAI Easy Checks. W3C прямо предупреждает: успешный результат быстрых проверок не подтверждает доступность сайта в целом.
Контент проверяйте по списку всех согласованных страниц, а не только по главной. Сверьте контакты, адреса, названия, цены и условия, сроки действия предложений, изображения и подписи. Откройте прикреплённые документы: правильны ли версия и содержимое, доступен ли файл? Найдите оставшиеся заглушки, пустые блоки и ссылки на тестовый домен.
Если управление контентом входит в объём, войдите под своей ролью, измените тестовую запись, сохраните и посмотрите результат на сайте. Проверка записи должна показать, что нужное действие доступно именно владельцу или редактору. Состав аккаунтов, материалов и полномочий разобран отдельно в статье о том, что передаётся после разработки сайта.
Проверьте адреса страниц и технический результат переходов
Возьмите согласованный список URL. Откройте страницы прямыми ссылками, пройдите переходы из меню и материалов, обновите внутреннюю страницу. Проверьте адрес в строке браузера и содержимое: правильная страница должна открываться и без предварительного посещения главной.
Если сайт заменяет прежний, пройдите согласованные старые адреса. Они должны вести к предусмотренным новым страницам; потеря конкретной услуги за переходом на главную — повод свериться с картой переноса. Владелец проверяет назначение перехода, специалист — код ответа и цепочку перенаправлений. Например, HTTP 301 означает постоянный перенос ресурса на другой адрес по RFC 9110, раздел 15.4.2.
Откройте заведомо несуществующий адрес своего сайта. Проверьте, что посетитель получает понятное сообщение и может вернуться к полезной странице. Попросите разработчика подтвердить код ответа: надпись «Страница не найдена» сама по себе не доказывает HTTP 404. Значение этого статуса определено в RFC 9110, раздел 15.5.5.
Для включённых в объём SEO-настроек запросите отдельный результат проверки рабочей версии: согласованные заголовки и описания, основные адреса страниц, правила индексации. Доступность страницы в браузере не подтверждает, что поисковик её проиндексировал. По такому просмотру также нельзя делать вывод о безопасности, нагрузочной устойчивости или доступности всего сайта: для этих требований нужны предусмотренные технические проверки и их результаты.
Убедитесь, что аналитика измеряет нужное действие
Значок установленного счётчика ещё не показывает, что цель работает. Сначала сверяйте владельца доступа, номер счётчика, проверяемый домен и согласованное значение события: клик по кнопке, принятое обращение и оплаченный заказ — разные результаты.
В Яндекс Метрике целевое событие может передаваться методом reachGoal; условия задаются при настройке цели. Это описано в документации целевых событий. Для нашего учебного требования о принятом обращении событие должно соответствовать этому результату, а не любому нажатию кнопки.
Выполните подготовленный тест и попросите специалиста показать событие в отладчике, затем проверьте его появление в отчёте. Для нового кода Метрики предусмотрен параметр _ym_debug=2; для прежнего кода документация описывает проверку через консоль с _ym_debug=1. Порядок, фильтры собственных визитов и возможные блокировки перечислены в инструкции проверки цели. Если данных нет, выясните причину; не отмечайте пункт успешным только по словам «счётчик стоит».
Запишите время, номер счётчика, событие и условия теста. Для выбранного учебного сценария отдельно проверьте, что ошибка ввода и повторное нажатие не создают лишних событий принятого обращения. Если проект предусматривает согласие на аналитику, проверьте согласованные состояния согласия и отказа. Имена, телефоны, email и текст обращений не используйте как параметры тестовых событий.
Оформите замечания и решение о готовности
У каждого замечания должны быть шаги воспроизведения и основание. Дефект — наблюдаемое расхождение с согласованным поведением. Новое пожелание — изменение этого поведения или добавление возможности. Если документы расходятся либо ожидаемый результат не определён, сначала уточните требование.
Учебная карточка дефекта: «После выбора услуги и отправки формы на телефоне название услуги отсутствует в тестовой CRM. Проверяемая сборка указана в журнале; устройство и браузер — в приложении. Шаги: открыть страницу услуги, перейти в форму, отправить обращение с меткой “УЧЕБНЫЙ ТЕСТ ПРИЁМКИ А”, найти запись по метке. Ожидалось: поле услуги заполнено согласно согласованному пункту. Получено: поле пустое. Подтверждение: скриншоты выбранной услуги и тестовой записи. Последствие: менеджер не понимает предмет обращения».
Просьба добавить в эту форму новый способ связи, которого нет в требованиях, оформляется отдельным пожеланием с оценкой объёма. Она не должна скрывать уже найденный дефект передачи услуги.
В журнале используйте понятные результаты: «Пройдено», «Дефект», «Не проверено — указана причина», «Нужно уточнить». Свяжите замечание с ответственным, способом исправления и повторной проверкой. После исправления подтвердите сам пункт и затронутый путь до результата у получателя; прежняя галочка на другой версии не переносится автоматически.
Решение о готовности принимает уполномоченный представитель заказчика по условиям проекта. Зафиксируйте принятую версию, выполненные проверки и оставшиеся ограничения. Неполученные обращения, неверные данные заказа и недоступный основной путь требуют разрешения до того, как вы назовёте соответствующий сценарий готовым. Допустимые замечания оставляйте только с явным решением владельца и порядком их устранения.
При заказе разработки сайта под ключ критерии и формат приёмки полезно согласовать до начала работ. После выпуска регулярные изменения и новые проверки можно организовать через техническую поддержку сайтов, отдельно определив её объём и порядок приёма задач.
