Редизайн и запуск

Как проверить готовый сайт перед приёмкой

Приёмка сайта проверяет рабочие сценарии, данные и передачу управления. Используйте последовательный чек-лист вместо оценки только по внешнему виду.

Редакционная иллюстрация: Как проверить готовый сайт перед приёмкойПРИЁМКА САЙТА

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

Задания и журнал замечаний

Возьмите согласованные требования и превратите их в задания. У каждого должны быть ожидаемый результат и место, где он проверяется. Если смысл понятен только автору требования, уточните его до приёмки.

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

В учебном примере компания принимает заявки на изготовление деталей. Пользователь прикладывает чертёж, выбирает материал и оставляет контакт. Проверка заканчивается получением именно этого файла и параметров сотрудником. Надписи «отправлено» при потерянном вложении недостаточно.

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

Сложные данные и повторные действия

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

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

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

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

Телефон, масштаб и клавиатура

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

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

Названия полей должны объяснять назначение, а сообщения об ошибках использовать текст, а не только цвет. Контраст и размер элементов проверяют по согласованным критериям доступности. Ориентиры содержатся в официальном справочнике WCAG 2.2 W3C, проверенном 15 октября 2026 года. Несколько ручных действий не дают основания объявить полное соответствие стандарту: для такой оценки нужен определённый объём аудита.

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

Где искать подтверждение интеграции

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

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

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

Передача сотрудникам

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

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

Источники по теме

Материал обновлён в октябре 2026 года.

← Все материалы блога