Dados de teste importam: quando a falha está no cenário, não no código

O problema encontrado

Durante a criação de uma invoice pela API, o teste falhou retornando erro de validação:

{
  "billing_country": [
    "The billing_country does not match the entered address"
  ]
}

Inicialmente parecia um problema no endpoint ou na automação, mas a causa estava nos dados enviados.

O dado de teste era inválido

O cenário utilizava uma combinação de endereço que não fazia sentido para a validação da aplicação:

{
  "billing_city": "Test City",
  "billing_state": "Test State",
  "billing_country": "US"
}

A API possuía uma regra de negócio que validava se cidade, estado e país pertenciam ao mesmo endereço.

Falha técnica ou falha de cenário?

Nem toda falha de teste indica um problema no código de automação.

• Endpoint incorreto pode ser uma falha técnica.
• Payload inválido pode ser uma falha de dados.
• Regra de negócio inesperada pode exigir investigação.

Antes de alterar a implementação, é necessário entender qual camada está causando o comportamento.

Como melhorar dados de teste

• Utilizar dados coerentes com as regras do sistema.
• Evitar valores genéricos quando existe validação de domínio.
• Criar massa de dados reutilizável.
• Separar dados de teste da lógica dos testes.

Aplicação prática

Ao corrigir os dados de endereço, o mesmo teste passou sem alteração no código de automação.

A investigação mostrou que o framework estava funcionando corretamente; o problema estava no cenário criado.

Conclusão

Dados de teste fazem parte da qualidade da automação. Um teste confiável depende não apenas de código correto, mas também de cenários que representem situações válidas e relevantes para a aplicação.