Como criar casos de teste de processo com ChatGPT

O processo mudou e o teste virou uma leitura rápida

Uma equipe altera a regra de aprovação de pedidos. O documento parece claro, a tela foi atualizada e alguém testa um exemplo comum. A mudança entra em uso. Dias depois, aparece um pedido exatamente no limite da alçada, outro com cadastro bloqueado e um terceiro com desconto sem fonte. Nenhum deles estava no teste.

O ChatGPT pode ajudar a decompor regras em condições, entradas e resultados esperados. A ferramenta também pode inventar uma política provável, completar lacunas e escrever casos que apenas repetem o texto original.

Este tutorial usa uma conversa comum no ChatGPT e um processo inteiramente sintético. O caminho principal depende somente de texto colado, sem upload, app conectado ou recurso em rollout. A saída esperada foi conferida contra as regras publicadas abaixo. A Júpiter não executou benchmark entre modelos, planos ou interfaces.

O que você vai produzir

Ao final, você terá:

1. inventário de regras e lacunas;
2. tabela de condições e resultados esperados;
3. casos de caminho comum;
4. testes de limite;
5. casos de exceção e bloqueio;
6. combinações que ainda precisam de decisão;
7. matriz de rastreabilidade;
8. roteiro de execução e registro;
9. pacote em estado RASCUNHO PARA REVISÃO.

O material prepara a validação humana. Ele não altera sistema, aprova política, executa pedido real ou autoriza a entrada de uma mudança em produção.

O recorte deste tutorial

O artigo sobre documentar um processo com ChatGPT transforma notas de execução numa instrução de trabalho. O tutorial de checklist a partir de política organiza verificações recorrentes.

Aqui, a tarefa começa com regras já escritas e produz situações capazes de mostrar se uma mudança respeita essas regras. O resultado serve para homologação de fluxo, formulário, automação ou procedimento por uma pessoa responsável.

A página sobre critérios de aceite para agentes aborda a decisão formal de liberar uma capacidade de IA. Este exercício é mais amplo e ensina uma equipe a preparar casos de teste para um processo empresarial delimitado.

Ferramenta, acesso e cuidados com dados

Use o ChatGPT pela web numa conversa nova. Cole o cenário sintético deste artigo.

A documentação oficial da OpenAI descreve o ChatGPT como ferramenta para seguir instruções, redigir, resumir e trabalhar com texto. As orientações de prompts recomendam contexto, pedido específico e formato de saída. O método usa essas capacidades gerais.

Antes de trabalhar com um processo real:

• confirme a conta e o workspace autorizados;
• remova nomes, dados pessoais, contratos e valores restritos sem função no teste;
• preserve a política original fora da conversa;
• identifique versão, vigência e dono da regra;
• confirme quem pode aprovar o plano e o resultado;
• use ambiente de teste quando houver execução em sistema;
• bloqueie envio, pagamento, publicação ou alteração real;
• revise os controles de dados da conta.

Os controles disponíveis variam conforme login, plano e workspace. A OpenAI declara que conteúdos de ofertas empresariais cobertas por sua política comercial ficam fora do treinamento por padrão. Isso não substitui autorização interna, classificação da informação ou contrato da empresa.

Processo sintético do exercício

A Empresa Horizonte vende equipamentos para outras empresas. Ela quer testar uma regra revisada de liberação de pedidos antes de configurar o sistema.

Copie a especificação fictícia:

PROCESSO: liberação de pedido B2B
VERSÃO DA REGRA: 3.2
ESTADO: rascunho aprovado para teste; uso em produção ainda proibido

ENTRADAS OBRIGATÓRIAS
- pedido_id
- cliente_id
- valor_total
- percentual_desconto
- condição_pagamento
- status_cadastro
- status_estoque
- proposta_aprovada_id
- aprovacao_comercial_id, quando exigida
- aprovacao_financeira_id, quando exigida

REGRAS
R1. Pedido sem proposta aprovada vinculada fica BLOQUEADO.
R2. Cadastro do cliente precisa estar ATIVO. Cadastro PENDENTE ou BLOQUEADO impede liberação.
R3. Estoque COMPLETO permite seguir. Estoque PARCIAL exige decisão comercial registrada. Estoque INDISPONÍVEL bloqueia.
R4. Desconto de 0% a 5%, inclusive, segue sem aprovação comercial adicional.
R5. Desconto acima de 5% até 10%, inclusive, exige aprovacao_comercial_id válida.
R6. Desconto acima de 10% fica BLOQUEADO. A regra não prevê exceção.
R7. Condição de pagamento em 30 dias segue sem aprovação financeira adicional.
R8. Condição acima de 30 dias até 60 dias, inclusive, exige aprovacao_financeira_id válida.
R9. Condição acima de 60 dias fica BLOQUEADA.
R10. Pedido com valor_total acima de R$ 50.000 exige segunda conferência por pessoa ainda A DEFINIR.
R11. Valor igual a R$ 50.000 não aciona segunda conferência.
R12. Todas as condições aplicáveis precisam ser atendidas. Uma aprovação comercial não substitui aprovação financeira.
R13. A liberação apenas muda o pedido para PRONTO_PARA_EXPEDICAO. Nenhum faturamento ou envio é executado.

LACUNAS CONHECIDAS
- a regra não informa o comportamento para desconto negativo;
- a regra não define quem faz a segunda conferência;
- a regra não informa o que ocorre quando o ID de aprovação existe, mas pertence a outro pedido;
- a regra não define prazo de validade das aprovações;
- a combinação estoque PARCIAL com valor acima de R$ 50.000 exige as duas decisões, mas a ordem ainda não foi definida.

PROIBIÇÕES DO TESTE
- não preencher lacunas por prática de mercado;
- não criar aprovação fictícia;
- não enviar pedido;
- não faturar;
- não alterar CRM ou ERP;
- não tratar BLOQUEADO como REPROVADO definitivamente;
- não usar dados reais.

O exercício contém limites inclusivos, combinações de aprovação, estados impeditivos e lacunas declaradas. O plano reprova se a ferramenta criar uma resposta para qualquer lacuna.

Passo 1: fixe o contrato da conversa

Envie:

Vou fornecer uma especificação sintética de processo.

Prepare casos de teste em estado RASCUNHO PARA REVISÃO.
Use somente as regras fornecidas.
Não invente política, responsável, prazo, aprovação, sistema ou resultado.
Preserve limites inclusivos e condições cumulativas.
Quando a regra não permitir determinar o resultado, use exatamente: A DEFINIR.
Não execute ação externa e não trate o plano como homologação concluída.
Aguarde a especificação.

Depois, cole o processo sintético.

Essa primeira mensagem deixa claro que uma lacuna descoberta pertence ao dono do processo. O ChatGPT pode transformá-la em pergunta ou teste pendente. Não pode convertê-la em uma regra conveniente.

Passo 2: inventarie as regras antes de criar casos

Peça:

Extraia a especificação para uma tabela com estas colunas:
- ID da regra;
- entrada observada;
- condição;
- limite inferior e superior;
- inclusivo ou exclusivo;
- resultado esperado;
- aprovação exigida;
- ação proibida;
- dependência de outra regra;
- lacuna relacionada;
- trecho literal da fonte.

Crie uma linha por condição verificável.
Não gere casos de teste ainda.
Não combine regras silenciosamente.

A tabela precisa preservar pelo menos:

• 5% dentro da faixa sem aprovação adicional;
• valores acima de 5% e até 10% com aprovação comercial;
• 10% dentro da faixa que admite aprovação;
• valores acima de 10% bloqueados;
• 30 dias sem aprovação financeira adicional;
• valores acima de 30 e até 60 dias com aprovação financeira;
• valores acima de 60 dias bloqueados;
• R$ 50.000 sem segunda conferência;
• valores acima de R$ 50.000 com segunda conferência;
• aprovações comercial e financeira como requisitos independentes;
• liberação terminando em PRONTO_PARA_EXPEDICAO.

Se a saída arredondar limites, omitir “inclusive” ou tratar aprovações como alternativas, corrija o inventário antes de seguir.

Passo 3: separe regra testável de lacuna

Envie:

Classifique cada item como:
- REGRA TESTÁVEL;
- LACUNA QUE BLOQUEIA O RESULTADO;
- LACUNA QUE BLOQUEIA A EXECUÇÃO DO TESTE;
- INFORMAÇÃO DE CONTEXTO.

Para cada lacuna, informe:
- cenário afetado;
- decisão necessária;
- risco de presumir uma resposta;
- pergunta ao dono do processo.

Não proponha a resposta.

O gabarito deve manter como lacunas:

1. desconto negativo;
2. responsável pela segunda conferência;
3. vínculo do ID de aprovação ao pedido;
4. validade temporal da aprovação;
5. ordem entre decisão de estoque parcial e segunda conferência.

O modelo pode perceber outras ambiguidades. Elas entram como perguntas, com referência ao trecho que gerou a dúvida. Sugestão de boa prática não vira requisito do processo.

Passo 4: crie casos de caminho comum

Comece por poucos casos que provem o fluxo básico.

Crie casos de caminho comum com:
- ID;
- objetivo;
- pré-condições;
- valores completos de entrada;
- regras exercitadas;
- resultado esperado;
- estado final permitido;
- evidência a registrar;
- ação que permanece proibida.

Use valores distantes dos limites nesta etapa.
Inclua somente cenários cujo resultado decorra das regras.

Um caso comum válido pode ser:

ID: CT-01
Objetivo: liberar pedido sem aprovação adicional
Entrada:
- pedido_id: PED-101
- cliente_id: CLI-40
- valor_total: 18000
- percentual_desconto: 3
- condição_pagamento: 30 dias
- status_cadastro: ATIVO
- status_estoque: COMPLETO
- proposta_aprovada_id: PROP-101
- aprovacao_comercial_id: não aplicável
- aprovacao_financeira_id: não aplicável
Resultado esperado: PRONTO_PARA_EXPEDICAO
Ação proibida: faturar ou enviar
Regras: R1, R2, R3, R4, R7, R13

Outro caminho comum deve mostrar um pedido com desconto de 8% e pagamento em 45 dias, com as duas aprovações exigidas. Se apenas uma estiver presente, a liberação reprova.

Passo 5: teste os limites de cada faixa

Casos de fronteira capturam erros de comparação como < no lugar de <=.

Peça:

Crie testes de limite para desconto, condição de pagamento e valor_total.
Para cada fronteira, gere quando aplicável:
- valor imediatamente abaixo;
- valor exatamente igual;
- valor imediatamente acima.

Mostre a regra exercitada e o resultado esperado.
Use duas casas decimais para percentual e valor monetário quando necessário.
Não crie resultado para desconto negativo; marque A DEFINIR.

Limites de desconto esperados

| Entrada | Condição esperada | |---|---| | 4,99% | sem aprovação comercial adicional | | 5,00% | sem aprovação comercial adicional | | 5,01% | exige aprovação comercial | | 9,99% | exige aprovação comercial | | 10,00% | exige aprovação comercial | | 10,01% | bloqueado |

Limites de pagamento esperados

| Entrada | Condição esperada | |---|---| | 29 dias | a regra publicada só confirma 30 dias; resultado A DEFINIR | | 30 dias | sem aprovação financeira adicional | | 31 dias | exige aprovação financeira | | 59 dias | exige aprovação financeira | | 60 dias | exige aprovação financeira | | 61 dias | bloqueado |

Existe uma armadilha importante: R7 confirma “em 30 dias”, sem declarar explicitamente “até 30 dias”. Por isso, 29 dias não deve receber uma resposta inventada. O teste transforma essa lacuna em decisão antes da configuração.

Limites de valor esperados

| Entrada | Condição esperada | |---|---| | R$ 49.999,99 | sem segunda conferência por valor | | R$ 50.000,00 | sem segunda conferência por valor | | R$ 50.000,01 | exige segunda conferência; responsável A DEFINIR |

O resultado acima de R$ 50.000 pode ser “aguardando segunda conferência”, sem inventar a pessoa responsável.

Passo 6: crie casos de bloqueio

Envie:

Crie um caso isolado para cada bloqueio explícito:
- proposta ausente;
- cadastro PENDENTE;
- cadastro BLOQUEADO;
- estoque INDISPONÍVEL;
- desconto acima de 10%;
- pagamento acima de 60 dias;
- aprovação comercial ausente quando exigida;
- aprovação financeira ausente quando exigida.

Mantenha as demais entradas válidas para isolar a causa.
Registre resultado, regra, evidência e próxima decisão permitida.
Não chame BLOQUEADO de reprovação definitiva.

Isolar a causa ajuda a localizar defeitos. Um caso com proposta ausente, cadastro bloqueado e desconto de 12% prova que o pedido para, mas não mostra qual validação falhou ou se todas foram avaliadas corretamente.

Depois dos casos isolados, crie combinações para verificar a ordem e o acúmulo de motivos.

Passo 7: teste condições cumulativas

A especificação diz que todas as regras aplicáveis precisam ser atendidas.

Use:

Crie casos combinatórios mínimos para provar que aprovações e bloqueios são cumulativos.
Inclua:
1. desconto de 8% com pagamento em 45 dias e duas aprovações válidas;
2. o mesmo cenário somente com aprovação comercial;
3. o mesmo cenário somente com aprovação financeira;
4. estoque PARCIAL com decisão comercial registrada;
5. estoque PARCIAL sem decisão registrada;
6. valor acima de R$ 50.000 com demais condições válidas;
7. estoque PARCIAL e valor acima de R$ 50.000.

Use pairwise apenas como sugestão de cobertura, sem alegar cobertura completa.
Marque A DEFINIR quando a ordem ou a validade da aprovação impedir resultado conclusivo.

Resultados esperados:

• as duas aprovações válidas permitem seguir, se as demais regras passarem;
• uma aprovação não substitui a outra;
• estoque parcial depende de decisão comercial registrada;
• valor acima de R$ 50.000 aguarda segunda conferência;
• a combinação de estoque parcial e valor alto exige as duas decisões, mas a ordem permanece A DEFINIR.

Passo 8: teste IDs e vínculos sem inventar validação

A regra exige IDs de aprovação, mas declara uma lacuna sobre vínculo ao pedido.

Peça:

Crie testes para:
- campo de aprovação vazio;
- ID com formato presente;
- ID pertencente ao mesmo pedido;
- ID pertencente a outro pedido;
- ID de aprovação comercial usado no campo financeiro;
- aprovação emitida antes da última alteração do pedido;
- aprovação sem data disponível.

Separe:
- o que a regra atual permite concluir;
- o que precisa de definição;
- a validação que seria necessária antes da produção.
Não afirme que presença do ID prova validade.

Somente a ausência do campo quando exigido possui resultado determinado: o pedido não pode seguir. Vínculo, tipo e prazo de validade precisam de decisão adicional. Esse é um achado do teste, não um convite para a ferramenta escrever a política.

Passo 9: monte uma matriz de rastreabilidade

Envie:

Crie uma matriz com:
- regra ou lacuna;
- casos que a cobrem;
- entradas usadas;
- resultado esperado;
- evidência de execução;
- estado: COBERTA, PARCIAL ou SEM RESULTADO DEFINIDO;
- revisão humana necessária.

Aponte regras sem caso e casos sem regra de origem.
Não use quantidade de casos como prova de cobertura suficiente.

A matriz precisa mostrar pelo menos uma linha para R1 a R13 e para cada lacuna conhecida. Uma regra pode exigir vários casos. Um caso pode cobrir várias regras, desde que o resultado continue diagnosticável.

Use âncoras descritivas ao guardar o plano: R5 desconto acima de 5% até 10% comunica melhor que “regra intermediária”.

Passo 10: defina o roteiro de execução humana

O plano vira evidência somente depois de execução controlada.

Prepare um roteiro para uma pessoa executar os casos em ambiente de teste.
Inclua:
1. identificação da versão do processo e do sistema;
2. limpeza ou isolamento dos dados sintéticos;
3. preparação das entradas;
4. execução de um caso por vez;
5. captura do resultado observado;
6. comparação com o esperado;
7. registro de divergência;
8. restauração do ambiente;
9. revisão por responsável;
10. decisão de corrigir, repetir, aceitar com limite ou bloquear.

Não declare que os casos foram executados.

Registre para cada execução:

case_id
rule_version
system_version
executed_at
operator
input_fixture
expected_result
observed_result
status
error_or_difference
artifact_link
reviewer
next_action

A captura deve permitir reprodução. Uma imagem sem entrada, versão ou caso associado comprova pouco.

Passo 11: audite invenções e perdas

Use o pedido final:

Compare o plano de testes com a especificação linha por linha.
Crie cinco blocos:
1. regras preservadas;
2. limites alterados;
3. resultados inventados;
4. regras sem cobertura;
5. ações externas incluídas indevidamente.

Cite o trecho de origem.
Não corrija silenciosamente.

Reprove o plano se ele:

• liberar 5,01% sem aprovação comercial;
• bloquear 10% apesar de aprovação válida;
• liberar 61 dias;
• exigir segunda conferência em R$ 50.000;
• permitir aprovação comercial no lugar da financeira;
• autorizar estoque parcial sem decisão registrada;
• inventar responsável pela segunda conferência;
• tratar ID presente como aprovação válida;
• liberar desconto negativo;
• faturar ou enviar pedido;
• afirmar que os casos foram executados;
• chamar o plano de homologado.

Gabarito de cobertura do exercício

A especificação contém:

• 9 entradas obrigatórias gerais e 2 condicionais;
• 13 regras numeradas;
• 3 faixas de desconto;
• 3 condições de pagamento descritas, com uma lacuna abaixo de 30 dias;
• 3 estados de cadastro;
• 3 estados de estoque;
• 1 limite monetário estritamente acima de R$ 50.000;
• 5 lacunas conhecidas;
• 6 ações proibidas no teste;
• 1 estado final permitido: PRONTO_PARA_EXPEDICAO.

A contagem verifica se o plano perdeu elementos do cenário. Ela não prova que o processo real está correto, que os casos foram executados ou que a mudança pode entrar em produção.

Como revisar a qualidade dos casos

Um caso deve ter uma pergunta clara

“Testar pedido” cria espaço demais. “Confirmar que desconto de 5,01% exige aprovação comercial” permite observar uma regra específica.

A entrada precisa ser completa

Se o caso omite cadastro ou estoque, o resultado pode depender do valor padrão do sistema. Declare todos os campos que mudam a decisão.

O esperado precisa vir da fonte

Escrever APROVADO por costume pode esconder que a política só autoriza PRONTO_PARA_EXPEDICAO. Preserve o vocabulário e o alcance da regra.

Exceções merecem casos próprios

Caminho comum mostra que a operação passa. Limites, ausência, conflito e estado inválido mostram se ela para com o motivo correto.

A evidência precisa alcançar o efeito

Confirme o estado gravado e a ausência de ações proibidas. Uma mensagem de sucesso na tela pode acompanhar faturamento indevido ou pedido sem registro final.

Limites do método

O ChatGPT organiza cobertura a partir do texto fornecido. Ele não observa automaticamente o processo real, a configuração do sistema ou regras que ficaram fora do documento.

Antes da aprovação:

• uma pessoa dona da regra confirma a interpretação;
• quem executa o processo revisa casos comuns e exceções;
• tecnologia valida campos, estados e integrações;
• segurança revisa dados e ambiente;
• o responsável pela mudança executa os casos;
• divergências geram correção ou decisão documentada;
• testes são repetidos depois da alteração.

Processos jurídicos, financeiros, médicos, trabalhistas ou de segurança exigem revisão competente no domínio. A ferramenta prepara o plano; a responsabilidade permanece com quem define e aprova a operação.

Checklist antes de executar

• [ ] A versão da regra está identificada?
• [ ] O ambiente de teste está separado ou controlado?
• [ ] Os dados são sintéticos e completos?
• [ ] Cada caso aponta para uma regra ou lacuna?
• [ ] Limites inclusivos e exclusivos foram preservados?
• [ ] Caminho comum, fronteiras, bloqueios e combinações aparecem?
• [ ] Campos condicionais foram testados presentes e ausentes?
• [ ] Aprovações independentes continuam independentes?
• [ ] Lacunas permanecem como A DEFINIR?
• [ ] O estado final corresponde ao alcance da regra?
• [ ] Ações proibidas possuem verificação explícita?
• [ ] Resultado esperado e observado ficam separados?
• [ ] A execução registra versão, operador e evidência?
• [ ] Divergência possui dono e próxima decisão?
• [ ] Uma pessoa autorizada revisará o resultado?
• [ ] O pacote continua como rascunho até a homologação real?

Um bom teste força a regra a responder

O ChatGPT ajuda a transformar um documento em perguntas verificáveis. Primeiro extraia condições e limites. Depois crie caminhos comuns, fronteiras, bloqueios e combinações. Por fim, ligue cada caso à fonte e registre o que continua sem resposta.

O ganho aparece antes da execução: ambiguidades ficam visíveis enquanto ainda custam uma decisão, em vez de surgirem como erro no trabalho real. A equipe entra na homologação com entradas, resultados esperados e lacunas legíveis.

Fontes oficiais verificadas em 2 de outubro de 2026:

• OpenAI: ChatGPT Capabilities Overview, para capacidades gerais de redação, seguimento de instruções e trabalho com texto.
• OpenAI: Prompt engineering best practices for ChatGPT, para contexto, especificidade, formato e refinamento.
• OpenAI: Data Controls FAQ, para controles que variam por login, plano e workspace.
• OpenAI: Business data privacy, security, and compliance, para o tratamento declarado de dados em ofertas empresariais.

As fontes sustentam capacidades e controles gerais do produto. Elas não aprovam a política sintética, não comprovam execução dos casos e não autorizam dados empresariais numa conta específica.