Как принять сайт у разработчика: короткий чек-лист

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

Ниже — рабочий чек-лист для заказчика, не юридическая инструкция. Порядок сдачи конкретного проекта определяется его документами. Мои действующие условия работы можно посмотреть отдельно; здесь речь о том, как проверить сам сайт.

1. Сверьте страницы и содержание с заданием

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

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

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

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

2. Пройдите путь посетителя на компьютере и телефоне

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

Минимальный набор проверок выглядит так:

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

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

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

3. Убедитесь, что действие дошло до бизнеса

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

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

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

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

4. Соберите замечания и проверьте передачу результата

Хорошее замечание содержит адрес страницы, шаги, ожидаемый результат и фактическое поведение. Например: «На телефоне открыл услугу, нажал кнопку расчёта; ожидал форму, но ничего не произошло». Скриншот или короткая запись помогают воспроизвести проблему.

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

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