Как принять сайт у разработчика: проверка перед запуском
Принимать сайт лучше по согласованным требованиям и реальным действиям посетителя: найти услугу, отправить заявку, выбрать товар, оформить заказ. Красивой главной страницы недостаточно. До запуска нужно проверить содержимое, получение обращений, работу сотрудника в админке и передачу доступов.
С чего начать приёмку, если вы не разработчик?
Откройте задание и смету, по которым делали сайт. Из них должно быть понятно, что входит в сдаваемую версию: страницы, формы, каталог, интеграции, материалы. Если часть функций решили перенести, это стоит отметить отдельно. Иначе одна сторона будет проверять весь первоначальный замысел, а другая — только согласованный запуск.
Не нужно самостоятельно разбираться в коде. Для заказчика полезнее пройти обычный путь клиента и попробовать действия, которые сотрудник будет выполнять после сдачи. Вопрос «как я поменяю условия доставки?» иногда обнаруживает недоговорённость быстрее, чем просмотр всех макетов.
Если требования пока существуют в переписке, соберите их в один список вместе с исполнителем. Для будущих проектов поможет пример задания на сайт.
Какие сценарии проверить до запуска?
Начните с самых важных для бизнеса. У сайта услуг это выбор услуги и обращение. У магазина — поиск товара, выбор варианта, корзина и заказ. Для каждого сценария запишите ожидаемый результат и кто его подтверждает.
| Участок | Что проверить |
|---|---|
| Страницы и материалы | Услуги, цены, изображения, условия, контакты и ссылки соответствуют согласованным данным; нет временного текста |
| Формы | Понятны обязательные поля и ошибки; отправленное обращение получает ответственный сотрудник |
| Каталог и заказ | Выбранный вариант, количество и итог заказа передаются корректно; согласованные способы оплаты и доставки доступны |
| Телефон и компьютер | Можно прочитать условия, открыть меню, заполнить поля и завершить нужное действие на согласованных устройствах |
| Работа сотрудника | Назначенный пользователь может менять нужные материалы и понимает, где это делать |
| Интеграции | Данные появляются в нужной системе, а ошибки и порядок повторной обработки понятны |
Проверку оплаты нужно заранее согласовать с исполнителем: использовать тестовый режим сервиса или другой предусмотренный порядок. Случайный настоящий платёж без обсуждения не нужен. Также стоит отделить тестовые заказы и письма от обращений клиентов.
Допустим, компания запускает сайт с заявкой на замер. Форма показывает подтверждение, но уведомление уходит в личную почту разработчика. Внешне всё выглядит готовым, однако менеджер не получит клиента. Поэтому тест заканчивается проверкой сообщения у нужного сотрудника, а не надписью «Спасибо» на странице.
Как передать замечания, чтобы их исправили?
Удобнее вести общий список с адресом страницы, действием, фактическим и ожидаемым результатом. Например: «На телефоне в форме услуги после выбора даты кнопка оказывается за пределами экрана; отправить заявку не получается». К такому описанию полезно приложить снимок и указать устройство.
Замечания стоит разделить по влиянию на запуск. Невозможность оформить заказ требует другого решения, чем пожелание заменить фотографию. При этом новый раздел или функция, которых не было в задании, нуждаются в отдельном обсуждении объёма и срока.
После исправления нужно повторить проблемный сценарий и проверить связанные действия. Если меняли форму, важны не только её внешний вид, но и сохранение данных, доставка обращения и сообщения об ошибках.
Что должно остаться у компании после сдачи?
Управление нужными аккаунтами, доступы сотрудников, предусмотренные проектом файлы и инструкции, сведения о лицензиях и регулярных платежах. Полезно также узнать, как создаются резервные копии и к кому обращаться при сбое. Если эти вопросы оставлены на потом, первое изменение цены или продление домена может оказаться неожиданной задачей.
Перед запуском стороны должны понимать, что проверено, какие замечания закрыты и какие работы остаются. Если допустили запуск с ограничениями, их нужно перечислить и согласовать дальнейший порядок. Это помогает избежать ситуации, когда после открытия сайта каждый по-своему понимает слово «готово».
О дальнейших расходах есть отдельная статья о содержании сайта. Если требуется помощь с технической проверкой перед запуском или с дальнейшей работой, задачу можно обсудить с поддержкой WBStudio.