ТЗ для тестировщиков модуля маркетплейса (любой на ваш выбор) в формате, пригодном для тест-плана и набора тест-кейсов. ## 1) Цель и границы тестирования ### Цель Проверить, что маркетплейс: * корректно показывает витрину товаров/услуг; * обеспечивает поиск/фильтрацию/сортировку; * корректно ведёт пользователя по сценарию покупки (или заявки) до финального статуса; * корректно обрабатывает оплату/неоплату/отмену; * корректно работает для ролей: гость/покупатель/продавец/админ; * защищён от типовых уязвимостей и не ломает основные пользовательские потоки. ### Вне скоупа (если не оговорено отдельно) * контентная модерация вне интерфейса админки; * внешние интеграции, не влияющие на пользовательский флоу (аналитика, пиксели), кроме критических ошибок. --- ## 2) Термины и сущности Товар/услуга (Listing): карточка предложения продавца. Категория: группировка предложений (например: редактура/обложки/продвижение — уточнить по факту). Продавец: пользователь, имеющий право создавать предложения. Покупатель: пользователь, который оформляет заказ/заявку. Заказ / Сделка: сущность, фиксирующая покупку/заявку. Оплата: внешний платежный провайдер (ЮKassa/иное). Статусы: * listing: черновик/на модерации/активно/скрыто/отклонено/архив (уточнить) * order: создан/ожидает оплату/оплачен/в работе/выполнен/отменен/возврат (уточнить) --- ## 3) Окружения и доступы ### Окружения * Prod: zelluloza.ru * Stage/Dev: (указать URL стенда, если есть) ### Роли/учетки для теста (обязательное) 1. Гость (неавторизован) 2. Покупатель (обычный пользователь) 3. Продавец (имеет кабинет продавца/раздел “мои услуги”) 4. Админ/модератор (может модерировать листинги и управлять спорными заказами) ### Тестовые данные Нужно иметь минимум: * 30+ листингов, чтобы проверить пагинацию/сортировки * несколько категорий (3–5) * листинги с разной ценой (в т.ч. минимальная/максимальная), разной валютой (если есть), разным типом (товар/услуга), разной доступностью * листинги с медиа (1 фото, много фото, без фото) * листинг со “сломанными” данными для негативных тестов (например, очень длинное название, спецсимволы) --- ## 4) Функциональные требования и критерии приемки ### 4.1 Витрина / список предложений FR-MP-01 Страница /marketplace/ открывается без ошибок (200), корректно рендерится на desktop/mobile. FR-MP-02 На странице списка отображаются: * название * цена/единица (если есть) * превью/обложка * продавец (ник/ссылка) * рейтинг/отзывы (если есть) * метки (хит/скидка/новое — если есть) FR-MP-03 Пагинация работает: переход по страницам, сохранение фильтров, корректный счетчик (если есть). FR-MP-04 Пустая выдача (нет результатов) показывает понятное сообщение и кнопку сброса фильтров. ### 4.2 Поиск, фильтры, сортировка FR-MP-10 Поиск по ключевым словам: * учитывает морфологию/частичные совпадения (если заявлено) * экранирует спецсимволы * не падает на длинной строке FR-MP-11 Фильтры (уточнить по факту): категория, цена (от/до), тип, рейтинг, доступность, “только с отзывами”, etc. FR-MP-12 Сортировка: по цене, по популярности, по рейтингу, по новизне (что есть) и корректная стабильность сортировки. FR-MP-13 Сохранение состояния: фильтры/поиск/страница сохраняются в URL (желательно) и корректно восстанавливаются при обновлении. ### 4.3 Карточка предложения FR-MP-20 Карточка открывается из списка и по прямой ссылке. FR-MP-21 Отображает полный набор данных: описание, условия, состав, сроки/доставка (если есть), FAQ, отзывы, продавец, цена, медиа. FR-MP-22 Защита: нельзя открыть скрытый/удаленный листинг (должен быть 404/“недоступно”), кроме админа/владельца. FR-MP-23 Действие CTA: * “Купить” (если мгновенная покупка) * или “Оформить заявку/Связаться” (если услуга по заявке) — ведет в корректный поток. ### 4.4 Оформление заказа/заявки FR-MP-30 Авторизация: гость при попытке заказать попадает на логин/регистрацию, после успешного логина возвращается в поток заказа. FR-MP-31 Создание заказа: * обязательные поля валидируются * цена/итог считаются на сервере (анти-фрод) * нельзя подменить price/listing_id в запросе FR-MP-32 Статус заказа меняется корректно по событиям (создан ? ожидает оплату ? оплачен/отменен и т.д.). FR-MP-33 История заказа доступна покупателю и продавцу (каждому своя видимость). FR-MP-34 Уведомления (если есть): покупателю/продавцу о создании/оплате/статусе. ### 4.5 Оплата (если есть онлайн-платеж) FR-MP-40 Создание платежа: * сумма фиксируется на сервере * повторная оплата одного заказа корректно обрабатывается (идемпотентность) FR-MP-41 Колбэки/вебхуки платежки: * переводят заказ в “оплачен” * повторный вебхук не ломает статус * неверная подпись/неизвестный платеж отклоняется FR-MP-42 Отмена/ошибка оплаты: * пользователь возвращается с понятным статусом * заказ остается “ожидает оплату” или “отменен” по правилам FR-MP-43 Возврат (если реализован): корректный статус, доступность функционала после возврата. ### 4.6 Кабинет продавца FR-MP-50 Продавец может создать листинг (черновик/публикация): * валидации полей * загрузка изображений/файлов * предпросмотр FR-MP-51 Редактирование/снятие с публикации/архивирование листинга. FR-MP-52 Нельзя редактировать чужой листинг (403/ошибка). FR-MP-53 Управление заказами: смена статуса “в работе/выполнен”, комментарии/чат (если есть). ### 4.7 Админка/модерация (если есть) FR-MP-60 Список листингов на модерации, решение approve/reject с причиной. FR-MP-61 Логи действий (кто/когда) для критичных операций. FR-MP-62 Управление спорными заказами/возвратами (если предусмотрено). ### 4.8 Отзывы/рейтинг (если есть) FR-MP-70 Оставить отзыв может только покупатель после завершенного заказа. FR-MP-71 Нельзя накрутить отзывами через прямой POST, нельзя оставить второй отзыв на тот же заказ (если ограничение есть). FR-MP-72 Модерация отзывов (если есть). --- ## 5) Нефункциональные требования (обязательная проверка) ### 5.1 Безопасность * CSRF для форм/POST (или иной механизм защиты) * Авторизация/ACL на все действия (создать/редактировать/заказ/оплата) * XSS: экранирование описаний/отзывов/полей * SQLi: параметры фильтров/поиска * Анти-фрод: цена/кол-во/скидки пересчитываются сервером; нельзя подменить итог * Rate limit на поиск/создание заказа (если есть) ### 5.2 Производительность * /marketplace/ и карточка: TTFB и полная загрузка в разумных пределах (зафиксируйте KPI, например: TTFB < 800ms на стенде) * Пагинация/фильтры не вызывают N+1 и не “кладут” БД при массовом клике ### 5.3 UX/доступность * Mobile-верстка не ломается * Кнопки/поля доступны с клавиатуры * Ошибки валидации понятны --- ## 6) Матрица тестирования (что проверить обязательно) ### 6.1 Smoke (каждый релиз) 1. Открывается /marketplace/ 2. Открывается карточка листинга 3. Поиск дает результаты 4. Фильтр по категории работает 5. Авторизация в потоке заказа (гость ? логин ? возврат) 6. Создание заказа 7. Оплата (успех) или создание заявки (если без оплаты) 8. Отображение заказа в кабинете покупателя 9. Отображение заказа в кабинете продавца ### 6.2 Регресс (перед крупными релизами) * все разделы 4.1–4.8 + безопасность 5.1 --- ## 7) Детальные тест-кейсы (скелет для тестировщиков) Ниже — “максимально прикладной” список. Тестировщики заносят в TestRail/Jira с конкретными URL/полями. ### 7.1 Витрина * TC-MP-LIST-001: открыть /marketplace/ (desktop) ? 200, список виден * TC-MP-LIST-002: открыть (mobile) ? адаптив корректен * TC-MP-LIST-003: пагинация: перейти на стр.2 ? элементы меняются, фильтры сохраняются * TC-MP-LIST-004: пустая выдача (фильтр “цена от очень большой”) ? сообщение “ничего не найдено”, кнопка “сбросить” ### 7.2 Поиск/фильтры/сортировки * TC-MP-SRCH-001: поиск по точному названию ? 1+ результатов * TC-MP-SRCH-002: поиск по части слова ? ожидаемое поведение (уточнить) * TC-MP-SRCH-003: поиск со спецсимволами “'<>%_ ? нет падения, нет XSS * TC-MP-FLT-001: фильтр по кат егории ? только нужная категория * TC-MP-FLT-002: фильтр цена от/до (границы) ? корректная выдача * TC-MP-SORT-001: сортировка по цене ? ? монотонность цен * TC-MP-SORT-002: сортировка по новизне ? новые выше (проверить по датам) ### 7.3 Карточка * TC-MP-CARD-001: открыть карточку активного листинга ? все поля отображаются * TC-MP-CARD-002: открыть скрытый/архивный листинг прямой ссылкой (не админ) ? “недоступно/404” * TC-MP-CARD-003: галерея изображений: 1 фото/несколько/нет фото ? UI корректен * TC-MP-CARD-004: CTA “Купить/Заявка” ? переход в оформление ### 7.4 Заказ/заявка * TC-MP-ORD-001: гость нажимает “Купить” ? редирект на логин, после логина возврат в оформление * TC-MP-ORD-002: обязательные поля пустые ? ошибки валидации * TC-MP-ORD-003: создать заказ с валидными данными ? заказ создан, статус “ожидает оплату/создан” * TC-MP-ORD-004 (анти-фрод): в запросе подменить price/listing_id (через DevTools) ? сервер отклоняет/игнорирует подмену * TC-MP-ORD-005: заказ виден покупателю в “мои заказы” * TC-MP-ORD-006: заказ виден продавцу в “мои продажи/заказы” ### 7.5 Оплата (если есть) * TC-MP-PAY-001: успешная оплата ? статус “оплачен”, доступ к дальнейшим шагам * TC-MP-PAY-002: отмена оплаты на стороне провайдера ? корректный статус, понятное сообщение * TC-MP-PAY-003: повторное нажатие “оплатить” ? не создается дубль заказа; платеж идемпотентен * TC-MP-PAY-004: повторный вебхук ? статус не ломается (идемпотентность) ### 7.6 Кабинет продавца * TC-MP-SELL-001: создать листинг с валидными данными ? листинг появляется в “моих” * TC-MP-SELL-002: загрузка изображения: jpg/png/webp, большой файл, неверный формат ? ожидаемая обработка * TC-MP-SELL-003: редактировать листинг ? изменения видны на витрине (после модерации, если есть) * TC-MP-SELL-004: удалить/скрыть ? на витрине недоступен * TC-MP-SELL-005: попытка редактировать чужой листинг ? 403/ошибка ### 7.7 Админка/модерация (если есть) * TC-MP-ADM-001: approve листинга ? появляется на витрине * TC-MP-ADM-002: reject с причиной ? продавец видит причину, листинг не виден * TC-MP-ADM-003: аудит действий ? запись “кто/когда/что” ### 7.8 Отзывы (если есть) * TC-MP-REV-001: нельзя оставить отзыв без покупки ? блокировка * TC-MP-REV-002: можно оставить отзыв после “выполнен” ? отзыв появляется, рейтинг пересчитан * TC-MP-REV-003: XSS в отзыве ? экранируется --- ## 8) Требования к баг-репортам Каждый баг должен содержать: * URL * роль (гость/покупатель/продавец/админ) * шаги * фактический результат * ожидаемый результат (с ссылкой на FR/TC) * скрин/видео + HAR (для сетевых проблем) * логи консоли (если фронт) --- ## 9) Минимальный набор артефактов, которые тестировщик должен сдать 1. Test Plan (1–2 страницы): скоуп, роли, окружения, риски 2. Набор Smoke кейсов (20–40) 3. Регрессионный набор (100–250, зависит от реального функционала) 4. Отчет о прогоне: пройдено/провалено/заблокировано + список критичных дефектов.