Testar todas as entradas possíveis é impossível — um simples campo de número inteiro já tem bilhões de valores. A maturidade de um QA aparece justamente aqui: em escolher o menor conjunto de casos que encontra o maior número de defeitos. É para isso que existem as técnicas de design de teste de caixa-preta. Elas são clássicas (vêm do ISTQB) e são usadas o tempo todo, mesmo quando o QA nem percebe que está usando.

O mapa das técnicas

Como derivar casos de teste sem testar tudo?
        │
        ├── Entradas com faixas/grupos
        │      ├── Partição de equivalência  → 1 valor por grupo
        │      └── Análise de valor-limite    → as bordas dos grupos
        │
        ├── Combinação de condições
        │      └── Tabela de decisão           → regras de negócio "se A e B então..."
        │
        └── Comportamento que depende do passado
               └── Transição de estado         → status, fluxos, máquinas de estado

1. Partição de equivalência

A ideia: se um grupo de entradas é tratado da mesma forma pelo sistema, testar um valor do grupo equivale a testar todos. Você divide o domínio em classes (válidas e inválidas) e pega um representante de cada.

Exemplo — um campo de idade que aceita de 18 a 65:

• Inválida (abaixo): qualquer valor < 18 → ex.: 10
• Válida: 18 a 65 → ex.: 30
• Inválida (acima): > 65 → ex.: 80

Três casos cobrem o comportamento do campo inteiro. Testar 30, 31 e 32 seria desperdício — todos caem na mesma partição.

2. Análise de valor-limite

Bugs adoram as bordas. > que devia ser >=, o "off-by-one", o limite que ninguém testou. Esta técnica complementa a partição testando exatamente os extremos de cada faixa. Para o campo de idade (18–65), os valores que interessam são:

     17   |   18   ...   65   |   66
   inválido |  válido (18 a 65) |  inválido
       ^        ^          ^         ^
     borda   primeiro    último    borda
   rejeita   aceita      aceita    rejeita

Os casos: 17 (rejeita), 18 (aceita), 65 (aceita), 66 (rejeita). É onde a maior parte dos defeitos de validação se esconde — e é uma das primeiras coisas que um avaliador técnico pergunta: "como você testaria esse campo?".

3. Tabela de decisão

Quando a regra depende da combinação de várias condições, listar tudo na cabeça falha. A tabela de decisão mapeia cada combinação de condições à ação esperada — e expõe regras que ninguém tinha pensado.

Exemplo — desconto que depende de ser cliente VIP e da compra passar de R$ 100:

Cada coluna é um caso de teste. A técnica garante que nenhuma combinação seja esquecida — inclusive a R4, o caso "nada acontece", que costuma ficar de fora dos testes felizes.

4. Transição de estado

Alguns comportamentos dependem do histórico, não só da entrada atual. Um pedido pode ir de Criado → Pago → Enviado, mas nunca de Criado → Enviado. Aqui se modela uma máquina de estados e se testam tanto as transições válidas quanto as proibidas:

   [Criado] ──pagar──► [Pago] ──despachar──► [Enviado] ──entregar──► [Entregue]
       │
       └──cancelar──► [Cancelado]

   Transições inválidas a testar:
     • Criado ──despachar──►  (deve ser bloqueado)
     • Enviado ──pagar──►     (deve ser bloqueado)
     • Entregue ──cancelar──► (deve ser bloqueado)

O ganho está nas transições inválidas: é onde moram os bugs de "consegui cancelar um pedido já entregue". Testar só o caminho feliz deixa esse buraco aberto.

Combinar é a regra, não escolher uma

Na prática essas técnicas se somam. Um único formulário de cadastro pode pedir partição + valor-limite nos campos numéricos, tabela de decisão na regra de "quem pode se cadastrar" e transição de estado no fluxo de ativação da conta. A pergunta certa nunca é "qual técnica usar?", e sim "quais condições deste requisito cada técnica me ajuda a cobrir?".

Testar bem não é testar muito — é testar o certo. Essas técnicas são o raciocínio que transforma "cliquei por aí e parece ok" em cobertura defensável.

Conclusão

Partição de equivalência e valor-limite atacam entradas; tabela de decisão ataca combinações; transição de estado ataca comportamento dependente do passado. Juntas, elas dão ao QA uma resposta sólida para a pergunta mais frequente de qualquer avaliação técnica — "por que você escolheu esses casos e não outros?" — e, mais importante, encontram defeitos que o teste improvisado nunca acharia.

Testing every possible input is impossible — a simple integer field already has billions of values. A QA's maturity shows precisely here: in choosing the smallest set of cases that finds the largest number of defects. That is what black-box test design techniques are for. They are classics (straight from ISTQB) and are used all the time, even when the QA doesn't realize they're using them.

The map of techniques

How do you derive test cases without testing everything?
        │
        ├── Inputs with ranges/groups
        │      ├── Equivalence partitioning  → 1 value per group
        │      └── Boundary value analysis   → the edges of the groups
        │
        ├── Combination of conditions
        │      └── Decision table            → business rules "if A and B then..."
        │
        └── Behavior that depends on the past
               └── State transition          → statuses, flows, state machines

1. Equivalence partitioning

The idea: if a group of inputs is treated the same way by the system, testing one value from the group is equivalent to testing all of them. You split the domain into classes (valid and invalid) and pick one representative from each.

Example — an age field that accepts 18 to 65:

• Invalid (below): any value < 18 → e.g. 10
• Valid: 18 to 65 → e.g. 30
• Invalid (above): > 65 → e.g. 80

Three cases cover the behavior of the whole field. Testing 30, 31 and 32 would be a waste — they all fall in the same partition.

2. Boundary value analysis

Bugs love edges. A > that should have been >=, the "off-by-one", the limit nobody tested. This technique complements partitioning by testing exactly the extremes of each range. For the age field (18–65), the values that matter are:

     17   |   18   ...   65   |   66
   invalid |  valid (18 to 65) |  invalid
       ^        ^          ^         ^
     edge     first       last      edge
   rejects   accepts    accepts   rejects

The cases: 17 (rejects), 18 (accepts), 65 (accepts), 66 (rejects). This is where most validation defects hide — and it's one of the first things a technical interviewer asks: "how would you test this field?".

3. Decision table

When the rule depends on the combination of several conditions, listing everything in your head fails. The decision table maps each combination of conditions to the expected action — and exposes rules nobody had thought of.

Example — a discount that depends on being a VIP customer and the purchase exceeding R$ 100:

Each column is a test case. The technique guarantees no combination is forgotten — including R4, the "nothing happens" case, which tends to be left out of happy-path tests.

4. State transition

Some behaviors depend on history, not just the current input. An order can go from Created → Paid → Shipped, but never from Created → Shipped. Here you model a state machine and test both the valid and the forbidden transitions:

   [Created] ──pay──► [Paid] ──dispatch──► [Shipped] ──deliver──► [Delivered]
       │
       └──cancel──► [Cancelled]

   Invalid transitions to test:
     • Created ──dispatch──►  (must be blocked)
     • Shipped ──pay──►       (must be blocked)
     • Delivered ──cancel──►  (must be blocked)

The payoff is in the invalid transitions: that's where the "I managed to cancel an order that was already delivered" bugs live. Testing only the happy path leaves that hole open.

Combining is the rule, not picking one

In practice these techniques add up. A single sign-up form might call for partitioning + boundary values on numeric fields, a decision table for the "who can sign up" rule, and state transition for the account activation flow. The right question is never "which technique should I use?", but "which conditions of this requirement does each technique help me cover?".

Testing well isn't testing a lot — it's testing the right things. These techniques are the reasoning that turns "I clicked around and it looks fine" into defensible coverage.

Conclusion

Equivalence partitioning and boundary values attack inputs; decision tables attack combinations; state transition attacks behavior that depends on the past. Together, they give the QA a solid answer to the most frequent question in any technical interview — "why did you choose these cases and not others?" — and, more importantly, they find defects that improvised testing never would.