Принимать сайт удобнее по согласованным действиям и результатам. Просмотр главной страницы показывает внешний вид, но не подтверждает доставку заявки, работу редактора, доступность на телефоне или готовность к публикации на основном домене.
Начните с перечня требований и определите, чем подтвердите каждое. Ниже — рабочий чек-лист для заказчика: его нужно адаптировать к своему проекту, добавить отсутствующие проверки и отдельно назвать то, что не входило в проверку. Он не заменяет аудит безопасности, полную оценку доступности или договорные условия приёмки.
Зафиксируйте версию и условия
Запишите адрес окружения, версию сборки или иной однозначный идентификатор результата, дату, браузеры, устройства, языки и роли проверяющих. Укажите источник требований: согласованное ТЗ, макеты, карта страниц и перечень интеграций. Если требование звучит как «удобно» или «быстро», сначала уточните критерии приёмки.
Разделите проверку тестового окружения и проверку после релиза. Настройки домена, реальные интеграции и ограничения поисковых роботов могут различаться. Успешная проверка локальной сборки не подтверждает автоматически работу основного сайта.
Для форм и интеграций заранее согласуйте синтетические данные, место их приёма и ответственного. Не отправляйте пробные обращения в рабочий поток без разрешения. Настройки production не меняют только ради того, чтобы пройти пункт чек-листа.
Как отмечать результат
Используйте четыре состояния. Pass — подтверждено: ожидаемый результат получен в указанных условиях и есть доказательство. Fail — расхождение: результат не совпал с согласованным. Не проверено: отсутствуют данные, доступ или выполненный сценарий. Не применимо: пункт не относится к проекту, и основание записано.
Не заменяйте отсутствие проверки отметкой pass. Чужой скриншот, устное обещание или работавшая раньше версия не доказывают состояние текущего выпуска. Не применимо тоже требует объяснения: например, «личный кабинет не входит в согласованный состав».
Чек-лист перед запуском
Скопируйте таблицу и добавьте колонки «результат», «доказательство», «ответственный» и «следующая проверка». Все строки изначально не проверены; в этой статье нет результатов вашего проекта.
| ID / проверка | Что выполнить | Условие pass |
|---|---|---|
| P01 / основной сценарий | Пройти путь от страницы входа до целевого действия без подсказок автора | Нужная информация найдена, следующий шаг доступен, согласованный результат получен |
| P02 / состав страниц | Сверить страницы, языки, документы и переходы с утверждённой картой | Обязательные материалы на месте, ссылки ведут к соответствующим версиям |
| P03 / мобильный интерфейс | Пройти важные сценарии на согласованных экранах, открыть меню и форму | Контент и кнопки доступны, ничего не обрезано, прокрутка не мешает действию |
| P04 / клавиатура и подписи | Пройти навигацию и форму клавиатурой, проверить видимый фокус, названия и ошибки | Контролы понятны и доступны в согласованном сценарии, фокус не теряется |
| P05 / заявка | Выполнить разрешённую тестовую отправку и найти результат у получателя | Поля, назначение и доступ к обработке соответствуют требованиям |
| P06 / ошибки формы | Проверить неверные данные, отказ и согласованный повтор | Ошибка понятна, исправление возможно, текст и обращения не теряются по согласованным правилам |
| P07 / CMS | Выполнить типовые операции под ролью редактора | Изменения сохранены и опубликованы в нужном месте, ограничения соответствуют договорённости |
| P08 / интеграции | Сверить данные и состояния источника, промежуточных систем и получателя | Подтверждены результат обмена и поведение при выбранных сбоях |
| P09 / содержимое | Проверить реальные тексты, изображения, файлы, контакты и факты | Нет несогласованных заглушек, устаревших файлов и неподтверждённых утверждений |
| P10 / поисковые настройки | Сверить статусы, canonical, sitemap, ограничения и карту переходов при редизайне | Настройки соответствуют назначению страниц и окружению |
| P11 / скорость | Измерить согласованные страницы по зафиксированному протоколу | Согласованные показатели соблюдены либо отклонения оформлены решением |
| P12 / передача и восстановление | Проверить права, исходники, инструкцию и согласованный сценарий восстановления | Заказчик может продолжить управление, а результат восстановления проверен в разрешённом окружении |
Один пункт может требовать нескольких сценариев. Например, P05 для разных форм, языков и получателей следует разнести на отдельные записи. Если проверки выполнялись только на одном шаблоне, не распространяйте pass на все страницы без основания.
Проверяйте мобильную версию действием
Откройте меню на низком экране, дойдите до последней ссылки, заполните длинное описание и вызовите ошибку формы. Проверьте, что кнопка остаётся доступной, а сообщение не скрыто под фиксированной шапкой. Сравните несколько размеров и хотя бы те реальные устройства, которые включены в условия проекта.
Отсутствие горизонтальной прокрутки не доказывает, что всё поместилось: содержимое может быть обрезано стилями. Проверьте края заголовков, полей и кнопок. Для широких таблиц допустим согласованный способ отдельной прокрутки, при котором читаются все данные. О границах такой проверки — в термине «Адаптивный сайт».
Клавиатура, подписи и фокус относятся к доступности, но быстрый осмотр не подтверждает её полностью. W3C прямо ограничивает область своих начальных проверок; для общего заключения требуется более полная оценка. Начальные проверки W3C.
Проследите форму до результата
Не останавливайтесь на сообщении «отправлено». Найдите синтетическое обращение в нужной системе и попросите будущего ответственного подтвердить поля и следующий шаг. Если есть очередь, отделите принятые данные от завершённой обработки.
При ошибке сохраните время, безопасный идентификатор и последний подтверждённый этап. Не выкладывайте полный журнал с контактами или токенами в общую задачу. Для поиска причины используйте дерево диагностики заявки.
Аналитику принимайте отдельно: согласуйте событие, счётчик, период и правила исключения внутренних тестов. Клик, приём и обработка обращения — разные результаты. Задержка отчёта или отсутствие доступа не должны записываться как нулевой показатель.
Дайте редактору выполнить работу самостоятельно
Попросите будущего редактора изменить материал, создать страницу по шаблону, заменить файл и проверить результат без действий разработчика за него. Используйте реальные по структуре, но безопасные данные и согласованную роль. Возможности администратора не доказывают права редактора.
Проверьте также, что делать при ошибке и когда требуется помощь специалиста. Пять операций и бланк демонстрации есть в уроке о требованиях к CMS. Инструкция должна соответствовать переданной версии, а не прежнему виду панели управления.
Разделите поисковые настройки тестового и основного сайта
Для публичных страниц, предназначенных для поиска, проверьте, что ограничения тестовой версии не перенесены в релиз. При этом не удаляйте все запреты без разбора: черновики и закрытые разделы имеют другое назначение. Сначала согласуйте карту того, что должно быть доступно роботам и пользователям.
Правило noindex и robots.txt выполняют разные задачи. Google должен иметь возможность прочитать страницу, чтобы увидеть noindex; запрет обхода может помешать этому. Noindex не является способом ограничения доступа к секретам. Документация Google.
Проверьте основные URL, ссылки и sitemap на опубликованном окружении после разрешённого релиза. При редизайне используйте карту переноса адресов. Корректные настройки не гарантируют немедленную индексацию или определённую позицию: состояние поиска наблюдают отдельно.
Принимайте передачу как отдельный результат
Сверьте согласованный перечень: домен и DNS, хостинг, репозиторий, CMS, аналитика, интеграции, файлы и документация. Важно не только получить приглашение, но и проверить достаточность прав для нужной работы. Доступы передаются согласованным защищённым способом, а не публикуются в отчёте.
Для резервной копии определите состав, место хранения, ответственного и способ восстановления. Наличие архива не доказывает, что из него можно восстановить нужную версию. Контрольный сценарий выполняют в разрешённом окружении, не перезаписывая рабочие данные ради проверки.
Назовите ответственного за первый период после релиза: кто проверяет обращения, замечает сбои и принимает решения об исправлениях. Границы сопровождения и его состав фиксируют отдельно.
Оформите дефекты и решение о запуске
Каждое расхождение запишите карточкой: ID требования, версия, условия, шаги, ожидаемый и фактический результат, доказательство, влияние и следующий шаг. После исправления повторите исходную проверку и связанные сценарии, которых могло коснуться изменение.
Решение о запуске принимает ответственная сторона по согласованным правилам. Не рассчитывайте его автоматически по проценту зелёных пунктов: одна потерянная заявка может быть важнее нескольких визуальных замечаний. Для принятого ограничения нужны основание, последствия, ответственный и срок пересмотра; не называйте его исправленным дефектом.
Для сайта под ключ согласуйте проверки ещё при определении состава работ. Тогда приёмка подтверждает ожидаемый результат, а открытые вопросы обнаруживаются до даты публикации.
Заполните протокол
Используйте интерактивный чек-лист приёмки: отметьте результаты, добавьте доказательства и скачайте протокол. Инструмент не проверяет сайт автоматически и не принимает решение о запуске.
Для практики пройдите урок приёмки сайта: заполните сценарии, оформите дефекты и подготовьте решение по повторной проверке.
Проверки защищённого соединения собраны в термине SSL/TLS: адреса, ресурсы, продление и границы того, что подтверждает сертификат.
Проверьте robots.txt и его отличие от noindex на рабочем окружении. Зафиксируйте ожидаемые правила для публичных и служебных URL, не снимая ограничения без разбора.
Краткое определение и карточка сценария собраны в термине «приёмка сайта»: используйте их, чтобы отделять подтверждённый результат от непроверенных условий.