Контекст

Современная беттинг-платформа — это не один продукт, а экосистема взаимосвязанных модулей: pre-match sportsbook, live betting, казино, виртуальные виды спорта, киберспорт и лотереи. Каждый модуль имеет собственную логику расчёта коэффициентов, settlement и управления рисками. QA-инженер, не знающий различий между этими продуктами, рискует пропустить критические баги в бизнес-логике. Например, правила void и cancellation для виртуального футбола кардинально отличаются от реального спорта. Понимание продуктовой карты беттинг-оператора — фундамент эффективного тестирования.

Pre-match betting: ставки принимаются до начала события, рынки закрываются за несколько минут до старта, коэффициенты относительно стабильны
In-play (live) betting: ставки в реальном времени во время события, коэффициенты обновляются каждые 1-5 секунд, рынки могут быть приостановлены
Virtual sports: симулированные события (виртуальный футбол, скачки), результаты генерируются RNG, циклы длятся 3-5 минут непрерывно
Esports betting: ставки на League of Legends, CS2, Dota 2 и другие игры, специфика — длинные матчи, nested markets (ставки на отдельные карты/раунды)
Outright / futures: долгосрочные ставки на победителя турнира, чемпионата, лиги; settlement откладывается на недели или месяцы

Рабочий алгоритм

При онбординге на беттинг-проект составляйте карту продуктов, которые покрывает платформа, и для каждого продукта определяйте ключевые точки риска.

Составьте матрицу продуктов: выпишите все вертикали (sport, live, virtual, esports, casino), отметьте какие из них уже в проде, а какие в разработке
Для каждого продукта определите тип settlement: автоматический по фиду данных, ручной трейдерами или гибридный — это влияет на тест-кейсы для void и correction
Изучите типы ставок внутри каждого продукта: singles, doubles, trebles, accumulators, system bets (Trixie, Patent, Yankee, Lucky 15) — каждый тип имеет уникальную формулу расчёта
Зафиксируйте cut-off rules для каждого канала: веб, мобильное приложение, retail-терминал могут иметь разные deadlines для приёма ставок
Проверьте наличие специфических рынков: BTTS (both teams to score), Asian handicap, spread betting — их математика отличается от классических рынков
Создайте глоссарий в Confluence с терминами из Domain: stake, liability, exposure, void, push, cashout, each-way, SP (starting price) — без этого тест-кейсы будут неоднозначными

Пример из практики

На проекте беттинг-оператора второго эшелона команда QA добавила в регрессионный набор только pre-match сценарии. После запуска virtual sports обнаружились баги в settlement через 2 недели в проде: виртуальные матчи с RNG-результатом «ничья» не проходили settlement, так как код settlement-сервиса не обрабатывал draw как отдельный исход для виртуальных рынков.

Проблема: settlement-сервис был написан с предположением, что ничья невозможна — это было верно для тенниса и баскетбола, но не для виртуального футбола
Последствия: за 2 недели накопилось 4 700 неурегулированных ставок, клиенты не получили выплаты, поступили chargeback-заявки
Причина пропуска: QA не имел глоссария продуктов и не знал, что virtual football отличается по settlement rules от real football
Решение: составили матрицу «продукт → возможные исходы → тип settlement» и добавили отдельные тест-кейсы для каждого сочетания перед следующим запуском

Частые ошибки

QA-инженеры, приходящие из других доменов, совершают типовые ошибки при знакомстве с беттинг-продуктами.

Смешение pre-match и in-play правил в тест-кейсах: например, тестирование cashout для pre-match ставок по правилам live-cashout, хотя у них разные формулы расчёта
Игнорирование виртуальных видов спорта в регрессии: считают, что «это просто симуляция», хотя там полноценные денежные транзакции и собственный settlement pipeline
Непонимание разницы между void и cancelled: void означает, что ставка возвращается как часть системной ставки, cancelled — полный возврат stake; путаница ведёт к неправильным тест-кейсам
Тестирование только Singles и игнорирование system bets: Trixie из 3 событий создаёт 4 ставки внутри, баги в перерасчёте при void одного из selections проявляются только там
Отсутствие тест-кейсов для SP (starting price): для ставок на лошадиные скачки SP определяется в момент старта, а не при приёме ставки; тест-кейс для SP отличается от fixed odds

✅ Самопроверка

1Чем отличается void от cancelled в контексте системной ставки Trixie?

При void одного из selections в системной ставке Trixie количество активных комбинаций уменьшается (из 4 ставок остаётся 3 или меньше), и перерасчёт выплаты идёт по оставшимся комбинациям. При cancelled — вся ставка возвращается полностью без settlement.

2Почему settlement виртуальных видов спорта требует отдельных тест-кейсов, а не переиспользования pre-match сценариев?

Виртуальные виды спорта имеют RNG-генерируемые результаты, непрерывный цикл событий без перерывов и иной набор возможных исходов (например, ничья в виртуальном футболе). Кроме того, у них нет аналогов abandoned match или weather cancellation, которые есть в реальном спорте, что меняет весь набор edge cases для settlement.

3Какой cut-off rule применяется к in-play ставкам и почему он критичен для тестирования?

In-play ставки имеют динамический cut-off: рынок может быть приостановлен трейдером или автоматически при значимом событии в матче (гол, красная карточка). Тест-кейс должен проверять, что ставки, отправленные в период приостановки рынка, либо отклоняются с корректным сообщением, либо не принимаются системой — и никакой partial acceptance не происходит.