Sistema de Resultados de Campeonatos (Chronosat)
Validacao em duas frentes, Alfa (interno) e Beta (com o cliente)
Sistema de Resultados de Campeonatos (Chronosat): Plano de Testes (Alfa e Beta)
| Campo | Valor |
|---|---|
| Projeto | Sistema de Resultados de Campeonatos (integração Chronosat) |
| Cliente | Sertões |
| Agência / Autor | Modulareasy |
| Documento | Plano de Testes (Alfa e Beta), companheiro do DRS |
| Data de revisão | 2026-07-03 |
Documentos da família
- DRS (resultados-chronosat), o que o sistema faz.
- Roadmap de Implementação (resultados-chronosat-roadmap), em que ordem construir e como verificar.
- Inventário de Artefatos (resultados-chronosat-inventario), tudo que precisa existir e como cada item deve ser.
- Jornadas dos Atores (resultados-chronosat-jornadas), como cada papel opera o sistema.
Este documento valida o sistema antes da entrega, em duas seções. Alfa: teste interno, um item por requisito funcional do DRS (usando o critério de aceite H1 de cada um), mais itens gerais de visual, segurança, desempenho, mobile e regressão. Beta: teste com o público, o operador e o administrador reais, um item por jornada de cada ator, mais a coleta de feedback do primeiro evento ao vivo. É a camada de validação do sistema inteiro, acima do "como verificar" que cada tarefa do Roadmap já traz embutido: o Roadmap prova que cada peça foi construída certa, este documento prova que o sistema completo funciona e está pronto para o público.
Como usar
Cada item é um card marcável. Um item Alfa só passa quando o critério (H1 do requisito, ou o critério do item geral) se confirma de fato, testado à mão ou de forma automatizada. Um item Beta só passa quando o usuário real completa a jornada ponta a ponta sem bloqueio. A entrega ao público só ocorre com a seção Alfa inteira concluída e a seção Beta observada em um evento real.
Verticais MTB e Kitesurf (validação com o primeiro pacote real, sem espera): a construção e os testes usam os dados reais já em mãos (rally); nenhum arquivo de exemplo de terceiros é aguardado. Quando o primeiro pacote real da Bike ou do Kite chegar, ele é validado no próprio teste de conexão do cadastro (conforme o Roadmap, F5-GATE e F6-GATE): no match, os testes daquela vertical ({TA-19}, {TA-41}, {TA-44}) rodam com renderização plena; na divergência estrutural (ex.: dupla com dois numerais na Bike, classificação por pontos no Kite), valida-se o fallback genérico útil e o adaptador de ingestão (ADR-012) entra como refinamento, sem bloquear os demais cards.
Alfa (testes internos)
INGEST, ingestão e cache
Cobre: RF-INGEST-001.
Como testar: publicar um evento com URLs válidas de crews, stagetimes e racetimes e observar as chamadas de rede do navegador do público.
Passa quando: o front recebe os dados sem chamar satcron.com diretamente, a resposta do servidor inclui cabeçalho de origem cruzada permitindo o domínio da página, e nenhuma chamada direta à Chronosat parte do navegador.
Cobre: RF-INGEST-002.
Como testar: disparar múltiplas requisições do público para o mesmo arquivo dentro de uma janela de 30 segundos e contar as chamadas efetivas à Chronosat.
Passa quando: todas as requisições dentro da janela são servidas do cache e a chamada à origem ocorre no máximo uma vez por minuto por arquivo.
Cobre: RF-INGEST-003.
Como testar: simular a Chronosat respondendo erro ou indisponível após uma leitura bem sucedida, e acessar a página.
Passa quando: a página exibe o último resultado válido conhecido com indicação de atualização suspensa, sem erro cru nem página em branco.
Cobre: RF-INGEST-004.
Como testar: conferir, para um competidor de numeral conhecido, se a visão consolidada reúne dados de crews, stagetimes e racetimes.
Passa quando: a visão do competidor reúne identificação, parciais, tempo do trecho e acumulado geral, todos com o mesmo numeral.
Cobre: RF-INGEST-005.
Como testar: com um evento ao vivo já com leituras bem-sucedidas, derrubar a origem (Chronosat fora do ar ou inacessível) SEM encerrar o evento no painel, e acessar a página; em seguida, consultar diretamente o banco de dados e conferir o payload bruto salvo para aquela fonte (evento, modalidade, tipo e trecho).
Passa quando: a página continua exibindo o último estado salvo no banco mesmo com a origem fora do ar e o evento ainda não encerrado, nenhum dado exibido anteriormente se perde, e a consulta ao banco mostra o payload bruto da última leitura bem-sucedida com o momento da leitura registrado.
API, leitura interna
Cobre: RF-API-001.
Como testar: chamar o endpoint de classificação geral de um evento e modalidade publicados.
Passa quando: retorna a lista de competidores ordenada pelo tempo total acumulado, cada um com numeral, tripulação, veículo, equipe, tempo total, penalidades e bônus.
Cobre: RF-API-002.
Como testar: chamar o endpoint de um trecho específico de um evento e modalidade publicados.
Passa quando: retorna a lista de competidores do trecho com tempo da especial, posições parciais e tempo total do trecho.
Cobre: RF-API-003.
Como testar: chamar o endpoint de detalhe para um competidor com parciais registradas em um trecho.
Passa quando: retorna os horários I1 a I7, os deltas tempo1 a tempo7 e as posições posI1 a posI7, omitindo os indicadores nulos.
Cobre: RF-API-004.
Como testar: carregar a página de um evento publicado e conferir os metadados recebidos.
Passa quando: retorna título e subtítulo da prova, a lista de trechos com atributos e status, as modalidades, as categorias e o estado ao vivo ou encerrado.
Cobre: RF-API-005.
Como testar: chamar o endpoint de classificação de uma categoria específica de um evento com categorias definidas.
Passa quando: retorna apenas os competidores da categoria, ordenados pelo tempo aplicável, com posição renumerada de 1 em diante.
PUB, página pública
Cobre: RF-PUB-001.
Como testar: abrir a página no celular e no desktop com um evento com classificação disponível, incluindo um competidor em abandono ou teto, num evento da vertical Series (piloto e navegador).
Passa quando: no celular cada competidor aparece como cartão com posição, numeral, tripulação, equipe e veículo, categoria, penalidades, tempo total e diferença; no desktop os mesmos dados aparecem em tabela na ordem definida; quem abandonou ou atingiu o teto exibe "Não completou".
Cobre: RF-PUB-001, RF-CONFIG-001.
Como testar: abrir a tabela (ou os cartões no celular) de um evento de cada perfil de tripulação: Series ou Petrobras (piloto e navegador), MTB (dupla), Kitesurf (solo).
Passa quando: no rally o piloto aparece em destaque com o navegador ao lado (formato "PILOTO (UF) | NAVEGADOR (UF)"); na bike os dois nomes da dupla aparecem em negrito; no kite aparece apenas o atleta solo; nenhuma vertical exibe a regra de exibição de outra.
Cobre: RF-PUB-002.
Como testar: abrir um recorte (geral, categoria ou etapa) com ao menos cinco competidores e outro com menos de cinco, num evento da vertical Series.
Passa quando: os cinco primeiros aparecem em ordem sequencial de 1º a 5º, cada lugar com posição, numeral, piloto, navegador, equipe, tempo total e diferença, refletindo o recorte selecionado; com menos de cinco, mostra os que houver na mesma ordem.
Cobre: RF-PUB-002, RF-CONFIG-001.
Como testar: abrir o pódio de um evento de cada perfil de tripulação: Series ou Petrobras (piloto e navegador), MTB (dupla), Kitesurf (solo).
Passa quando: cada lugar do pódio exibe os nomes conforme a regra da vertical (piloto e navegador no rally, os dois nomes da dupla em negrito na bike, o atleta solo no kite), coerente com {TA-10B}.
Cobre: RF-PUB-003.
Como testar: num evento com mais de uma modalidade, selecionar cada modalidade disponível.
Passa quando: a classificação, o pódio e os trechos passam a refletir apenas a modalidade selecionada.
Cobre: RF-PUB-004.
Como testar: num evento com categorias definidas, selecionar uma categoria no Geral e com um trecho selecionado.
Passa quando: a lista exibe apenas os competidores da categoria, ordenados pelo tempo aplicável, com posição renumerada de 1 em diante, e o pódio reflete os cinco primeiros da categoria.
Cobre: RF-PUB-005.
Como testar: num evento com trechos iniciados, selecionar um trecho e depois voltar para Geral.
Passa quando: a tabela exibe os tempos e posições do trecho selecionado, e ao selecionar Geral volta ao acumulado.
Cobre: RF-PUB-006.
Como testar: buscar pelo numeral de um competidor presente no evento.
Passa quando: a tabela destaca ou filtra esse competidor.
Cobre: RF-PUB-007.
Como testar: tocar um competidor da classificação, com e sem um trecho com parciais selecionado, incluindo um caso com posIx nulo.
Passa quando: o modal mostra equipe, veículo, categoria, posição, penalidades, tempo total e o tempo por especial SS1 a SSN; com trecho de parciais, mostra também I1 a I7 com deltas e posições, ocultando as sem indicador; o modal fecha sem recarregar a página.
Cobre: RF-PUB-008.
Como testar: abrir a central com um evento com documentos publicados e com um evento sem nenhum.
Passa quando: cada documento aparece como botão de download com título e link funcional; sem documentos, a central exibe estado vazio sem erro.
Cobre: RF-PUB-009.
Como testar: permanecer na página de um evento ao vivo e depois marcar o evento como encerrado.
Passa quando: os dados se atualizam automaticamente a cada cerca de 30 segundos com o indicador "ao vivo"; ao encerrar, o indicador muda para "encerrado" e a atualização automática para.
Cobre: RF-PUB-010.
Como testar: abrir a página de um evento de cada uma das quatro verticais (Series, Petrobras, MTB, Kitesurf) e comparar lado a lado.
Passa quando: a cor de destaque é o laranja oficial E96409 em Series e em Petrobras (que compartilham a cor e se distinguem pela marca), o rosa oficial E40E7F em MTB e o verde oficial 88BD23 em Kitesurf, cada uma sobre o fundo escuro comum conforme o Ap.4 do DRS, E nenhuma das quatro verticais exibe a marca ou a capa de outra.
Cobre: RF-PUB-011.
Como testar: abrir a página de um evento ao vivo e de um evento encerrado.
Passa quando: o cabeçalho exibe a barra na cor da marca, o logotipo oficial, a navegação e o selo "Ao Vivo" pulsante quando ao vivo; quando encerrado, o selo não pulsa.
Cobre: RF-PUB-012.
Como testar: abrir a página de um evento publicado e trocar de aba de modalidade.
Passa quando: o hero mostra nome e subtítulo do evento, as abas de modalidade com contador de competidores, a faixa de etapas com a visão Geral em destaque e cada trecho com nome, distância e estado (incluindo o Prólogo), e o indicador "atualizado há X"; ao trocar de aba, a página reflete a modalidade escolhida.
Cobre: RF-PUB-013.
Como testar: aplicar e limpar um filtro de categoria e uma busca.
Passa quando: o contador de competidores reflete a quantidade exibida no recorte ativo.
Cobre: RF-PUB-014.
Como testar: rolar até o fim de qualquer página de resultados publicada.
Passa quando: o rodapé exibe "Cronometragem por Chronosat" e "Desenvolvido por Modulareasy".
Cobre: RF-PUB-015.
Como testar: abrir a home de uma vertical (/<vertical>) com um ou mais eventos publicados, ao vivo e arquivados, e conferir a URL de um evento no padrão /<vertical>/<ano>/<evento>.
Passa quando: a home da vertical mostra a capa com a identidade do esporte, o evento ao vivo sinalizado em destaque quando houver, e a lista das edições por ano; escolher uma leva à página daquele evento nesse endereço; nenhuma outra vertical aparece nessa home.
Cobre: RF-PUB-016.
Como testar: abrir a raiz do subdomínio de resultados com as quatro verticais cadastradas.
Passa quando: a raiz mostra a lista dos sites das verticais (nome, marca e cor de cada uma) na ordem configurada, ao escolher uma o público é levado à home daquela vertical, e a home global não mistura classificações nem eventos de esportes diferentes.
REGRA, regras de interpretação dos dados
Cobre: RF-REGRA-001.
Como testar: usar um competidor com penais igual a " *" de um JSON real.
Passa quando: a célula de penalidades exibe o traço de ausência e não o texto literal *.
Cobre: RF-REGRA-002.
Como testar: usar um competidor com posI5 nulo num JSON real e abrir a janela de parciais.
Passa quando: a posição da parcial 5 não aparece e as demais parciais com posição aparecem normalmente.
Cobre: RF-REGRA-003.
Como testar: num evento com prólogo realizado, conferir o acumulado geral.
Passa quando: o tempo do prólogo não é somado ao tempo total, e o prólogo permanece consultável como trecho próprio.
Cobre: RF-REGRA-004.
Como testar: usar um competidor com tempo de especial 9000.00 ou tempo total 27000.00 de um JSON real.
Passa quando: o sistema exibe "Não completou" no lugar do número e mantém a posição conforme a ordenação aplicável.
Cobre: RF-REGRA-005.
Como testar: usar um competidor com L igual a 25680.00 de um JSON real.
Passa quando: o sistema interpreta o valor como segundos desde a meia-noite (07:08:00) para auditoria, sem confundir com tempo de prova.
Cobre: RF-REGRA-006.
Como testar: usar um competidor com _status igual a O de um JSON real.
Passa quando: esse competidor não aparece na página pública e os demais aparecem normalmente.
PAINEL, painel de gestão
Cobre: RF-PAINEL-001 na sua primeira versão (login único), como entregue em F3-01.
Como testar: tentar acessar uma rota do painel sem login, e depois com a credencial válida.
Passa quando: sem credencial o visitante é barrado; com a credencial válida, acessa as telas de gestão.
Nota: este card cobre a primeira versão (login único). A autenticação por conta nominal com papel (RF-PAINEL-001 revisado) é coberta por {TA-48B}; a evolução ainda não foi implementada.
Cobre: RF-PAINEL-001 revisado, RNF-SEG-002, RNF-SEG-005.
Como testar: entrar com uma conta de administrador e com uma de operador; tentar com senha errada; tentar com uma conta desativada; tentar uma rota do painel sem sessão.
Passa quando: cada conta ativa entra e a sessão carrega o papel certo; senha errada e conta desativada são recusadas; visitante sem sessão é barrado; nenhuma senha trafega ou fica guardada em texto puro (só hash).
Cobre: RF-PAINEL-002.
Como testar: iniciar um novo campeonato e selecionar vertical e nome.
Passa quando: o sistema registra a vertical (com sua cor e marca) e o nome, e habilita o passo 2.
Nota (2026-07-05, S64): provado ponta a ponta: vertical lida do banco (select real), rascunho criado no banco, redirecionamento 302 ao passo 2, passo 2 mostra o perfil da vertical escolhida, validações rejeitam campos vazios, entrada maliciosa (XSS) escapada, 586/586 testes verdes.
Cobre: RF-PAINEL-003.
Como testar: colar de uma vez o bloco inteiro de URLs de um evento válido (crews, racetimes e stagetimes de todas as modalidades e trechos) e acionar "testar conexão"; repetir com uma URL inválida ou inacessível no meio do bloco; incluir um arquivo de trecho ainda não iniciado (que retorna vazio).
Passa quando: o sistema extrai e classifica automaticamente cada URL pelo padrão do nome do arquivo, sem o operador separar campo a campo, e a pré-visualização mostra a contagem de modalidades, trechos e competidores encontrados; com URL inválida, exibe qual falhou sem publicar; o arquivo de trecho vazio é aceito e não bloqueia o teste.
Cobre: RF-PAINEL-004.
Como testar: concluir os passos 1 e 2 com teste de conexão bem sucedido e publicar.
Passa quando: o evento fica disponível na página pública da vertical correspondente, no estado inicial configurado.
Nota (2026-07-05, S66): provado com smoke visual real (desktop 1280 e mobile 390): evento de teste publicado apareceu na página pública e como 2º card, AO VIVO, na home da vertical, ao lado do evento real, sem regressão; deletado nominalmente após o smoke.
Cobre: RF-PAINEL-005.
Como testar: marcar um campeonato publicado como encerrado, e depois como ao vivo novamente.
Passa quando: ao encerrar, a página para a atualização automática e exibe o indicador de encerrado; ao voltar para ao vivo, a atualização automática retorna.
Cobre: RF-PAINEL-006.
Como testar: adicionar um PDF por link e outro por upload de arquivo, cada um com título, e depois remover um.
Passa quando: cada PDF adicionado por link ou por upload aparece na central de downloads pública; ao remover, deixa de aparecer.
Cobre: RF-PAINEL-007.
Como testar: ocultar um competidor exibido na página e depois reexibi-lo.
Passa quando: oculto, ele deixa de aparecer na página pública; reexibido, volta a aparecer.
Cobre: RF-PAINEL-008.
Como testar: abrir o painel com um ou mais campeonatos cadastrados.
Passa quando: a lista mostra vertical, nome, estado (rascunho, ao vivo, encerrado) e as ações de editar, publicar, alternar estado e gerenciar PDFs.
Cobre: RF-PAINEL-009.
Como testar: encerrar um evento ao vivo e, em seguida, simular a Chronosat retirando os dados da origem.
Passa quando: o sistema grava o resultado final num arquivo permanente e a página continua exibindo esse arquivo mesmo com a origem fora do ar, permanecendo acessível no endereço por evento e ano e listada na home.
Cobre: RF-PAINEL-010.
Como testar: cadastrar pelo assistente um evento de uma edição passada, a partir de URLs ou arquivos históricos.
Passa quando: a página daquela edição é gerada e arquivada no endereço por evento e ano, e passa a aparecer na home junto às demais.
Cobre: RF-PAINEL-011.
Como testar: com um administrador, criar uma conta de operador com senha inicial e confirmar que ela entra; mudar o papel de uma conta e confirmar que o acesso muda; desativar uma conta e confirmar que ela não entra mais e que o histórico dela permanece, depois reativá-la; redefinir a senha de uma conta e confirmar que a nova vale e a antiga não.
Passa quando: cada operação (criar, mudar papel, desativar/reativar, redefinir senha) tem o efeito esperado no acesso da conta, sem apagar o histórico, e nenhuma senha é exibida nem guardada em texto puro; não há autocadastro público.
Cobre: RF-PAINEL-012, RNF-SEG-004.
Como testar: com um administrador, executar ações sensíveis (login, criar conta, mudar papel, desativar conta, redefinir senha) e depois abrir a tela de auditoria; tentar (sem sucesso) editar um registro.
Passa quando: cada ação gera um registro com quem fez, o que fez, sobre o que e quando; a tela lista os registros do mais recente ao mais antigo; a redefinição de senha registra a troca sem o valor da senha; o log é imutável (não editável pelo painel).
Cobre: RF-PAINEL-001 revisado, RF-PAINEL-011, RF-PAINEL-012, RF-PAINEL-013, RNF-SEG-003.
Como testar: entrar com uma conta de papel operador e tentar abrir a tela de gestão de contas, a de auditoria e a de monitor de status (por menu e pela rota direta); entrar com uma conta de papel administrador e abrir as mesmas telas.
Passa quando: o operador não vê os itens de menu Contas, Auditoria e Status das páginas e é barrado ao tentar as rotas diretas; o administrador vê e acessa as três telas; nenhuma tela de gestão de campeonatos fica vedada ao administrador.
Cobre: RF-PAINEL-013.
Como testar: com um administrador, abrir a tela de monitor de status e conferir a lista curada de rotas com o código de resposta de cada uma; provocar uma rota no ar e confirmar que aparece 200; apontar (ou simular) uma rota inexistente ou fora do ar e confirmar que aparece com o código de erro (por exemplo 404 ou 503) sinalizado; acionar "verificar de novo" e confirmar que os códigos são reconsultados; conferir que nenhuma rota por evento aparece na lista; tentar (sem sucesso) abrir a tela com um papel operador.
Passa quando: a tela mostra a lista curada de rotas com um código HTTP por linha; uma rota no ar aparece como 200 e uma com erro aparece com o código do erro em destaque; "verificar de novo" reconsulta; a lista não inclui nenhuma rota por evento (só as principais curadas); o operador é barrado; e a verificação de uma rota que não responde é reportada como erro sem derrubar a tela.
CONFIG, multi-evento e multi-vertical
Cobre: RF-CONFIG-001.
Como testar: consultar e ajustar, para uma vertical existente, todos os campos do perfil: cor de destaque, marca, capa da home (título, subtítulo, imagem), rótulos da hierarquia (modalidade, categoria, trecho), regra de exibição da tripulação e ordem na home global; em seguida adicionar uma vertical nova só por configuração.
Passa quando: cada campo do perfil é visível e editável, a mudança reflete no site daquela vertical sem novo deploy, e uma vertical nova pode ser adicionada sem alteração de código.
Cobre: RF-CONFIG-002.
Como testar: publicar um evento em Rally e outro em MTB ao mesmo tempo e abrir a página de cada vertical.
Passa quando: cada vertical exibe seu próprio evento com sua identidade, sem interferência entre elas.
Cobre: RF-CONFIG-003.
Como testar: configurar um evento com uma modalidade só (por exemplo só carros) e outro evento com várias modalidades diferentes das do primeiro (por exemplo caminhão e production), com URLs próprias em cada, e alternar o filtro de modalidade em cada evento; conferir o rótulo de cada modalidade vindo de crews e o caso de ajuste manual do rótulo pelo operador.
Passa quando: o número de modalidades nunca é fixo (um evento com uma só e outro com várias funcionam igualmente), cada modalidade guarda suas URLs de crews, racetimes e stagetimes por trecho com seu rótulo, o rótulo reflete o crews ou o ajuste do operador quando aplicável, e o sistema lê a fonte correta conforme o filtro.
Cobre: RF-CONFIG-004.
Como testar: com a vertical Series já publicada e no ar, cadastrar a vertical Petrobras do zero pelo painel (perfil próprio de RF-CONFIG-001) e um evento dela pelo assistente, sem tocar em código nem duplicar o sistema.
Passa quando: o site da vertical Petrobras fica no ar com identidade, home e eventos próprios, nenhuma linha de código foi alterada ou copiada, e a vertical Series continua funcionando normalmente e sem nenhuma mistura de identidade entre as duas.
Cobre: RF-CONFIG-005.
Como testar: publicar um evento e conferir o endereço gerado no padrão resultados.sertoes.com.br/<vertical>/<ano>/<evento>; publicar um segundo evento da mesma vertical no mesmo ano com nome diferente e conferir que o endereço distingue os dois.
Passa quando: cada evento recebe um endereço permanente com o nome do evento na slug que não muda depois, dois eventos da mesma vertical no mesmo ano têm endereços distintos, e a home e as páginas da vertical no site apontam para esse endereço.
Prova (S72 2026-07-06): test/f3-12-endereco-permanente.test.ts, 9 casos (C1 endereço no padrão mais o passo 3 do assistente; C2 comportamental de publicar, encerrar e reativar; C2 estrutural varrendo a lista de módulos exportados em busca de qualquer caminho de mutação da identidade do evento; C3 trilha de navegação e cabeçalho apontando para o endereço canônico; C4 fumaça), somados às provas de colisão já existentes em test/eventos-crud e test/eventos-route. 739 de 739 testes node:test passando.
Gerais Alfa
Cobre: RF-CONFIG-004, RF-CONFIG-002, ADR-010, transversal ao módulo CONFIG.
Como testar: com a vertical Series publicada e um evento dela ao vivo, cadastrar a vertical Petrobras do zero apenas por configuração (perfil, sem alteração de código) e publicar um evento dela em paralelo; navegar entre os dois sites e o painel único.
Passa quando: o site da Petrobras nasce com identidade, home e regra de exibição próprias, nenhuma linha de código foi alterada ou copiada, os dois eventos convivem sem interferência (nenhum dado ou identidade de uma vertical vaza para a outra), e o operador administra as duas no mesmo painel com um único login.
Cobre: ADR-012, RF-INGEST-004, RF-INGEST-005, transversal.
Como testar: alimentar o sistema com um arquivo de teste contendo um campo desconhecido (fora do contrato do Ap.1), um arquivo com um campo esperado ausente, e um arquivo com mais parciais (IX) do que o usual; em seguida, alimentar com um pacote estruturalmente divergente do contrato conhecido (ex.: um formato de tripulação diferente do esperado).
Passa quando: nos três primeiros casos a página não quebra, exibe o que existe (o campo desconhecido é ignorado na tela mas preservado no banco; o campo ausente apenas omite o elemento; parciais a mais aparecem normalmente pelo padrão de nome); no caso do pacote divergente, o teste de conexão aponta ao operador exatamente o que divergiu, o dado é armazenado mesmo assim, e a página exibe uma tabela genérica sinalizada em vez de quebrar ou renderizar errado.
Cobre: RF-INGEST-003.
Como testar: simular a Chronosat indisponível já no primeiro acesso a um evento recém-publicado, antes de qualquer leitura bem-sucedida (sem cache ainda formado).
Passa quando: a página exibe um estado de "aguardando dados", nunca um erro cru nem uma página em branco.
Cobre: transversal (RF-PUB, Ap.4, Ap.5).
Como testar: abrir a página no celular (prioridade) e no desktop, para um evento de cada vertical, e conferir tela a tela: cabeçalho, hero, pódio, filtros, tabela ou cartões, modal de detalhe, central de documentos, rodapé, comparando com o protótipo aprovado.
Passa quando: todas as seções aparecem corretas, legíveis e com a identidade da vertical, em celular e desktop, sem elemento cortado, sobreposto ou quebrado.
Cobre: RNF-SEG-001, RF-PAINEL-001.
Como testar: tentar acessar o painel sem login; tentar acessar as URLs da Chronosat diretamente pelo navegador do público.
Passa quando: o painel exige autenticação em toda rota de gestão, e o público não consegue acessar satcron.com diretamente nem qualquer tela do painel.
Cobre: RNF-PERF-001, RNF-PERF-002, RNF-ESC-001, RF-INGEST-002.
Como testar: medir o carregamento da primeira tela útil no celular durante um pico simulado de acessos, e confirmar que as leituras da origem não excedem uma por minuto por arquivo.
Passa quando: a página carrega rápido mesmo sob pico, servindo do cache, e a Chronosat recebe no máximo uma chamada por minuto por arquivo.
Cobre: RNF-RESP-001.
Como testar: abrir todas as telas públicas no celular, incluindo a virada da tabela em cartões e o empilhamento do pódio de cinco lugares.
Passa quando: todas as telas funcionam corretamente no celular, com a tabela em cartões e o pódio empilhado em ordem de 1 a 5, e continuam corretas no desktop.
Cobre: transversal.
Como testar: trocar de modalidade, de categoria e de trecho em sequência, várias vezes, e conferir que nenhuma combinação anterior quebra ou apresenta dado de outra combinação.
Passa quando: a troca de modalidade, categoria ou trecho nunca deixa dado residual de outro recorte nem quebra a página.
Cobre: o uso real do sistema pelas jornadas de cada papel (sanity de uso).
Como testar: percorrer cada jornada de cada papel usando a ferramenta de verdade, não apenas abrir as telas: completar o fluxo do início ao resultado, conferir tabelas com dado real, botões que executam e formulários que persistem.
Passa quando: toda jornada de todo papel completa do início ao resultado, sem elemento quebrado.
Cobre: o grafo de navegação de toda tela alcançada nas jornadas.
Como testar: de cada tela em que se cai, encontrar o caminho de volta pela própria interface (trilha, botão voltar da aplicação, menu ou link de origem).
Passa quando: nunca é preciso o voltar do navegador nem redigitar a URL para retornar, e nenhum item de menu leva a "sem permissão" para o próprio papel.
Cobre: a autonomia de cada papel conforme o RBAC e o DRS.
Como testar: com cada papel, executar criar, ler, atualizar e apagar em tudo que a especificação diz que ele pode, incluindo o super admin nas estruturas que são responsabilidade dele.
Passa quando: cada papel realiza todo o CRUD previsto e nada que a especificação libera aparece bloqueado.
Beta (testes com o cliente)
Público
Cobre: a jornada Acompanhar a classificação ao vivo (documento de Jornadas).
Quem testa: usuário real do público, pelo celular.
Como validar: o usuário entra pelo site da vertical (a home do esporte) ou direto no endereço do evento, e acompanha a classificação se atualizando sozinha durante um evento ao vivo.
Passa quando: completa sem bloqueio, confirma que chegou à página certa a partir do site da vertical, e confirma que a classificação faz sentido e se atualiza sem precisar recarregar.
Cobre: a jornada Trocar de modalidade.
Quem testa: usuário real do público.
Como validar: o usuário alterna entre as abas de modalidade do evento.
Passa quando: completa sem bloqueio e confirma que cada aba mostra a modalidade correta com o número certo de competidores.
Cobre: a jornada Ver o pódio.
Quem testa: usuário real do público.
Como validar: o usuário localiza e interpreta o pódio dos cinco primeiros de um recorte.
Passa quando: completa sem bloqueio e confirma que reconhece os cinco primeiros na ordem correta.
Nota (2026-07-04): pódio por recorte selecionado (categoria, etapa) agora tecnicamente no ar (F2-06 entregue); falta a validação Beta com usuário real do papel Público para fechar este item, que exige alguém de fora testando a jornada, não só a capacidade técnica confirmada no Alfa.
Cobre: a jornada Filtrar por categoria ou trecho e buscar um competidor.
Quem testa: usuário real do público.
Como validar: o usuário filtra por categoria, seleciona um trecho e busca um competidor pelo numeral.
Passa quando: completa sem bloqueio e confirma que os resultados batem com o filtro escolhido em cada caso.
Cobre: a jornada Ver o detalhe de um competidor.
Quem testa: usuário real do público.
Como validar: o usuário toca um competidor e explora o modal de detalhe, com e sem trecho selecionado.
Passa quando: completa sem bloqueio e confirma que os dados do modal são claros e o fechamento não recarrega a página.
Cobre: a jornada Baixar um documento oficial.
Quem testa: usuário real do público.
Como validar: o usuário abre a Central de Documentos Oficiais e baixa um PDF disponível.
Passa quando: completa sem bloqueio e confirma que o arquivo baixado é o esperado.
Cobre: a home da vertical (arquivo por ano) e o endereço permanente por vertical, ano e evento.
Quem testa: usuário real do público.
Como validar: o usuário abre a home de uma vertical (o site do esporte) e navega até um evento arquivado de uma edição anterior.
Passa quando: completa sem bloqueio e confirma que a página arquivada mostra o resultado final congelado, e que a home lista as edições por ano daquela vertical.
Cobre: a home global enxuta, RF-PUB-010, RF-PUB-015, RF-PUB-016.
Quem testa: usuário real do público.
Como validar: o usuário parte da home global (a raiz do subdomínio) ou de um link externo, escolhe uma vertical diferente da que estava acompanhando e navega pelo site daquele esporte.
Passa quando: completa sem bloqueio e confirma que reconhece o site da nova vertical como um site próprio (cor, marca e capa diferentes), sem nenhum resquício visual ou de dado da vertical anterior.
Cobre: a jornada Acompanhar quando a origem oscila.
Quem testa: usuário real do público, durante uma oscilação real ou simulada da fonte.
Como validar: o usuário permanece na página enquanto a fonte de dados fica temporariamente indisponível.
Passa quando: completa sem bloqueio e confirma que a página não quebra nem fica em branco, mostrando o último resultado válido com aviso.
Operador
Cobre: a jornada Preparar um novo campeonato.
Quem testa: o operador real da Sertões.
Como validar: o operador recebe as URLs da Chronosat e abre o painel autenticado para iniciar o cadastro.
Passa quando: completa sem bloqueio e confirma que o acesso e o início do assistente são claros.
Nota (2026-07-05, S66): o assistente completo (passos 1, 2 e 3: F3-03, F3-04, F3-05) está construído e provado no Alfa ({TA-32}, {TA-33}, {TA-43}, {TA-34}). Segue aberta porque este card é validado pelo operador real da Sertões (Beta), não por teste interno.
Cobre: a jornada Passo 1, escolher a vertical e nomear.
Quem testa: o operador real da Sertões.
Como validar: o operador seleciona a vertical e nomeia o campeonato.
Passa quando: completa sem bloqueio e confirma que a vertical escolhida traz a cor e a marca certas.
Nota (2026-07-05, S66): passos 1, 2 e 3 entregues e provados no Alfa ({TA-32}, {TA-33}, {TA-43}, {TA-34}); este card Beta aguarda o teste real do operador da Sertões (não é validação interna), por isso segue aberto até a rodada Beta.
Cobre: a jornada Passo 2, colar as URLs e testar a conexão.
Quem testa: o operador real da Sertões, sem apoio técnico durante o teste.
Como validar: o operador cola as URLs recebidas e aciona "testar conexão".
Passa quando: completa sem bloqueio e confirma que a pré-visualização (trechos e competidores encontrados) é compreensível sem explicação técnica.
Cobre: a jornada Passo 3, publicar.
Quem testa: o operador real da Sertões.
Como validar: o operador confere o resumo e publica o campeonato.
Passa quando: completa sem bloqueio e confirma que o evento aparece na página pública da vertical correta.
Nota (2026-07-05, S66): o passo 3 (F3-05) está entregue e provado no Alfa ({TA-34}, smoke visual real); este card Beta aguarda o teste real do operador da Sertões, por isso segue aberto até a rodada Beta.
Cobre: a jornada Controlar o estado durante e depois da prova.
Quem testa: o operador real da Sertões, durante um evento real.
Como validar: o operador mantém o evento ao vivo durante a prova e o marca como encerrado ao final.
Passa quando: completa sem bloqueio e confirma que a mudança de estado reflete corretamente na página pública.
Cobre: RF-PAINEL-009, RF-INGEST-005, a fase de encerramento dentro da jornada Controlar o estado.
Quem testa: o operador real da Sertões, com evento real ou de teste.
Como validar: o operador encerra o evento e, depois, verifica a página com a origem da Chronosat já fora do ar; o operador também é informado de que, mesmo que esqueça de encerrar antes de a origem sair do ar, nada se perde (cada leitura já ficou salva ao longo da prova).
Passa quando: completa sem bloqueio, confirma que a página segue publicada com o resultado final no endereço por vertical, ano e evento, e confirma que entendeu que encerrar é só parar de buscar (não existe cópia nem risco de perda mesmo sem encerrar a tempo).
Cobre: a jornada de cadastro de uma edição passada (RF-PAINEL-010), complemento do arquivamento contínuo (RF-PAINEL-009) que é o caminho principal do histórico, como publicar um post antigo num blog.
Quem testa: o operador real da Sertões.
Como validar: o operador cadastra pelo mesmo assistente de sempre uma edição passada a partir dos dados históricos disponíveis, marcando-a como já encerrada.
Passa quando: completa sem bloqueio e confirma que a página daquela edição é gerada, congelada e arquivada no endereço por vertical, ano e evento, e aparece corretamente na home junto às demais.
Cobre: a jornada Gerir os PDFs oficiais.
Quem testa: o operador real da Sertões.
Como validar: o operador adiciona um documento oficial por link e outro por upload, e depois remove um.
Passa quando: completa sem bloqueio e confirma que cada forma (link e upload) funciona e o documento aparece e some corretamente na página pública.
Cobre: a jornada Ocultar um competidor.
Quem testa: o operador real da Sertões.
Como validar: o operador busca um competidor pelo numeral, oculta e depois reexibe.
Passa quando: completa sem bloqueio e confirma que a ocultação e a reexibição refletem corretamente na página pública.
Cobre: a jornada Gerir as verticais, RF-CONFIG-001, RF-CONFIG-004.
Quem testa: o operador real da Sertões.
Como validar: o operador edita o perfil completo (cor, marca, capa, rótulos, regra de tripulação) de uma vertical existente, e cadastra a vertical Petrobras do zero apenas por configuração, sem apoio de desenvolvimento.
Passa quando: completa sem bloqueio, confirma que a edição se reflete na página pública sem depender de desenvolvimento, e confirma que conseguiu criar a vertical Petrobras sozinho, com identidade própria, sem pedir ajuda técnica.
Administrador
Cobre: as jornadas do Administrador (entrar com a própria conta, e o acesso às telas de administração), RF-PAINEL-001 revisado.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador entra no painel com a sua conta nominal e confirma que vê, além das telas de gestão de campeonatos, os itens de Contas e Auditoria.
Passa quando: completa sem bloqueio e confirma que o acesso é pela mesma porta autenticada, com a sua credencial própria, e que as telas de administração aparecem.
Nota (S62): capacidade no ar (contas nominais, papel na sessão, telas de Contas e Auditoria visíveis ao administrador); aguarda beta com administrador real.
Cobre: as jornadas de gestão de contas (criar conta, editar papel, desativar/reativar, redefinir senha), RF-PAINEL-011.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador cria uma conta de operador para a equipe da Sertões, redefine a senha de uma conta que "esqueceu", e desativa uma conta que não precisa mais de acesso.
Passa quando: completa sem bloqueio e confirma que cada ação teve o efeito esperado (a conta nova entra, a senha redefinida passa a valer, a conta desativada não entra e o histórico dela permanece), sem precisar de apoio técnico.
Nota (S62): capacidade no ar (tela de gestão de contas com criar, editar papel, desativar/reativar, redefinir senha); aguarda beta com administrador real.
Cobre: a jornada de consulta ao log de auditoria, RF-PAINEL-012.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: depois de algumas ações no painel, o administrador abre a tela de auditoria e procura por uma ação específica.
Passa quando: completa sem bloqueio e confirma que consegue ver quem fez, o que fez, sobre o que e quando, do mais recente ao mais antigo, de forma compreensível.
Nota (S62): capacidade no ar (auditoria imutável gravando login, gestão de contas e mudanças de papel); aguarda beta com administrador real.
Cobre: a jornada Consultar o status das páginas (documento de Jornadas), RF-PAINEL-013.
Quem testa: um administrador real (equipe Modulareasy).
Como validar: o administrador abre a tela de sitemap e monitor de status para conferir se as páginas principais do sistema e do site estão no ar, e aciona "verificar de novo".
Passa quando: completa sem bloqueio e confirma que enxerga a lista curada de rotas com o código de cada uma (no ar ou com erro), entende de relance o que está no ar e o que está com problema, e reconsulta quando quer, sem precisar de apoio técnico.
Nota (S62): capacidade no ar (tela de sitemap e monitor de status, lista curada, botão verificar de novo); aguarda beta com administrador real.
Sustentação
Cobre: a jornada Provisionar e manter o servidor.
Quem testa: a equipe de sustentação (Modulareasy).
Como validar: provisionar o servidor dedicado isolado, configurar a borda e fazer o deploy do aplicativo.
Passa quando: completa sem bloqueio e o ambiente fica saudável e isolado dos demais produtos.
Cobre: a jornada Monitorar a saúde do sistema.
Quem testa: a equipe de sustentação (Modulareasy), durante um evento ao vivo real.
Como validar: acompanhar a disponibilidade da página, a saúde do intermediário de leitura, o sucesso das leituras da Chronosat e o estado do cache durante a prova.
Passa quando: completa sem bloqueio e confirma visibilidade suficiente para detectar um problema antes que o público perceba.
Cobre: a jornada Responder a incidente ao vivo.
Quem testa: a equipe de sustentação (Modulareasy), com uma queda real ou simulada da origem durante um evento.
Como validar: confirmar que a página segue servida do último estado salvo no banco e que o restabelecimento do serviço ocorre sem intervir na operação do conteúdo dos eventos.
Passa quando: completa sem bloqueio e a página nunca quebra durante o incidente, mesmo com a origem indisponível.
Coleta de feedback Beta
Cobre: a navegação das jornadas na perspectiva do usuário real.
Quem testa: cliente ou usuário real do papel.
Como validar: o usuário percorre suas jornadas e retorna às telas anteriores sempre pela interface.
Passa quando: o usuário confirma que nunca ficou preso numa tela sem caminho de volta.
Cobre: o Aprendizado Pós-Lançamento do DRS.
Quem testa: operador e sustentação, observando o público.
Como validar: observar o primeiro evento ao vivo publicado de ponta a ponta e registrar os ajustes necessários no painel e na exibição pública.
Passa quando: a observação está registrada, com os ajustes identificados encaminhados como pendência de melhoria, sem bloquear a operação do evento em curso.
Cobre: o Aprendizado Pós-Lançamento do DRS.
Quem testa: operador e sustentação.
Como validar: aplicar os ajustes levantados na coleta de feedback e confirmar com o operador que resolveram o incômodo observado.
Passa quando: os ajustes identificados foram aplicados e confirmados pelo operador, sem reabrir os itens já aprovados na seção Alfa.
Cada item Alfa só passa quando o H1 do seu requisito passa; um requisito sem H1 verificado não está pronto. A entrega ao público só ocorre com a seção Alfa inteira concluída e a seção Beta observada em um evento real.