Qualidade
Como validamos jogos web e aplicativos Android
Testar um jogo é mais do que confirmar que ele abre. Regras, interface, tempo, inteligência do computador, sincronização e estados finais interagem. Nossa estratégia usa camadas: verificações rápidas para erros previsíveis, automação para fluxos repetíveis e testes manuais para percepção visual e uso em aparelho real.
1. A regra é o primeiro contrato
Antes do teste visual, descrevemos as transições relevantes. Quem pode agir? O que torna uma jogada válida? Quando o turno muda? Como se determina vitória, derrota ou empate? Em Rouba-Monte, por exemplo, a distribuição de novas cartas depende de todas as mãos terem terminado. Em Dominó, uma peça só pode entrar em uma extremidade compatível e a orientação visual não pode alterar seu valor.
Casos de borda recebem atenção especial: pilha vazia, jogador desconectado, repetição, nenhuma jogada disponível e reinício. Se a regra exibida na página divergir da implementação, o produto está errado mesmo quando o código não apresenta exceção.
2. Análise estática e testes automatizados
Nos projetos Flutter, análise estática encontra tipos incompatíveis, APIs obsoletas e padrões de código problemáticos antes do build. Testes unitários e de widget verificam partes determinísticas. Na web, scripts automatizados percorrem o catálogo, iniciam jogos e observam erros de console, recursos ausentes e elementos fora da área esperada.
A automação é mais útil quando protege uma correção concreta. Depois de ajustar a posição das cartas da Sueca no celular, o teste passou a reprovar se as cartas externas saíssem da mesa. Após criar o seletor móvel da Batalha Naval, sua presença e funcionamento entraram na suíte. Assim, o teste registra conhecimento sobre regressões que já aconteceram.
3. Matriz visual proporcional
Não testamos todas as combinações possíveis de tela. Escolhemos representantes que expõem riscos distintos: celular estreito em retrato, tablet em retrato e paisagem e computador. Temas claro e escuro são verificados porque controles nativos, listas suspensas e estados de foco podem ficar ilegíveis mesmo quando o restante do layout está correto.
Cada jogo percorre uma partida completa. Observamos cabeçalho, instruções, tabuleiro, mão, placar, modal e estado final. Também conferimos se a página cria rolagem indesejada durante a jogada, se botões permanecem tocáveis e se uma mensagem de vitória depende apenas de cor ou animação.
4. Ambiente real e rede
Um navegador automatizado não reproduz completamente um celular. Por isso, a etapa móvel inclui aparelho físico para toque, retorno do aplicativo, orientação, som e desempenho percebido. No Android, o AAB assinado precisa ser instalado pela faixa de teste da loja sempre que possível, porque esse caminho se aproxima da distribuição real e alimenta o relatório de pré-lançamento.
Partidas online precisam de pelo menos dois clientes. Criar sala em uma única aba prova pouco; testamos entrada, aprovação, início, alternância de turnos, atualização dos participantes, término e limpeza. Também verificamos o comportamento quando um cliente atualiza a página ou perde a conexão.
5. Publicação gradual
Uma suíte aprovada reduz risco, mas não garante ausência de defeitos. Publicamos de forma controlada e acompanhamos erros. No catálogo Android, o Memory Master foi escolhido como piloto para validar assinatura, materiais da loja, declarações de dados, teste interno e relatório de pré-lançamento. Somente depois desse ciclo os demais aplicativos devem seguir o mesmo processo.
Publicidade é tratada como parte da interface. Um anúncio não pode cobrir controles, deslocar o tabuleiro ou induzir clique acidental. IDs de teste e produção permanecem separados, e builds de produção não aceitam identificadores de teste. No portal web, o carregamento fica desativado enquanto a conta e o domínio não estiverem aprovados.
Checklist de liberação
- Regra pública e comportamento concordam.
- Uma partida completa chega corretamente ao resultado.
- Console e análise estática não apresentam erros relevantes.
- Celular, tablet e computador mantêm controles utilizáveis.
- Temas claro e escuro preservam contraste e foco.
- Preferência por movimento reduzido é respeitada.
- Fluxos online foram testados com clientes separados.
- Build assinado foi instalado pelo canal mais próximo da produção.
- Política de privacidade e declarações refletem as bibliotecas usadas.