Introdução
Testar não é apenas clicar até encontrar um erro antes da publicação. É investigar se o software se comporta de maneira coerente em cenários importantes e aprender onde ainda existe risco. Um teste pode confirmar um comportamento esperado ou revelar que uma suposição estava errada.
Também é importante entender que nenhum conjunto de testes prova que um sistema não tem defeitos. Ele oferece evidências, e a qualidade depende de requisitos claros, revisão, design, implementação, operação e aprendizado.
O que um teste procura?
Um teste começa com uma pergunta. O cadastro rejeita dados obrigatórios ausentes? Uma pessoa sem permissão é impedida de consultar um documento? Um relatório mantém os filtros escolhidos? Uma falha de integração produz uma mensagem compreensível?
Para responder, defina contexto, entrada, ação e resultado esperado. Inclua casos normais, limites e situações inválidas. O objetivo é escolher cenários que representem o risco do produto, não acumular passos sem propósito.
Níveis de teste
Teste unitário
Verifica uma unidade pequena de comportamento, como uma função ou regra, com dependências controladas. É rápido e ajuda a localizar a origem de uma falha. Muitas vezes, essa unidade é um método de uma classe descrita no diagrama de classes.
Teste de integração
Avalia a interação entre partes, como serviço e banco de dados ou sistema e provedor externo. Pode revelar problemas de contrato, configuração e tratamento de erro. Um diagrama de sequência ajuda a enxergar quais mensagens e retornos entre essas partes precisam ser verificados.
Teste de sistema
Examina um fluxo mais completo em condições próximas do uso. Ajuda a verificar se componentes colaboram para entregar uma capacidade.
Teste de aceitação
Relaciona o comportamento ao objetivo do negócio e às expectativas das pessoas usuárias. Pode envolver exemplos revisados com quem solicitou a funcionalidade. Os fluxos principal e alternativos de um caso de uso são boas fontes para esses cenários.
Tipos e estratégia de testes
Os níveis indicam a abrangência da verificação; os tipos indicam o que está sendo investigado. Testes funcionais verificam comportamentos, testes de regressão procuram impactos de mudanças, testes exploratórios usam investigação guiada e testes não funcionais avaliam qualidades como desempenho, acessibilidade ou segurança.
Uma estratégia proporcional combina técnicas. Um fluxo de pagamento pode exigir teste unitário para regras de cálculo, integração com o provedor, teste de sistema do fluxo completo e aceite com o critério de negócio. O risco e o impacto ajudam a decidir onde investir mais.
Pirâmide de testes
Como escrever um caso de teste claro
- Relacione o teste a um requisito, regra ou risco.
- Descreva o contexto inicial e os dados relevantes.
- Use uma ação objetiva e um resultado observável.
- Inclua pelo menos um cenário de exceção quando ele for importante.
- Evite depender de detalhes visuais que não fazem parte do comportamento.
Uma forma curta de escrever é “dado que, quando, então”: dado que o documento já existe, quando a pessoa tentar salvar outro registro com o mesmo valor, então o sistema deve impedir a duplicidade e explicar o motivo.
Para cenários com mais detalhes, vale separar cada parte. Veja um exemplo completo:
Requisito: uma pessoa atendente não pode criar duas reservas para o mesmo recurso no mesmo horário.
- Pré-condição: existe uma reserva confirmada para o recurso A entre 14h e 15h;
- Entrada: tentar criar nova reserva para o recurso A no mesmo intervalo;
- Resultado esperado: o sistema recusa a operação, explica o conflito e mantém a primeira reserva;
- Variação: uma reserva para 15h deve ser aceita quando não houver outra restrição.
O mesmo comportamento pode ser verificado manualmente em uma validação exploratória e automaticamente em uma suíte de regressão.
Requisitos e evidências
Um requisito precisa de uma forma de verificação, seja ele funcional ou não funcional. Se o requisito diz que apenas pessoas autorizadas podem exportar dados, o caso de teste deve incluir um perfil permitido e um perfil sem permissão. Se diz que uma busca deve responder em até dois segundos, o teste precisa registrar volume, ambiente e condição de medição.
Essa relação pode ser documentada em uma matriz simples entre requisito, cenário, resultado esperado e evidência. Ela facilita a revisão de mudanças e mostra o que ainda não foi verificado.
Quando automatizar?
Automação é valiosa quando o teste é repetido, importante e possui resultado verificável. Testes automatizados podem proteger regras centrais e detectar regressões a cada alteração. Mas nem todo teste precisa ser automatizado: exploração, usabilidade e algumas avaliações visuais dependem de investigação humana.
O glossário do ISTQB é uma referência confiável para a terminologia de testes. Na prática, escolha uma estratégia proporcional ao risco e ao contexto.
Conclusão
Testes de software aumentam a qualidade porque transformam expectativas em perguntas verificáveis. Eles ajudam a encontrar defeitos, compreender riscos e dar confiança para evoluir. Comece por comportamentos importantes e crie exemplos que outra pessoa consiga entender e repetir.