Existe uma imagem falsa do teste que insiste em não morrer: alguém abre o aplicativo, clica por todo lado e espera que algo exploda. Se nada explode, "está testado". Essa ideia é confortável e é mentira. Testar não é esperar o acidente. É desenhar um experimento que responda a uma pergunta concreta e verificável: este software faz o que prometemos que faria?
O teste de software é o conjunto de atividades que comparam o comportamento real de um sistema com o esperado, para descobrir a diferença antes que o usuário a descubra. Essa é a definição curta. O resto é o mapa de como se faz bem e por que a maioria faz ao contrário.
Um teste que nunca poderia falhar não está testando nada: só está confirmando o que você já acreditava.
01 · a perguntaO que é um teste, de verdade
Um teste tem três partes, embora quase nunca as nomeemos. Uma entrada: o estado e os dados com que ele começa. Uma ação: o que você executa. E, a que todos esquecem, um oráculo: a regra que decide se o resultado foi correto. Sem oráculo não há teste, há uma demonstração.
O oráculo é o coração da questão. Quando alguém diz "já testei e funciona", a pergunta certa é: funciona comparado com o quê? Se você não consegue responder isso, não testou, apenas olhou. O programa do ISTQB distingue com cuidado entre um erro (o engano humano), um defeito (o problema que ficou no código) e uma falha (o sintoma visível quando o defeito é executado). Testar bem é caçar defeitos antes que virem falhas diante de um cliente.
E aqui vai uma verdade que Dijkstra deixou escrita há meio século: testar pode demonstrar a presença de defeitos, nunca sua ausência. Nenhuma suíte garante que o software esteja livre de erros; o que ela dá é evidência. O objetivo não é a certeza absoluta, que não existe, mas reduzir o risco a um nível que você possa defender.
A tentação natural é escrever testes que confirmem que está tudo bem. Chama-se viés de confirmação e é veneno para um testador. Um bom teste é desenhado para falhar se o software estiver quebrado. Se você escreve um caso pensando "este com certeza passa", provavelmente não vale a pena. Pense como alguém que quer quebrar o sistema, não como quem quer aprová-lo.
02 · os níveisOnde se testa: do tijolo ao edifício
Não se testa tudo no mesmo lugar nem da mesma maneira. O teste se organiza em níveis, conforme o tamanho do que você está verificando. Entendê-los evita o erro mais caro de todos: testar a peça errada com a ferramenta errada.
Na base estão os testes unitários: verificam uma função ou uma classe isolada, sem seus vizinhos. São baratos, rápidos e muito específicos. Um pouco acima, os testes de integração comprovam que duas ou mais peças conversam bem entre si, que é onde costumam se esconder os defeitos reais. No topo, os testes end to end percorrem um fluxo completo como faria um usuário, do clique inicial ao resultado final.
A regra de bolso: quanto mais você sobe, mais realista é o teste, mas também mais lento e mais frágil. Uma suíte saudável tem muitos testes embaixo e poucos em cima. A doente, a que você vê em tantos times, tem a ampulheta invertida: centenas de testes end to end lentos e quase nenhum unitário.
03 · os tiposO que se testa: nem tudo é "que funcione"
Os níveis respondem onde. Os tipos respondem qual qualidade você está medindo. E é aqui que muita gente fica aquém, porque acredita que testar é só verificar que o botão faz o que diz.
A primeira grande divisão é entre testes funcionais e não funcionais. Os funcionais perguntam "faz a coisa certa?": se eu enviar o formulário, o registro é salvo? Os não funcionais perguntam "faz suficientemente bem?": responde rápido, aguenta a carga, é seguro, dá para usar sem manual? O padrão ISO/IEC 25010 dá nome a essas qualidades e lista oito características do produto, entre elas a eficiência de desempenho, a segurança, a confiabilidade e a usabilidade. Não é enfeite acadêmico: é a lista de tudo o que pode estar certo ou errado além de "funciona".
Daí saem famílias inteiras de testes especializados. Os testes de desempenho medem o que acontece sob carga e estresse. Os testes de regressão vigiam que uma mudança nova não quebre o que já funcionava. Os testes de fumaça fazem uma checagem rápida de que o essencial sobe, antes de investir tempo em testes profundos.
"Funciona" é a resposta a uma única pergunta. A qualidade se decide nas outras sete.
04 · o estiloComo se testa: roteiro contra exploração
Existe uma tensão saudável entre duas maneiras de testar. A primeira é scripted: casos escritos de antemão, com passos e resultado esperado, que se executam igual toda vez. São ideais para automatizar e para a regressão, porque não dependem de quem os roda.
A segunda são os testes exploratórios: o testador aprende, desenha e executa ao mesmo tempo, seguindo o faro para onde o sistema cheira estranho. Não substituem o roteiro, o complementam. O roteiro encontra o que você sabia procurar; a exploração, o que nem havia lhe ocorrido. Um time que só automatiza fica cego ao inesperado, que é justamente onde vivem os piores defeitos.
05 · o limiteQuanto testar: a armadilha dos cem por cento
A pergunta que todo time faz cedo ou tarde é quanto é suficiente. A resposta honesta incomoda: testar tudo é impossível. O número de estados, entradas e caminhos possíveis de quase qualquer programa real é tão grande que esgotá-los levaria mais tempo do que a vida do produto. Por isso o teste exaustivo é um mito, não uma meta.
O que você pode fazer é testar com inteligência. Você prioriza por risco: onde uma falha doeria mais, quais partes mudam com mais frequência, quais caminhos os clientes usam mais. Um defeito na cobrança não pesa igual a um na cor de um ícone. O teste baseado em risco aceita que os recursos são finitos e os investe onde mais rendem.
Também ajuda entender que os defeitos se agrupam: uma minoria dos módulos concentra a maioria dos defeitos. Se uma área já lhe deu problemas, provavelmente continuará dando, e ali convém cavar. O teste não é justo com o código: é impiedoso com o risco. E cuidado com o paradoxo do pesticida: se você sempre roda os mesmos testes, eles deixam de encontrar defeitos novos, igual a um inseticida repetido que deixa de matar insetos resistentes. Um teste que está há um ano no verde nem sempre é boa notícia: às vezes só deixou de olhar onde o problema agora está.
06 · o fechamentoComo começar sem se afogar
Se você está começando, não monte o edifício completo no primeiro dia. Comece pelo que mais reduz risco com menos esforço: alguns testes unitários sobre a lógica que mais lhe assusta, um punhado de testes de fumaça que confirmem que o essencial sobe, e exploração manual para os fluxos novos e frágeis.
O que não pode faltar, desde o primeiro teste, é o oráculo: a regra clara do que conta como correto. Todo o resto (os níveis, os tipos, a automação) é arquitetura que se constrói em cima dessa base. Sem ela, por mais testes que você tenha, não está testando: está decorando.
O teste bem entendido não é um pedágio que você paga antes de entregar. É a forma mais barata de aprender a verdade sobre seu software enquanto ainda é barato mudá-la: mover a descoberta do defeito o mais perto possível de quando você o escreveu, e o mais longe possível de quando um cliente o sofre.
Fuentes
- International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus, v4.0 (2023). Define termos, princípios do teste (incluindo o agrupamento de defeitos e o paradoxo do pesticida) e níveis/tipos de teste. istqb.org.
- ISO/IEC 25010:2023. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Product quality model. International Organization for Standardization. Modelo das características de qualidade do produto de software. iso.org/standard/78176.html.
- Dijkstra, E. W. (1970). Notes on Structured Programming (EWD249). Origem da máxima "os testes podem mostrar a presença de defeitos, nunca sua ausência".
- Myers, G. J., Sandler, C. & Badgett, T. (2011). The Art of Software Testing, 3.ª ed. John Wiley & Sons. Tratamento clássico do desenho de casos e do teste como processo destrutivo por desenho.