Экспертный журнал / Практика

Приёмка сайта: проверяем PASS/FAIL, а не впечатление «вроде работает»

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

Автор: Денис БогдановФормат: практический чек-листОбновлено: 17.09.2026

01 / принцип

Каждый критерий должен быть воспроизводимым

Фразы «адаптивно», «удобно», «SEO настроено» или «всё безопасно» нельзя принять однозначно. В приёмке нужен сценарий, среда, ожидаемый результат и доказательство.

Минимальная запись: URL → устройство/браузер → предусловие → действие → ожидаемый результат → факт → PASS / FAIL / BLOCKED → доказательство.

02 / области проверки

Что входит в короткую приёмку

Чек-лист охватывает критичные пользовательские и технические точки, которые можно проверить на конкретном релизе без подмены специализированных аудитов.

Сценарии

CTA, формы, ошибки, подтверждение результата и отсутствие тупиков.

Мобильная версия

320/360/390/768 px, document overflow, меню, фокус и перекрытия.

SEO

Canonical, robots, sitemap, redirects, metadata и structured data.

Аналитика

Имена событий, дубли, персональные данные и различимые переходы.

Безопасность

Короткая приёмочная проверка доступа, headers и backup/restore — не pentest.

Стабильность

Cache-control, CMS-свежесть, внешние интеграции и границы лабораторных метрик.

03 / примеры дефектов

Как выглядит проверяемый результат

Статус должен следовать из наблюдаемого факта. Если проверки нельзя завершить из-за отсутствия доступа или данных, это BLOCKED, а не условный PASS.

Статус	Ситуация	Как проверять
FAIL	Страница на 320 px визуально выглядит нормально, но document.scrollWidth шире viewport.	Проверять ширину документа инструментально и искать конкретный переполняющий компонент.
FAIL	Кнопка формы показывает успех, но повторный клик создаёт второй запрос.	Проверить блокировку повторной отправки и фактические network requests.
FAIL	В CI canonical корректный, а production отдаёт старый домен.	Проверять HTML через публичный ingress после deploy.
BLOCKED	Нужно подтвердить цель в Метрике, но нет доступа к интерфейсу счётчика.	Не ставить PASS по факту вызова JS; зафиксировать ограничение и отдельную проверку.

Где заканчивается короткий чек-лист

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

Отдельная профильная работа нужна для полноценного pentest, юридической оценки ПДн/cookie/оферты, формального WCAG/ГОСТ-аудита, нагрузочного тестирования, сложных интеграций и инфраструктуры.

Что должно остаться после приёмки

матрица PASS / FAIL / BLOCKED по согласованным критериям;
доказательства по каждому существенному дефекту;
список исключений и непроверенных областей;
перечень исправлений, влияющих на выпуск;
отдельный список улучшений, которые не блокируют запуск.

Следующий шаг

Принимать релиз по критериям, а не по ощущениям

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

Аудит и стратегия ↗Шаблон ТЗ