Контекст
iGaming — это широкая категория онлайн-продуктов для азартных игр. QA-инженер, приходя в iGaming-компанию, сталкивается с несколькими принципиально разными продуктами под одной крышей: казино, спортбеттинг, покер-рум и лотереи работают по разным правилам, используют разные алгоритмы и требуют разного подхода к тестированию.
- Casino: слоты, live casino, настольные игры — результат определяется RNG или живым дилером; ключевой риск — некорректный RTP и выплаты.
- Sports Betting: ставки на события реального мира с динамическими коэффициентами; ключевой риск — ошибки расчёта ставок и задержки live-данных.
- Poker: игра против других игроков, а не против дома; ключевой риск — коллюзия, читерство и корректность оценки комбинаций.
- Лотереи и кено: результат определяется случайным розыгрышем чисел; ключевой риск — целостность розыгрыша и правильность начисления выигрышей.
- Каждый тип продукта регулируется отдельными правилами и может требовать отдельной лицензии в каждой юрисдикции.
Рабочий алгоритм
При онбординге в новый iGaming-проект выполните следующие шаги для понимания продуктовой карты:
- Запросите у продакта или BA список активных вертикалей (casino, sportsbook, poker, lottery) и их статус (production/beta/planned).
- Для каждой вертикали изучите Business Rules Document или Game Math Sheet — документ, описывающий алгоритм определения результата и расчёта выигрыша.
- Составьте матрицу рисков: для каждой вертикали укажите тип риска (RTP, settlement, collusion, draw integrity), вероятность и финансовый импакт.
- Определите точки интеграции между вертикалями: общий кошелёк, единая система бонусов, общий KYC — это зоны повышенного риска.
- Изучите регуляторные требования для каждой вертикали в целевых юрисдикциях: некоторые требования специфичны для типа игры.
- Создайте mind-map продуктовой экосистемы и согласуйте его с командой — это станет основой для планирования тест-стратегии.
Пример из практики
Крупный iGaming-оператор запустил новый покер-рум, интегрированный с существующим казино через общий кошелёк. QA-команда пропустила тестирование граничного сценария: перевод баланса из казино в покер во время активной бонусной wagering-сессии.
- Игрок мог заморозить вейджер в казино, перевести деньги в покер, выиграть и вывести без выполнения условий бонуса.
- Баг существовал 72 часа до обнаружения фрод-командой — финансовые потери составили $140k.
- Root cause: QA-команда тестировала покер и казино изолированно, не покрыв интеграционные сценарии с бонусной системой.
- После инцидента в тест-план добавили отдельный раздел cross-vertical integration tests с обязательным smoke-тестированием перед каждым релизом.
Частые ошибки
Начинающие QA-инженеры в iGaming допускают характерные ошибки при работе с многопродуктовыми платформами:
- Тестирование вертикалей в полной изоляции — игнорирование общего кошелька, бонусной системы и единого аккаунта как точек интеграции.
- Применение одинакового тест-подхода к casino и sportsbook — они имеют принципиально разные риски и алгоритмы.
- Игнорирование регуляторной специфики: тесты, достаточные для Curaçao-лицензии, могут быть критически недостаточны для UKGC.
- Отсутствие понимания Business Rules — тестирование «на глаз» без эталонного Game Math Sheet приводит к пропуску RTP-ошибок.
- Недооценка сложности покера: проверяют только базовые комбинации, пропуская split pot, side pot и edge cases раздачи.