A resposta curta

“O jogo abre em ambiente de homologação” comprova que um caminho bem-sucedido funcionou uma vez em um ambiente de teste. Antes da produção, a equipe também deve comprovar que o candidato e o escopo estão congelados, que os caminhos funcionais e de exceção foram testados, que registros financeiros e operacionais são reconciliados, que a configuração de produção e os limites de acesso são controlados, que a responsabilidade por incidentes é executável e que rollback ou desligamento pode ser realizado com segurança.

A aceitação deve produzir evidências e uma decisão — não apenas a expressão “testado”. Para cada item, registre o ambiente, a versão candidata, o caso de teste, o resultado real, a localização da evidência, o responsável e o nível de bloqueio. Um item sem evidência permanece não verificado; uma confirmação verbal em uma reunião não o transforma em aprovação.

Sete áreas de evidência antes da produção

Área Evidência mínima de aprovação O que deve bloquear a produção
1. Escopo e candidato APIs acordadas, modelo de carteira, escopo de jogos, versão candidata, lista de configuração e exclusões O candidato ainda está mudando ou o escopo testado difere do escopo de release
2. Caminhos funcionais Resultados revisáveis para os casos acordados de lançamento, retorno, carteira e consulta de registros Um caminho crítico de negócio falha ou apenas a exibição de front-end foi verificada
3. Caminhos de exceção Conclusões para casos de timeout, duplicidade, desconexão, falha de negócio, sucesso parcial e estado desconhecido O estado final não pode ser estabelecido e a recuperação depende de retentativas cegas
4. Reconciliação e consistência Identificadores estáveis correlacionam solicitações, transações, rodadas, valores, moedas e movimentações de saldo Registros não podem ser vinculados ou divergências não têm caminho de consulta, tratamento e encerramento
5. Segurança e isolamento de ambiente Credenciais, acessos, dados, logs e limites de configuração de homologação e produção são verificados Credenciais de teste são reutilizadas, segredos entram em código ou logs, ou permissões de produção não estão claras
6. Responsabilidade e prontidão operacional Responsáveis pela decisão de lançamento, resposta de engenharia, reconciliação, segurança e escalonamento estão confirmados Há apenas um contato comercial ou incidentes e divergências financeiras não têm responsável
7. Rollback, desligamento e recuperação Gatilhos, executor, tratamento de dados, validação de recuperação e canais de comunicação estão confirmados A integração não pode ser interrompida com segurança ou ninguém reconcilia o estado após o rollback

Etapa 0: congele o escopo e o formato de evidências

Antes dos testes, estabeleça esta linha de base:

  • candidato a release, versão da documentação de API e versão de configuração;
  • provedores, jogos, modelo de carteira, moedas, idiomas e mercados previstos para lançamento;
  • exclusões explícitas deste release;
  • diferenças entre homologação e produção;
  • pré-condições, entradas, resultados de negócio esperados, resultados reais e localização da evidência para cada caso;
  • gravidade do defeito, aprovador de exceção e responsável pela decisão final de seguir/não seguir.

Se o candidato a release não for a versão testada, reavalie as áreas de aceitação afetadas. Não mantenha conclusões sem uma revisão de impacto.

1. Aceitação funcional

Cubra toda a cadeia de negócio acordada, em vez de uma única tela de jogo:

  • o catálogo ou jogo-alvo é identificado pelo ID estável acordado;
  • criação de sessão, entrada, retorno e expiração se comportam como acordado;
  • o modelo de carteira selecionado conclui seu caminho bem-sucedido esperado;
  • resultados de negócio são avaliados segundo o protocolo de interface, não inferidos apenas do status HTTP;
  • registros de transação, rodada e relacionados podem ser consultados e vinculados às ações de teste;
  • permissões, moedas, idiomas e dispositivos são testados apenas para combinações da linha de base congelada.

Escreva condições de aprovação como resultados observáveis — por exemplo, “a transação de teste é retornada pelo ID de negócio especificado e corresponde à movimentação no livro-razão” — em vez de “a carteira funciona”.

2. Aceitação de exceções

Escolha os casos de exceção com base no risco do projeto e no protocolo real. Em geral, eles incluem:

  • timeout de solicitação, resposta perdida ou conexão interrompida;
  • envio duplicado ou callback duplicado;
  • falha de parâmetro, permissão, assinatura ou validação de negócio;
  • sucesso parcial a jusante quando o chamador não tem status completo;
  • consulta, compensação, reconciliação ou escalonamento manual após recuperação do serviço;
  • interrupção de ação automatizada após o limite acordado de retentativa, preservando as evidências.

Esta lista de verificação exige um resultado testado para caminhos de exceção. Ela não inventa uma chave de idempotência, contagem de retentativas ou valor de recuo para um projeto. Consulte idempotência, retentativas e reconciliação na Slots API para o arcabouço de projeto e use o protocolo formal das partes para os detalhes de implementação.

3. Aceitação de registros e reconciliação

Use pelo menos uma transação normal e um cenário de exceção ou de estado desconhecido. Verifique se:

  • identificadores de solicitação, transação de negócio, rodada e aposta podem ser correlacionados;
  • valor, moeda, direção, estado final e interpretação de tempo concordam;
  • saldo da carteira ou movimentação do livro-razão corresponde ao registro da transação;
  • eventos duplicados são reconhecidos, em vez de criar dois resultados indistinguíveis;
  • toda divergência tem responsável, registro de tratamento, condição de encerramento e evidência de auditoria;
  • o escopo de consulta ou exportação suporta a revisão operacional e financeira acordada.

Uma amostra aprovada comprova apenas os casos e o escopo abrangidos. Isso não significa que divergências futuras sejam impossíveis.

4. Segurança, configuração e isolamento de ambientes

Produção não é a configuração de homologação copiada para outro host. Antes do release, verifique pelo menos que:

  • teste e produção usam credenciais, permissões e configuração separadas e controladas;
  • segredos não entram no código-fonte, capturas de tela, corpo de tickets ou logs comuns da aplicação;
  • acesso à produção segue o princípio do menor privilégio e possui registros de aprovação, mudança e revogação;
  • os logs retêm contexto suficiente para rastreamento sem registrar segredos de assinatura, credenciais completas ou dados sensíveis desnecessários;
  • dados de teste não podem ser confundidos com transações de produção, e dados de produção não entram em testes sem aprovação;
  • diferenças de configuração foram revisadas, e domínios de produção, regras de rede e alvos de monitoramento passaram por verificações reais do projeto;
  • dependências, relógios, certificados e configurações relacionadas a assinatura têm responsáveis nomeados.

Os padrões técnicos da UK Gambling Commission incluem a separação entre sistemas de desenvolvimento, teste e produção dentro de seu escopo de segurança aplicável. Esta é uma referência útil para isolamento de ambientes, mas cada mercado e projeto ainda requer sua própria revisão. Ela não estabelece conformidade regulatória ou de segurança completa.

5. Responsabilidade e prontidão operacional

Transforme uma lista de contatos em uma matriz de responsabilidades executável:

Cenário Responsabilidade a estabelecer antes do lançamento
Incidente de API ou sessão Primeiro respondente, requisito de evidência, escalonamento de engenharia e comunicação externa
Divergência financeira ou de registro Condição de pausa, responsável pela reconciliação, decisor de negócio e padrão de encerramento
Mudança de catálogo ou versão Iniciador da mudança, avaliação de impacto, notificação e testes de regressão
Incidente de credencial ou segurança Isolamento, rotação, investigação, notificação e aprovação da recuperação
Release e rollback Seguir/não seguir, execução, validação e responsabilidade pelo registro final

Se metas de resposta, disponibilidade de serviço ou reparações forem condições de lançamento, coloque-as no contrato ou em outro documento operacional formalmente acordado.

6. Rollback, desligamento e recuperação

Nem toda integração de API pode ser revertida com um rollback de código. Quando carteiras e transações estão envolvidas, o plano também deve abranger eventos de negócio criados durante a janela de release ou rollback. Confirme:

  • condições explícitas que acionam desligamento ou rollback;
  • quais pontos de entrada podem ser fechados e quais eventos em andamento ainda devem ser tratados;
  • quem executa, aprova e verifica o rollback;
  • como serviço, registros e estado financeiro são verificados após recuperar configuração ou versão;
  • se dados de produção precisam ser retidos, compensados ou reconciliados manualmente;
  • um caminho controlado de degradação, pausa e comunicação quando rollback rápido não for possível.

Execute o plano em um ambiente seguro ou conduza uma simulação de mesa, e preserve o resultado. Este artigo não presume que a AG forneça uma ferramenta específica de rollback.

O registro final de seguir/não seguir

Antes da produção, registre uma decisão concisa:

  • versão candidata e configuração;
  • status de todas as sete áreas de evidência: verificado, aceito condicionalmente ou bloqueado;
  • defeitos e exceções não resolvidos, incluindo risco, responsável e aprovador;
  • responsabilidades de monitoramento, escalonamento, desligamento e recuperação;
  • aprovação separada para acesso à produção e escopo comercial;
  • decisão: seguir, seguir com escopo limitado ou não seguir;
  • data da decisão e funções signatárias, sem presumir uma data fixa de lançamento.

O que pode ser avaliado atualmente neste site

  • O processo de integração separa descoberta, escopo técnico, aceitação de testes e coordenação pré-produção.
  • A referência pública da API mostra códigos de resultado de negócio, identificadores de solicitação ou transação, dois sentidos de carteira e consultas de registros que podem orientar o projeto dos testes.
  • Um jogo aberto abrange apenas um caminho visível; não comprova que carteira, exceções, registros ou permissões tenham sido aprovados na aceitação ponta a ponta.
  • O comportamento real em execução e a admissão em produção devem basear-se em evidência de testes no ambiente acordado e em uma decisão assinada por ambas as partes.

Limites a considerar

  • Esta página não afirma que a AG forneceu credenciais de homologação ou produção a um projeto específico.
  • Ela não estabelece período fixo de teste, data de release, configuração de retentativa, nível de desempenho, capacidade ou SLA.
  • A aprovação em homologação não garante comportamento idêntico em produção.
  • Ela não estabelece que um jogo, versão ou modelo de carteira seja adequado a toda plataforma ou mercado.
  • Ela não afirma segurança absoluta nem substitui aprovação de contrato, conformidade, segurança e mudanças de produção.

FAQ

Se a homologação for aprovada, a equipe pode lançar imediatamente?

Não automaticamente. A identidade do candidato, diferenças de ambiente, acesso à produção, responsabilidade, monitoramento, escopo comercial e condições de rollback ainda precisam de revisão, seguida da decisão de seguir/não seguir acordada.

O teste do caminho bem-sucedido é suficiente?

Não. Timeouts, duplicidades, desconexões, falhas de negócio e estados desconhecidos são fontes comuns de processamento repetido e divergências financeiras. Casos de exceção devem entrar na aceitação conforme o protocolo e o risco.

Quem assina a decisão de produção?

A matriz de responsabilidades do projeto decide. Engenharia, QA, operações ou finanças, segurança e a função com autoridade de decisão de produção normalmente assinam suas próprias áreas. A confirmação comercial não substitui aprovação técnica ou de produção.

Todo projeto deve usar exatamente os mesmos casos de teste?

As sete áreas de evidência são uma estrutura comum. Os casos específicos devem ser ajustados ao modelo de carteira, escopo, mercado-alvo, plataforma atual e risco de mudança. A própria decisão de ajuste deve ser registrada e aprovada.

Leituras relacionadas e próximos passos

Para definir um escopo de aceitação de projeto, use a seção “Fale conosco” para informar o modelo de carteira, os jogos-alvo, a fronteira da plataforma atual e os ambientes esperados. A AG poderá então colaborar nos casos e evidências conforme o protocolo confirmado, sem prometer antecipadamente uma data de lançamento ou admissão em produção.

Fontes e escopo

Para o escopo de produto, consulte o processo de integração, a visão geral da Slots API e a referência pública da API.

Os métodos gerais de release são informados pela engenharia de release e pelas práticas em evolução de envolvimento de SRE do Google SRE. O exemplo de isolamento de ambiente específico de mercado vem dos padrões técnicos de jogo remoto e software: requisitos de segurança da UK Gambling Commission.

Estas fontes explicam práticas gerais de aceitação. Elas não estabelecem que a AG implemente todos os processos referenciados nem que um projeto cumpra um mercado específico. As condições de produção devem ser acordadas pelas funções responsáveis de engenharia, QA, operações ou finanças, segurança, comercial e conformidade.

Precisa transformar estas orientações em um plano de projeto?

Este artigo apoia a avaliação do projeto e não substitui a validação técnica, contratual, de certificação ou da legislação local.

Fale conosco