Приёмка маркетплейса после разработки — это не формальность и не «пробежаться по сайту». Это структурированная проверка, которая защищает вас от скрытых дефектов, недоделок и проблем с безопасностью. Большинство заказчиков подписывают акт сдачи-приёмки слишком рано — и потом месяцами устраняют баги за свой счёт. В этой статье — пошаговый порядок приёмки, конкретные критерии и чек-лист, который можно использовать сразу.
Почему приёмка маркетплейса — это отдельный процесс, а не «посмотреть глазами»
Маркетплейс — технически сложная система: несколько ролей пользователей (покупатель, продавец, администратор), платёжный шлюз, каталог с тысячами SKU, личные кабинеты, уведомления, аналитика. Визуальный осмотр закрывает от силы 10% возможных проблем.
Остальное — это функциональные сценарии, нагрузочное поведение, безопасность данных, корректность бизнес-логики. Именно поэтому приёмку нужно проводить по заранее согласованным критериям, а не по ощущениям. Если в договоре не прописаны критерии готовности — добейтесь их фиксации до начала тестирования.
Этап 1. Подготовка: что нужно получить от подрядчика до начала проверки
Прежде чем запускать тестирование, запросите у подрядчика следующий пакет документов и материалов:
- Техническое задание — именно по нему вы будете сверять реализацию.
- Тест-кейсы или сценарии тестирования — подрядчик должен предоставить их, если это предусмотрено договором.
- Доступы к тестовой среде: все роли (покупатель, продавец, модератор, администратор).
- Доступы к панели администратора и аналитике.
- Документацию на API, если планируется интеграция с внешними сервисами.
- Результаты внутреннего тестирования от QA-команды подрядчика.
Если подрядчик не может предоставить хотя бы тестовую среду и ТЗ — это тревожный сигнал. Подписывать акт в таких условиях не стоит.
Этап 2. Функциональная проверка по ролям
Проверяйте каждую роль отдельно, проходя сквозные сценарии от начала до конца.
Покупатель
- Регистрация и авторизация (включая восстановление пароля).
- Поиск товаров: полнотекстовый, фильтры, сортировка.
- Карточка товара: фото, описание, отзывы, наличие у разных продавцов.
- Корзина и оформление заказа: адрес доставки, выбор продавца, промокоды.
- Оплата: тестовые транзакции через платёжный шлюз (успех, отказ, возврат).
- Личный кабинет: история заказов, статусы, уведомления.
Продавец
- Регистрация магазина и прохождение верификации.
- Добавление и редактирование товаров: атрибуты, варианты, цены, остатки.
- Управление заказами: подтверждение, отгрузка, отмена.
- Финансовый кабинет: баланс, вывод средств, история выплат.
- Аналитика продаж.
Администратор
- Модерация товаров и магазинов.
- Управление категориями, атрибутами, тегами.
- Настройка комиссий и тарифов.
- Работа с жалобами и спорами.
- Отчёты и выгрузки данных.
Этап 3. Техническая и нагрузочная проверка
Функциональность — это половина дела. Вторая половина — как система ведёт себя под нагрузкой и насколько она устойчива.
| Параметр | Минимальный приемлемый показатель |
|---|---|
| Время загрузки главной страницы | до 2 секунд (LCP) |
| Время открытия карточки товара | до 1.5 секунды |
| Оформление заказа (весь флоу) | без ошибок при 50+ одновременных сессиях |
| Доступность платёжного шлюза | 100% в тестовых сценариях |
| Мобильная версия / адаптивность | корректная работа на iOS и Android |
Нагрузочное тестирование (например, через Apache JMeter или Яндекс.Танк) желательно провести до подписания акта, особенно если вы планируете маркетинговые запуски с трафиковыми пиками.
Этап 4. Проверка безопасности и соответствия требованиям
Маркетплейс работает с персональными данными и деньгами пользователей — здесь ошибки стоят дорого: от штрафов Роскомнадзора до репутационных потерь.
Минимальный чек-лист безопасности:
- HTTPS на всех страницах, корректный SSL-сертификат.
- Защита от SQL-инъекций и XSS (проверьте формы и параметры URL).
- Разграничение прав доступа: продавец не должен видеть данные другого продавца.
- Политика конфиденциальности и согласие на обработку персональных данных — в соответствии с 152-ФЗ.
- Хранение паролей в хешированном виде (не в открытом тексте).
- Логирование критических действий (оплата, вывод средств, смена пароля).
Этап 5. Фиксация дефектов и порядок их устранения
Все найденные проблемы нужно классифицировать по критичности и зафиксировать письменно — в баг-трекере или хотя бы в таблице с описанием, скриншотом и шагами воспроизведения.
Стандартная классификация дефектов:
- Критические (Blocker) — система не работает, оплата недоступна, данные теряются. Устраняются до подписания акта.
- Серьёзные (Major) — функция работает неправильно, но есть обходной путь. Устраняются в первом патче после запуска.
- Незначительные (Minor/Cosmetic) — визуальные несоответствия, опечатки. Могут быть внесены в план доработок.
Не подписывайте акт, пока не закрыты все Blocker-дефекты. Это ваш главный рычаг влияния на подрядчика.
Если вы ещё на стадии выбора исполнителя — обратите внимание на разработку маркетплейса под ключ от Aris.Web: в процесс уже включены внутреннее QA-тестирование и структурированная сдача проекта по этапам.
Часто задаваемые вопросы
Сколько времени занимает приёмка маркетплейса после разработки?
Для проекта средней сложности (до 10 000 SKU, 3 роли пользователей, 1–2 платёжных шлюза) полноценная приёмка занимает от 5 до 15 рабочих дней. Это включает функциональное тестирование, проверку безопасности, нагрузочные тесты и цикл исправления критических дефектов. Если подрядчик обещает сдать проект «за один день» — скорее всего, речь идёт только о демонстрации, а не о полноценной приёмке.
Нужен ли отдельный QA-специалист для приёмки или заказчик может справиться сам?
Заказчик может провести приёмку самостоятельно по функциональным сценариям — это реально и полезно, потому что вы лучше знаете бизнес-логику. Однако техническую часть (безопасность, нагрузка, корректность API) без профильного специалиста проверить сложно. Оптимальный вариант — заказчик тестирует пользовательские сценарии, независимый QA или технический консультант закрывает технический аудит.
Что делать, если подрядчик отказывается устранять дефекты, найденные при приёмке?
Сначала убедитесь, что дефект действительно входит в согласованное ТЗ — иногда заказчик добавляет требования постфактум. Если дефект зафиксирован в ТЗ, а подрядчик отказывается его исправлять — направьте письменную претензию со ссылкой на конкретный пункт договора и ТЗ. Не подписывайте акт приёмки до урегулирования ситуации: подписанный акт существенно ослабляет вашу позицию в любом споре.
Итог: приёмка — это инвестиция, а не бюрократия
Системная приёмка маркетплейса после разработки экономит деньги и нервы: вы запускаете платформу, которая реально работает, а не «в целом готова». Используйте этапы из этой статьи как рабочий чек-лист, фиксируйте всё письменно и не торопитесь с подписанием акта.
Если вы планируете запуск маркетплейса и хотите, чтобы разработка маркетплейса под ключ изначально включала прозрачную сдачу по этапам — обсудим ваш проект. Звоните: +7 (977) 326-69-09 или оставьте заявку на странице контактов.