Casos de teste XML TISS bem definidos ajudam a equipe a verificar uma mudança interna com arquivos representativos, sem expor dados sensíveis, e a registrar evidências para decidir entre liberar, corrigir ou investigar o fluxo.
Um caso de teste XML TISS não é apenas um arquivo criado para “passar no validador”. Ele é um registro planejado que responde a uma pergunta objetiva sobre uma alteração: um novo campo foi preenchido como esperado? A regra de montagem preservou a estrutura do documento? Um cenário antes aceito agora apresenta comportamento diferente? Ao definir cenário, dados fictícios, resultado esperado e evidência, a equipe transforma a validação interna em uma atividade repetível e comparável. Isso reduz a dependência de memória, evita testar somente o caminho mais simples e permite explicar por que uma alteração foi liberada, corrigida ou encaminhada para investigação.
Neste artigo
Comece pela pergunta que o teste precisa responder
Antes de gerar qualquer XML, escreva uma pergunta verificável e limitada. “Testar o faturamento” é amplo demais; “confirmar se a inclusão de um item adicional mantém a estrutura prevista para este cenário de guia” é uma pergunta que pode receber um resultado claro. O caso deve cobrir uma mudança, uma combinação relevante de condições ou um risco conhecido do processo, e não tentar demonstrar tudo de uma vez.
Perguntas úteis para orientar a seleção
- O XML gerado após a alteração contém os grupos e campos previstos para o cenário escolhido?
- O comportamento é o mesmo para um registro mínimo e para um registro com repetição de itens?
- A troca de versão configurada no ambiente foi aplicada ao arquivo de teste?
- Uma falha proposital é identificada e registrada de forma compreensível pela equipe?
- Após a correção, o mesmo caso deixa de apresentar a falha inicialmente observada?
O que a validação interna confirma — e o que ela não confirma
A validação interna pode demonstrar, dentro do ambiente e dos critérios escolhidos pela organização, como o sistema montou determinado arquivo e se a correção alterou o resultado observado. Ela não equivale a aceite de uma operadora, não comprova processamento posterior e não substitui regras contratuais, operacionais ou de relacionamento aplicáveis ao faturamento. Trate o resultado como evidência técnica interna: útil para controlar mudanças, mas delimitada pelo cenário e pela ferramenta usados.
O padrão TISS reúne componentes organizacional, de conteúdo e estrutura, de representação de conceitos em saúde, de segurança e privacidade e de comunicação. (Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar) A ANS informa que o componente de conteúdo e estrutura trata da arquitetura dos dados nas mensagens eletrônicas, enquanto o componente de comunicação adota XML como linguagem de marcação. Por isso, ao preparar o teste, registre separadamente a versão XML TISS adotada, os arquivos de referência consultados e as regras locais que não pertencem ao padrão. (Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar)
Depois de delimitar o papel dos casos de teste, conecte-os a uma rotina de validação do XML TISS mais ampla. A rotina cobre a conferência recorrente do arquivo; o caso de teste acrescenta rastreabilidade para uma mudança ou situação específica.
Escolha cenários representativos em vez de muitos arquivos parecidos
A representatividade vem da diferença entre as condições dos casos, não do volume de cópias quase idênticas. Primeiro, relacione o que mudou: regra de preenchimento, mapeamento de dado, montagem de item, sequência de grupos, parametrização de versão ou tratamento de uma condição excepcional. Em seguida, escolha casos que exponham essas diferenças. Um conjunto inicial equilibrado costuma conter um caminho usual, um caso mínimo, um caso com repetição, uma condição de fronteira e um caso negativo controlado.
Conjunto enxuto de cenários
- Caminho usual: uma guia fictícia com a combinação mais frequente de dados do processo
- Caso mínimo: somente os elementos necessários para responder à pergunta de teste
- Repetição: mais de um item, procedimento ou ocorrência quando a alteração alcança coleções
- Fronteira: data, quantidade, valor ou combinação de preenchimento próxima do limite definido pela regra em análise
- Negativo controlado: uma alteração deliberada e documentada para verificar se a inconsistência é percebida
- Regressão: um arquivo que já funcionava antes da mudança e deve manter o comportamento esperado
Use dados fictícios e reduza a exposição de informações
Planeje o arquivo de teste para reproduzir a forma necessária ao cenário, não uma ocorrência real. Use nomes claramente artificiais, identificadores internos não vinculados a pessoas, datas de teste, endereços não reais e valores criados para o exercício. Não copie guias de produção e não considere a simples troca de nome uma anonimização suficiente: combinações de identificadores, datas, procedimentos e outros atributos podem continuar permitindo associação indevida. Se um dado real tiver sido incluído por engano, interrompa o compartilhamento do arquivo, siga o procedimento interno de tratamento e gere um novo artefato de teste. (Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar)
Regras práticas para a base de teste
- Mantenha uma fonte controlada de dados sintéticos aprovada pela equipe
- Identifique cada registro fictício com convenção visível, como TESTE ou HOMOLOGAÇÃO INTERNA
- Separe credenciais, pastas e permissões do ambiente de teste das usadas em produção
- Evite anexar arquivos de teste a chamados, e-mails ou planilhas sem revisar o conteúdo
- Registre a origem do caso como dado sintético e não como guia copiada de atendimento
- Exclua versões descartadas conforme a política interna de retenção
Monte uma matriz de casos com critério e evidência
A matriz é o ponto de controle que impede que um arquivo isolado perca seu contexto. Ela pode ficar em planilha, ferramenta de chamados ou repositório de testes, desde que cada linha mantenha um identificador único e a ligação com o arquivo gerado. Não use a matriz apenas como lista de “aprovado” e “reprovado”: descreva a regra observada, o resultado esperado e a evidência que permite outra pessoa repetir a análise.
Modelo de matriz para casos de teste XML TISS
| Campo | Como preencher | Exemplo de registro |
|---|---|---|
| ID do caso | Código único e estável | CT-XML-014 |
| Mudança ou risco | O que motivou o teste | Ajuste no mapeamento de item repetido |
| Cenário | Condições que o arquivo representa | Guia fictícia com dois itens |
| Versão e ambiente | Configuração usada no teste | Versão configurada no ambiente interno |
| Resultado esperado | Critério objetivo de comparação | Dois itens gerados na estrutura prevista |
| Evidência | Localizador do XML, saída e registro de execução | Nome do arquivo, data e protocolo interno |
| Status | Situação atual e responsável | Falha identificada; encaminhada para correção |
Registre a execução, a falha e a nova validação
Um registro de falhas de validação XML TISS deve separar fato observado de hipótese. Fato é o que a equipe consegue reproduzir: identificador do caso, versão usada, data de execução, arquivo, critério esperado, resultado obtido e mensagem retornada pela ferramenta. Hipótese é a possível causa: campo não mapeado, ordem alterada, regra de negócio local, configuração de ambiente ou interpretação inadequada do requisito. Essa separação evita que uma suposição seja tratada como solução antes da investigação.
Informações que devem acompanhar a nova conferência
- ID do caso original e referência da falha anterior
- Descrição objetiva da correção aplicada
- Versão do sistema, configuração ou pacote avaliado
- Data, responsável e ambiente de execução
- Novo arquivo XML gerado a partir dos mesmos dados sintéticos, quando aplicável
- Resultado esperado preservado ou justificativa para sua alteração
- Resultado obtido e evidência associada
- Decisão final, pendência remanescente e responsável pelo próximo passo
Exemplo ilustrativo de decisão após uma falha
Exemplo ilustrativo
Entrada: a equipe alterou uma regra interna de geração e criou o caso CT-XML-021 com uma guia inteiramente fictícia e dois itens. Mapeamento: o resultado esperado foi a presença de duas ocorrências do grupo de itens na estrutura prevista, com valores sintéticos e sem dados de pacientes reais. Erro: a primeira execução gerou somente uma ocorrência, embora o cadastro de teste tivesse dois itens. Correção: a equipe registrou o resultado obtido, investigou o mapeamento da coleção, ajustou a regra e repetiu exatamente o mesmo caso. A segunda execução apresentou duas ocorrências, o que sustenta a liberação interna apenas para o comportamento testado. Se outros cenários, versões ou regras locais não foram verificados, eles continuam pendentes e não devem ser considerados cobertos.
A decisão deve seguir a evidência e o alcance do caso. Libere internamente quando o resultado observado corresponde ao critério definido e os cenários planejados foram executados. Corrija quando há divergência reproduzível entre resultado esperado e obtido. Investigue quando a equipe não consegue reproduzir a falha, quando o resultado depende de configuração não identificada ou quando falta informação para afirmar qual regra deveria prevalecer. Em todos os casos, registre a decisão e sua justificativa; “validado” sem referência ao caso não explica o que foi validado.
Checklist de execução dos casos de teste
Antes de encerrar a validação interna
- Defina uma pergunta objetiva para cada caso
- Relacione o caso à mudança, ao risco ou à regra em análise
- Use exclusivamente dados sintéticos ou previamente aprovados para teste
- Indique a versão XML TISS e o ambiente utilizados
- Descreva o resultado esperado antes da execução
- Guarde o arquivo gerado e a evidência de resultado em local controlado
- Registre fatos observados separadamente das hipóteses de causa
- Repita o mesmo caso após uma correção e compare os resultados
- Marque cenários não executados como pendências, sem tratá-los como aprovados
- Documente que o resultado é interno e não representa aceite da operadora
Confira os arquivos de teste antes da próxima etapa
Após preparar os casos e registrar os resultados, use o Validador TISS online para conferir os XMLs de teste. A conferência deve fazer parte da evidência do caso, sem substituir a análise do contexto, da versão aplicada e das regras específicas do seu processo.
Perguntas frequentes sobre casos de teste XML TISS
Fontes e referências
Padrão TISS – Maio/2026 — Agência Nacional de Saúde Suplementar