Тестирование и приёмка сайта: как проверить работу разработчика

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

Тестирование и отладка: что делает разработчик до сдачи

Приёмка — последний этап проверки, а не единственный. До неё разработчик сам тестирует и отлаживает сайт, и от того, насколько честно это сделано, зависит длина списка замечаний. Стоит заранее спросить, что входит в его проверку.

• Функциональное тестирование. Формы, корзина, оплата, личный кабинет, поиск и фильтры проходят по основным сценариям, включая ошибки ввода.
• Проверка на устройствах и в браузерах. Вёрстка и кнопки работают на телефоне, планшете и компьютере в распространённых браузерах.
• Отладка ошибок. Найденные сбои воспроизводятся, исправляются и проверяются повторно; журнал ошибок сервера и консоль браузера после этого чистые.
• Повторная проверка после правок. Исправление в одном месте не должно ломать другое, поэтому после доработок основные сценарии проходят заново.
• Тестовая копия. Проверка идёт на отдельной копии сайта, а не на рабочем, чтобы клиенты не видели незаконченные изменения.

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

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

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

• Зафиксируйте, что именно сдаётся. Список страниц, функций и интеграций, а не «сайт готов».
• Договоритесь о сроке проверки. Разумный срок — от нескольких дней до двух недель, в зависимости от объёма.
• Определите, кто принимает. Один ответственный со стороны заказчика, который собирает замечания от остальных.
• Условьтесь, что считается ошибкой, а что новой задачей. Это снимает основную часть конфликтов на финише.
• Убедитесь, что сайт наполнен реальным содержимым. Проверять макет с текстом-рыбой бессмысленно: половина проблем проявляется именно на настоящих названиях и фотографиях.

Что проверять самому

1. Пройдите путь клиента с телефона. Найдите услугу или товар так, как это сделал бы посетитель: из меню, через поиск, с главной. Узнайте цену, оставьте заявку.
2. Отправьте тестовую заявку и убедитесь, что она дошла до ответственного, а не осталась в базе сайта. Проверьте папку со спамом.
3. Проверьте страницы с настоящими данными: длинное название, отсутствующая фотография, товар без цены, пустая категория.
4. Откройте сайт в двух браузерах и на планшете. Разница чаще всего вылезает в шапке, меню и формах.
5. Проверьте скорость на мобильном интернете, а не в офисе по проводу.
6. Пройдите оформление заказа целиком, если это магазин: до оплаты и после неё, включая письмо покупателю.
7. Проверьте админку своими руками: добавьте товар, отредактируйте страницу, загрузите фотографию. Если это неудобно вам, этим не будут пользоваться.
8. Посмотрите, как выглядит ссылка на сайт при отправке в мессенджер: заголовок, описание и картинка должны подставляться.

Что должно быть передано

Технический минимум перед запуском

Эти пункты проверяются быстро, а их отсутствие обходится дорого.

• Сайт открывается по защищённому протоколу, сертификат действует и продлевается автоматически.
• У сайта один основной адрес: варианты со слэшем и без, с префиксом и без ведут на него переадресацией.
• Индексация не закрыта настройкой, оставшейся с тестового сервера. Это самая частая и самая обидная ошибка запуска.
• Страница 404 существует, оформлена и отдаёт правильный код ответа.
• Карта сайта сформирована и передана в панели вебмастеров.
• Установлена аналитика, настроены цели на отправку формы и на звонок.
• Есть политика обработки персональных данных и непредустановленный чекбокс согласия во всех формах.
• Заголовки страниц и описания заполнены, а не продублированы по шаблону.
• Тестовый сервер закрыт от посторонних и от индексации.

Как оформлять замечания

Форма замечаний влияет на скорость правок не меньше, чем их количество. Работает такой формат:

• Один общий список, а не сообщения в трёх мессенджерах.
• По каждому пункту: адрес страницы, что ожидали увидеть, что увидели, устройство и браузер, скриншот.
• Замечания разделены на блокирующие запуск и остальные. Это позволяет запуститься вовремя.
• Формулировки конкретные. «Не работает» без деталей возвращается вопросом и стоит ещё одного круга переписки.
• Список передан одной порцией. Замечания, приходящие по одному в течение двух недель, растягивают приёмку и теряются.

Отдельно стоит отличать ошибку от пожелания. «Форма не отправляется с телефона» — ошибка. «Хочу другой порядок блоков на главной» — новая задача, которую нормально обсудить отдельно, включая сроки и стоимость.

Чего в приёмке обычно не хватает

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

Что делать после сдачи

1. Первую неделю ежедневно смотреть почту и аналитику: приходят ли заявки, растёт ли число ошибок.
2. Проверить, что цели в аналитике действительно срабатывают, а не показывают ноль.
3. Через несколько дней после запуска убедиться, что новые страницы попадают в индекс.
4. Сохранить резервную копию рабочего состояния до первых доработок.
5. Договориться, кто и в каком режиме исправляет ошибки, найденные после сдачи, и в какие сроки.

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

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