Приёмка сайта: какие критерии согласовать до разработки

Фраза «сайт должен работать быстро и без ошибок» звучит понятно, пока не начинается приёмка. Для заказчика ошибка — это неотправленная заявка или неудобное меню. Для разработчика — отклонение от согласованного требования. Если требований нет, стороны спорят о впечатлениях вместо проверки результата.

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

Начните с действий посетителя

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

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

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

Зафиксируйте окружения и допустимые различия

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

В критериях приёмки укажите:

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

Не требуйте полного совпадения каждого пикселя на разных экранах. Полезнее проверить, сохраняются ли смысл, порядок блоков и возможность выполнить целевое действие. Анимация может выглядеть по-разному, но форма, меню, поиск и оплата должны оставаться доступными.

Скорость задавайте метриками и условиями измерения

Оценка «загрузилось быстро» невоспроизводима. Для нового сайта можно использовать Core Web Vitals как один из ориентиров. В актуальном наборе три полевые метрики: LCP оценивает появление основного содержимого, INP — отзывчивость при взаимодействии, CLS — визуальную стабильность.

Категория good соответствует LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1. Google оценивает их по 75-му процентилю реальных просмотров. Поэтому единичный зелёный отчёт лабораторного теста ещё не доказывает, что порог выполняется у посетителей.

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

Доступность проверяют на полном пути

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

Если в требованиях указан уровень WCAG 2.2, важно определить область проверки и уровень соответствия. Стандарт рассматривает полную страницу, включая её адаптивные варианты. Если страница входит в последовательный процесс, например оформление заказа, соответствовать должен весь процесс, а не только первый экран.

Минимальный ручной набор для приёмки: пройти основные сценарии клавиатурой, проверить видимый фокус, порядок переходов, подписи полей, сообщения об ошибках, масштабирование текста и альтернативы для значимых изображений. Формальное заявление о соответствии WCAG нельзя делать по одному автоматическому отчёту.

Безопасность переводите из обещания в область проверки

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

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

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

Попросите доказательства, а не отметки «готово»

Критерий считается полезным, если два человека могут проверить его одинаково. Для каждого пункта задайте четыре поля:

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

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

Чек-лист до начала приёмки

Согласованы главные пользовательские сценарии и ожидаемый результат каждого.
Определены страницы, роли пользователей и тестовые данные.
Зафиксированы браузеры, устройства, ширины экрана и допустимые различия.
Выбраны шаблоны страниц и условия лабораторного замера скорости.
Разделены критерии до запуска и показатели, которые можно оценить только по полевым данным.
Указаны область и уровень проверки доступности.
Выбраны применимые требования безопасности и ответственные за эксплуатацию.
Описан формат отчёта, доказательств и карточки дефекта.
Определено, какие ошибки блокируют запуск, а какие можно исправить после него.
Назначены ответственные за финальное решение и повторную проверку исправлений.

Вопросы о приёмке нового сайта

Можно ли составить критерии, если дизайн ещё не готов?

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

Достаточно ли одного автоматического отчёта?

Нет. Автоматизация полезна для повторяемых проверок, но не заменяет прохождение сценариев, тесты на реальных устройствах и ручную оценку доступности. Набор доказательств должен соответствовать конкретному критерию.

Что VOWE проверяет при создании сайта?

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