ТЗ для тестировщиков модуля маркетплейса (любой на ваш выбор) в формате, пригодном для тест-плана и набора тест-кейсов. ## 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. Отчет о прогоне: пройдено/провалено/заблокировано + список критичных дефектов.
Задачи чат-бота: информирование клиентов. Продукт: дальше. Техзадание есть. 1. Полное описание Необходимо разработать автоматизированного бота, который выполняет комплексную автоматизацию процесса записи в визовый центр: · Автоматическое бронирование найденных слотов · Автоматическое прохождение видео-верификации с использованием заранее подготовленных материалов 2. Цели и задачи · Основная цель: Полная автоматизация процесса записи на подачу документов в визовый центр · Ключевые задачи: · Авторизация в системе VFS Global · Поиск и анализ доступных дат для записи · Автоматическое бронирование подходящих слотов · Прохождение видео-верификации с использованием виртуальной камеры · Обеспечение стабильной работы 24/7 3. Функциональные требования 3.1. Конфигурационная система · Учетные данные VFS Global (логин/пароль) · URL целевого визового центра · Желаемый период для записи · Настройки уведомлений (Telegram Bot Token) · Интервалы проверки (10-30 секунд) · Пути к видеофайлам для верификации · Настройки виртуальной камеры 3.2. Модуль мониторинга и бронирования · Режим 1 (Оповещатель): · Постоянный мониторинг доступных слотов · Мгновенные уведомления в Telegram при обнаружении подходящей даты · Прямые ссылки на страницу бронирования в уведомлениях · Режим 2 (Автобронирование): · Полностью автоматическое бронирование слотов · Автозаполнение необходимых данных · Подтверждение бронирования 3.3. Модуль видео-верификации · Интеграция с виртуальной камерой: · Поддержка OBS Virtual Camera, ManyCam и аналогичных решений · Программное управление видео-потоком через OBS WebSocket · Автоматизация процесса: · Определение этапа видео-верификации · Автоматическое предоставление прав доступа к камере и микрофону · Выбор виртуальной камеры в качестве источника · Воспроизведение подготовленных видеофайлов · Корректное завершение сеанса верификации 3.4. Техническая устойчивость · Обход систем защиты (Cloudflare, антибот системы) · Поддержание пользовательской сессии (cookies, headers) · Обработка сетевых ошибок и изменений в структуре сайта · Расширенное логирование всех операций 4. Нефункциональные требования 4.1. Технический стек · Язык программирования: Любой · Работа с видео: OBS Studio + obs-websocket · Логирование: встроенный модуль logging 4.2. Системные требования · Обязательное ПО: OBS Studio с Virtual Camera plugin · Дополнительно: xvfb для Linux (безголовый режим) 4.3. Производительность и надежность · Работа 24/7 с минимальными перерывами · Оптимизированная нагрузка на серверы VFS · Автоматическое восстановление после сбоев · Детальное логирование для диагностики 5. Этапы разработки и приемки Этап 1: Подготовительный · Согласование ТЗ и технических деталей · Подготовка тестового окружения Этап 2: Базовый функционал · Разработка модуля авторизации и мониторинга · Реализация системы уведомлений (Telegram) · Тестирование парсинга и поиска слотов Этап 3: Модуль бронирования · Разработка системы автобронирования · Интеграция с этапами оформления записи · Тестирование полного цикла бронирования Этап 4: Видео-верификация · Интеграция с OBS Studio и виртуальной камерой · Разработка модуля автоматической верификации · Тестирование воспроизведения видео через виртуальную камеру Этап 5: Комплексное тестирование · Полное тестирование всего workflow · Проверка стабильности и обработки ошибок · Нагрузочное тестирование Этап 6: Документация и сдача · Подготовка инструкции по установке и настройке · Написание руководства пользователя · Финальная демонстрация и сдача проекта 6. Критерии приемки 1. Бот успешно запускается на чистой VPS по предоставленной инструкции 2. Стабильная работа в течение 48 часов без критических ошибок 3. Успешное прохождение полного цикла: поиск ? бронирование ? видео-верификация 4. Корректная работа системы уведомлений 5. Гибкая настройка под разные визовые центры и даты 7. Важные предупреждения и ограничения 7.1. Технические риски · VFS Global может изменить структуру сайта или усилить защиту · Возможно появление капчи, требующей интеграции с сервисами распознавания · Не гарантируется 100% успех видео-верификации из-за возможных систем обнаружения 8. Требования к исполнителю · Опыт веб-скрейпинга с обходом систем защиты (Cloudflare) · Интеграция с OBS Studio и виртуальными камерами · Понимание WebRTC и медиа-потоков в браузере · Опыт работы с API Telegram для уведомлений 9. Результаты проекта Исполнитель предоставляет: 1. Полный исходный код 2. Исполняемые файлы и скрипты запуска 3. Подробную документацию по установке и настройке 4. Инструкцию по конфигурации OBS и виртуальной камеры 5. Примеры конфигурационных файлов.
Почему стоит искать работу для фриласнеров по профилю программисты в России у нас?
🔸 Более 1 предложений о работе за сегодня в тематике программисты
🔸 Работа и подработка на бирже фриланса от прямых заказчиков, которым нужна помощь специалистов по профилю программисты уже сегодня!
🔸 Свежих заказов на программисты в России для фрилансеров на июнь 2026 года — 7050 шт.
Как найти удалённую работу для фриланс-специалистов по профилю программисты в России?
Вы специалист по программисты и ищете проекты и заказы на удалёнке в России? Нам всегда есть что вам предложить. Ежедневно мы публикуем новые проекты и заказы по вашей специальности. Найдите интересную работу уже сегодня
Сколько проектов для IT-специалистов по профилю программисты в России?
На июнь 2026 года опубликовано 7050 предложений удалённой работы от прямых заказчиков для исполнителей по специализации программисты
Сколько можно заработать выполняя проекты по программисты?
Специалисты по профилю программисты зарабатывают от 0.00 рублей с заказа. Хотите больше? Выполняйте как можно больше заказов и зарабатывайте сколько пожелаете