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