Checklist de QA para lançamento de slot: 40 verificações antes do go-live

Integration · 2026-07-16 · 9 min read · By CROCO Games

Um checklist prático de 40 pontos para operadores integrando um slot novo: matemática e configuração, comportamento de plataforma, UX mobile, compliance e prontidão de lobby — cada item com método de verificação.

A maioria dos incidentes de lançamento de slot não é exótica: uma variante de RTP errada num mercado, uma rodada bônus que perde estado na reconexão, um thumbnail que nunca foi localizado, um modo demo apontando para dinheiro real. Todos são detectáveis numa tarde com um checklist — e quase ninguém roda um, porque o dia do lançamento é corrido e o agregador disse que estava tudo bem. Aqui estão as 40 verificações que recomendamos aos operadores antes de qualquer título entrar no ar, agrupadas em cinco blocos de oito. Cada verificação diz o que conferir e como. Adapte sem dó; não delete nada até ter sido queimado pelo que aquele item pega.

Bloco A — Matemática e configuração (verificações 1–8)

  1. Variante de RTP por mercado. Confirme que a variante implantada em cada jurisdição bate com sua intenção comercial e regulatória. Verifique na tela de paytable/info do jogo em produção, por mercado — não só no back office do agregador; deriva de configuração entre os dois é um incidente clássico.
  2. Limites de aposta. Aposta mínima/máxima e a escada de stakes batem com sua configuração de mercado e expectativa dos jogadores; confira que os extremos realmente giram.
  3. Exibição de moeda. Moeda correta, formatação correta, conversão correta em moedas não-base — inclusive dentro da paytable, onde um € hardcoded já envergonhou muitos lançamentos.
  4. Aritmética da paytable. Confira cinco entradas da paytable contra as especificações do game sheet; paytables de variante errada aparecem aqui primeiro.
  5. Parâmetros de recursos. Preço do bonus buy, multiplicadores de aposta de recurso, seeds de níveis de jackpot — cada número configurável contra a ficha.
  6. Teto de ganho máximo. O teto anunciado bate com a configuração implantada, e o comportamento no teto está correto (rolos travados, contador limitado, mensagem certa).
  7. Fiação de jackpot (se aplicável). Contadores incrementam, exibem o pote certo, e a lógica de níveis bate com o contrato — potes locais vs de rede especialmente.
  8. Modo demo. O jogo fun-play existe onde é legal, está claramente rotulado, não usa carteira real e está desabilitado onde é proibido. As duas direções de falha são incidentes de compliance.

Bloco B — Comportamento de plataforma (verificações 9–16)

  1. Ida e volta da carteira. Débito de aposta e crédito de ganho reconciliam exatamente — rode uma sessão roteirizada e compare o histórico do jogo com as transações da carteira até o centavo.
  2. Recuperação de desconexão. Mate a conexão no meio do giro e no meio do bônus; a sessão deve retomar no estado idêntico com saldo intacto. A fonte mais comum de problemas ao vivo em jogos novos.
  3. Histórico de rodadas. Toda rodada aparece com aposta, resultado e detalhe de recurso corretos; replay funciona onde é oferecido.
  4. Política de sessões concorrentes. Dois dispositivos, uma conta: qualquer que seja sua política (bloquear, transferir, permitir), verifique que o jogo a aplica sem corromper saldo.
  5. Degradação de latência. Estrangule para velocidade 3G: o jogo deve continuar jogável e, acima de tudo, nunca exibir saldo errado durante chamadas lentas de carteira.
  6. Tratamento de erros. Simule timeouts de carteira e respostas malformadas; o jogo deve falhar para um estado claro e retomável, nunca uma tela girando para sempre.
  7. Integração de limites de sessão. Reality checks, limites de perda e relógios de sessão da sua plataforma disparam corretamente dentro do jogo — overlay renderiza, jogo pausa, eventos regulatórios são logados.
  8. Sanidade de carga. Se o marketing de lançamento vai gerar pico de tráfego, confirme que provedor/agregador viram sua projeção de concorrência; faça a pergunta por escrito.

Bloco C — UX e mobile (verificações 17–24)

  1. Retrato e paisagem. Ambas as orientações renderizam corretamente em celulares pequenos — controles alcançáveis, símbolos legíveis, sem UI cortada em larguras de 320px.
  2. Alvos de toque. Controles de giro, aposta e menu atendem tamanhos mínimos de toque; sem layouts de aposta acidental (o stepper de stake colado no botão de giro é o clássico).
  3. Tempo de carga. Tempos de primeira carga e carga com cache num celular intermediário em 4G; um lobby que carrega em 2s alimentando um jogo que carrega em 20 vaza jogadores na porta.
  4. Compliance de autoplay. Limites de autoplay, configurações de limite de perda e parada forçada por jurisdição (alguns mercados proíbem autoplay por completo — verifique que está ausente lá).
  5. Padrões de som. Políticas de mudo-por-padrão respeitadas; desmutar persiste entre sessões; sem rajada de áudio no carregamento.
  6. Informações no jogo. Regras, paytable e tela de RTP abrem, estão localizadas e batem com a variante implantada — a tela de info é documento regulatório, não decoração.
  7. Varredura de localização. Toda string visível em cada idioma de lançamento; regras de bônus traduzidas por máquina e compostos alemães truncados são infratores perenes.
  8. UX de recurso interrompido. Entre num bônus, feche o navegador, volte: a experiência de reentrada deve ser óbvia para um jogador confuso, não apenas tecnicamente correta.

Bloco D — Compliance e jogo responsável (verificações 25–32)

  1. Cobertura de certificação. O hash/versão exato do build está certificado para cada jurisdição de lançamento; mantenha as referências dos certificados em arquivo para auditoria.
  2. Restrições de mercado. O geo-bloqueio bate com a lista de mercados certificados; teste de um geo bloqueado, não só de um permitido.
  3. Alegações anunciadas. Todo número no seu material promocional (ganho máximo, RTP, frequência de recurso) bate com a configuração implantada — deriva entre marketing e configuração é gerador de reclamações regulatórias.
  4. Visibilidade de ferramentas RG. Limites de depósito, autoexclusão e reality checks alcançáveis de dentro da sessão de jogo conforme regras locais.
  5. Gating de idade/identidade. O jogo é inalcançável por contas não verificadas onde a verificação é exigida antes do jogo.
  6. Alinhamento de termos de bônus. Se promoções de lançamento anexam giros grátis, termos de wagering, peso dos jogos e tetos de conversão estão configurados e exibidos corretamente.
  7. Reporte regulatório. Rodadas fluem para seu reporte de jurisdição (onde exigido) com identificadores de jogo corretos — uma falha silenciosa de mapeamento aqui aparece meses depois numa auditoria.
  8. Caminho de reclamação. O suporte enxerga histórico de rodadas e replay deste título; um lançamento sem ferramental de suporte transforma cada dúvida de jogador numa escalação.

Bloco E — Prontidão de lobby e marketing (verificações 33–40)

  1. Thumbnails. Arte correta em cada proporção exigida, localizada onde seu lobby localiza, e legível no tamanho real renderizado num celular.
  2. Metadados. Provedor, rótulo de volatilidade, tags de recurso e RTP exibidos no lobby batem com a realidade implantada; rótulos de volatilidade errados sabotam as fileiras de segmento.
  3. Busca e filtros. O jogo é encontrável por nome (incluindo erros de grafia plausíveis), provedor e filtros de mecânica.
  4. Plano de posição de prateleira. Lançamentos ganham mediana de dias, não semanas, de atenção de topo — num conjunto de rastreamento de lobbies de 689 marcas, o jogo mediano segura vaga de top-10 por apenas 2 dias — então o plano de posicionamento (qual fileira, qual posição, por quanto tempo) deve existir antes do go-live, não depois.
  5. Link de demo. Links de demo do marketing apontam para o demo de produção, no idioma certo e apresentação de moeda certa.
  6. Assets de CRM. Segmentos de e-mail/push de lançamento definidos, criativos aprovados, envio agendado contra a janela de posicionamento — atenção de prateleira e CRM devem bater na mesma semana.
  7. Tracking. Eventos de analytics no nível do jogo (aberturas, sessões, entradas de recurso) verificados ponta a ponta no seu BI antes do lançamento, ou você medirá o lançamento por anedota.
  8. Plano de rollback. Um procedimento testado para tirar o jogo (remoção do lobby, gestão de sessões ativas, comunicação a jogadores) em minutos — a verificação que todos pulam e a que transforma um lançamento ruim numa nota de rodapé em vez de uma semana.

Rodando sem cerimônia

Quarenta verificações leem mais pesado do que rodam: os blocos A e E são trabalho de mesa que um analista limpa numa hora com a ficha aberta; B e C são uma tarde com dois celulares e uma conexão estrangulada; o bloco D é majoritariamente confirmar configuração permanente. O padrão eficiente é uma planilha compartilhada por lançamento — verificação, dono, link de evidência, status — reusada como template para que o segundo lançamento custe metade do primeiro. Provedores podem encurtar a lista do lado deles: a CROCO entrega game sheets por título com configurações exatas, listas de mercados certificados e notas de teste de integração através de uma única integração de API, e nosso time acompanha operadores no QA do primeiro lançamento sob demanda via contato.

Perguntas frequentes

O que um operador deve testar antes de lançar um slot novo? Cinco áreas: configuração matemática (variante de RTP, stakes, paytable), comportamento de plataforma (reconciliação de carteira, recuperação de desconexão), UX mobile (orientações, alvos de toque, tempo de carga), compliance (cobertura de certificação, ferramentas RG, geo-bloqueio) e prontidão de lobby (thumbnails, metadados, planos de posicionamento e rollback).

Qual é o problema técnico mais comum em lançamentos de slot? Recuperação de estado após desconexão — um jogador derrubado no meio do bônus precisa retomar exatamente onde o recurso pausou. Teste matando a conexão no meio do giro e do recurso; é a maior fonte de tickets em títulos novos.

Quem é responsável pelo QA do slot — provedor ou operador? Os dois, em camadas diferentes. O estúdio certifica matemática e comportamento do jogo; o agregador testa o encanamento da integração; mas configuração de mercado, reconciliação de carteira, encaixe de compliance e prontidão de lobby são do lado do operador e só verificáveis no ambiente de produção do operador.

Quanto tempo leva o QA pré-lançamento de um slot? Com um template e game sheets por título, cerca de um dia: uma hora de verificações de mesa contra especificações, uma tarde de testes de dispositivo e plataforma, e confirmações permanentes de compliance. A primeira rodada leva mais; o template se paga no segundo lançamento.

Principais conclusões