Particionamento de equivalência e valor limite

Peça a um QA para testar o campo de CPF de um formulário e, na maioria das vezes, você vai receber de volta uma lista escolhida no improviso (um CPF válido, um inválido, talvez um campo vazio), que soa razoável até alguém perguntar por que esses valores específicos entraram na lista e não outros. Particionamento de equivalência e análise de valor limite existem justamente para responder essa pergunta. São duas técnicas antigas de design de teste, quase sempre ensinadas juntas, que trocam o "o que me ocorreu agora" por um processo com lógica própria: cobertura que dá para justificar depois, sem exigir que ninguém teste todos os valores possíveis de um campo, coisa que, para um CPF de 11 dígitos, nem caberia numa vida inteira de trabalho.

Particionamento de equivalência: agrupar antes de testar

Funciona assim: divide-se o universo de entradas possíveis de um campo em grupos, as chamadas partições, onde tudo dentro de um mesmo grupo deveria receber o mesmo tratamento do sistema. Sendo essa suposição verdadeira, um único representante de cada partição já basta para confiar no grupo inteiro, porque qualquer outro valor ali dentro deveria percorrer exatamente o mesmo caminho de código. Um CPF, por exemplo, já nasce com pelo menos três partições óbvias: os que têm dígito verificador correto, os que não têm, e as entradas que sequer chegam aos 11 dígitos. Rodar cem CPFs válidos diferentes não aumenta cobertura nenhuma se todos caírem na mesma partição; o que soma confiança é atravessar partições diferentes, não repetir a mesma dezenas de vezes.

O detalhe que mais escapa de quem usa a técnica por cima é que toda partição válida carrega, do lado dela, uma ou mais inválidas que pedem o mesmo cuidado na hora de definir. Um time que só testa "o CPF que deveria passar" nunca vai descobrir sozinho que o sistema também aceita, por descuido, um CPF com todos os dígitos repetidos, simplesmente porque ninguém parou para nomear essa como uma partição inválida a cobrir.

Análise de valor limite: onde os bugs realmente moram

Se particionamento decide quais grupos existem, valor limite decide onde testar dentro de cada um deles. Por trás da técnica está uma observação bem prática de quem já caçou bug: trocar > por >=, um laço que para um índice cedo ou tarde demais, um comprimento máximo checado com < quando deveria ser <=: esses erros são comuns o suficiente para terem virado apelido (off-by-one), e aparecem justamente na fronteira entre uma partição e a próxima, nunca no meio dela. Um valor confortavelmente no centro de uma partição válida dificilmente vai denunciar esse tipo de falha; só o valor bem na borda, e o valor logo depois dela, conseguem.

Para um campo numérico com limite de tamanho, cinco pontos costumam bastar: o mínimo válido, um valor logo abaixo dele (já inválido), o máximo válido, um valor logo acima (inválido de novo) e, se sobrar tempo, um valor qualquer no meio da faixa. Com esses cinco, a maior parte dos erros de fronteira já aparece, a um custo bem menor do que testar a faixa inteira.

Aplicando ao CPF: além de "válido ou inválido"

Um campo de CPF esconde mais partições do que a intuição costuma sugerir. Além de válido e inválido pelo dígito verificador, há os casos de comprimento (10, 11, 12 dígitos), as sequências repetidas que passam pela fórmula do módulo 11 mas são explicitamente barradas por regra de negócio (111.111.111-11), e ainda a presença ou ausência de pontuação. A fronteira que mais importa aqui não é numérica no sentido tradicional, é estrutural: o décimo dígito, a posição logo antes do primeiro verificador, e o próprio dígito verificador são onde um erro de implementação do módulo 11 costuma se esconder, porque é exatamente ali que a lógica de peso e resto muda de comportamento. Quem quiser entender essa fronteira em detalhe encontra no post sobre a matemática do CPF e o módulo 11.

Aplicando a telefone: comprimento fixo que não é tão fixo assim

Telefone parece, à primeira vista, um campo de regra simples (DDD de dois dígitos, mais oito ou nove dígitos de número), mas esconde uma partição que boa parte das suítes ignora: a passagem do celular de oito para nove dígitos, com o nono obrigatoriamente sendo 9. Um formulário pode aceitar corretamente um fixo de oito dígitos e um celular de nove, e ainda assim falhar ao rejeitar um número de nove dígitos que não começa em 9, ou ao aceitar um fixo com nove dígitos por engano; falhas que só aparecem se alguém tiver dedicado uma partição a "comprimento certo, dígito inicial errado". O DDD merece a própria partição também: os códigos válidos no Brasil não formam uma sequência contínua, então validar apenas "dois dígitos numéricos" deixa passar combinações que não correspondem a nenhuma região do país.

Aplicando ao CEP: oito dígitos, faixas por estado

CEP leva vantagem por ter um comprimento de verdade fixo, sempre oito dígitos, o que já elimina a partição de comprimento variável que atormenta o telefone. A fronteira interessante mora em outro lugar: os Correios dividem o país em faixas numéricas por região e estado, então um CEP com oito dígitos bem formados pode, mesmo assim, apontar para uma faixa que não existe ou que não bate com o estado preenchido em outro campo do mesmo formulário. É o tipo de inconsistência que só um teste de validação cruzada revela; a checagem isolada do campo CEP nunca vai encontrar. Formulários que pedem estado e CEP juntos ganham, com isso, mais uma partição: a combinação coerente entre os dois, distinta da combinação em que cada campo é estruturalmente válido sozinho, mas os dois juntos não fazem sentido.

Montando a tabela de casos

As duas técnicas só mostram o valor quando a definição de partições e limites vira uma tabela que dá para revisar, não uma lista solta de exemplos que existe apenas na cabeça de quem escreveu o teste. Três colunas já resolvem a maior parte: a partição (o que aquele grupo de valores representa), o valor escolhido para representá-la, e o resultado esperado. Quando outra pessoa do time revisa essa tabela, partições esquecidas, como o CPF de dígitos repetidos ou o celular de nove dígitos que não começa em 9, costumam saltar aos olhos, porque viram lacunas visíveis numa estrutura, em vez de ausências silenciosas numa lista improvisada.

Para gerar rápido valores representativos das partições válidas (CPF com dígito verificador correto, CEP e DDD coerentes entre si por estado), o Gerador de CPF e o Gerador de Pessoas deste site já entregam esse tipo de dado estruturalmente pronto. Para os valores de borda inválidos, dígito verificador errado, sequências repetidas, o Validador de CPF serve como conferência rápida antes de qualquer caso virar teste automatizado.