As tabelas de decisão ajudam quando o comportamento depende de várias condições juntas. QA organiza combinações sistematicamente e vê quais regras são cobertas e quais permanecem não testadas.
Quando a técnica é especialmente útil
- →Várias condições de entrada determinam em conjunto o resultado.
- →A lógica textual torna-se difícil de seguir em detalhes.
- →Combinações conflitantes ou raras importam além do caminho feliz.
- →Os membros da equipe podem interpretar a mesma regra de maneira diferente.
Construindo uma tabela de decisão
- →Liste as condições que afetam o comportamento.
- →Identifique seus possíveis estados: sim/não, válido/inválido, papel A/papel B e assim por diante.
- →Registre a ação esperada para cada combinação significativa.
- →Remova combinações impossíveis ou irrelevantes para manter a tabela vinculada ao comportamento real.
Exemplo
Considere o checkout regido por três fatores: disponibilidade de estoque, usuário autenticado e pagamento confirmado. Uma tabela de decisão esclarece quando um pedido pode ser criado, quando o login é necessário e quando a operação deve ser bloqueada de forma mais clara do que uma descrição emaranhada em prosa.
Erros comuns
- →Incluindo todos os estados concebíveis sem considerar a relevância.
- →Falha em distinguir combinações impossíveis de combinações reais.
- →Descrever ações do sistema vagamente, sem expectativas concretas.
- →Criar uma tabela atrativa sem transformar suas regras em verificações executáveis.
As tabelas de decisão transformam regras de negócio vagas em um mapa de decisão transparente. São particularmente valiosas em fintech, comércio eletrônico, controle de acesso, descontos, planos de preços e sistemas de fluxo de trabalho.
Tabela de decisão resolvida: desconto para membros
Regra fictícia: aplique um desconto de 10% somente quando o cliente for membro AND o subtotal do pedido for de pelo menos 100 unidades monetárias inteiras. Caso contrário, não aplique desconto. O subtotal já está validado, impostos e entrega estão excluídos, e os exemplos usam valores inteiros para evitar uma política de arredondamento não especificada.
Regra Membro? Subtotal >= 100? Subtotal de exemplo Desconto Valor após desconto
R1 Não Não 80 0% 80
R2 Não Sim 120 0% 120
R3 Sim Não 80 0% 80
R4 Sim Sim 120 10% 108Duas condições booleanas independentes produzem quatro combinações; todos os quatro são viáveis sob esta especificação. A tabela torna explícita a regra AND: apenas a associação é insuficiente e um subtotal grande por si só é insuficiente. Se uma condição for impossível no sistema real, registre o motivo antes de remover sua regra.
Transforme uma regra em um caso de teste
Caso DT-R4
Pré-condições: membro autenticado; subtotal 120; sem outras promoções.
Ação: solicitar o total do pedido.
Esperado: taxa de desconto 10%; valor do desconto 12; valor após desconto 108.
Caso de controle DT-R2: mesmo subtotal, não membro; desconto 0; valor 120.Todas as regras de decisão cobertas não significam que os limites numéricos sejam cobertos. Adicione subtotais de membros 99, 100 e 101: as taxas esperadas são 0%, 10% e 10%. Se os valores exatos a pagar puderem ser fracionários, primeiro defina a precisão e o arredondamento da moeda. Mantenha essas verificações distintas da aplicação do desconto.
Exercício: altere AND para OR
Suponha que a regra mude para “membro OR subtotal de pelo menos 100”. Quais linhas mudam? R2 e R3 agora recebem 10%; R1 continua sem desconto e R4 continua com 10%. Os valores esperados dos exemplos passam a ser 80, 108, 72 e 108. Recalcule a tabela antes de atualizar os testes para que a suposição antiga não permaneça despercebida.