Vamos olhar para um caso conhecido
Para analisar uma situação concreta, a equipe da cantina confirma uma regra:
cada item do pedido deve ter de 1 a 10 unidades.
Mesmo assim, a primeira versão aceita quantidade 0.
Onde exatamente está o problema?
É fácil dizer apenas: “o sistema está com erro”.
Mas essa frase mistura momentos diferentes da história. Vamos acompanhá-la desde o começo.
Primeiro aconteceu uma ação humana
O desenvolvedor precisava representar a regra:
quantidade entre 1 e 10.
Ao programar, ele verificou apenas o limite máximo e esqueceu o mínimo.
Erro
Neste contexto, erro é uma ação humana incorreta: esquecer uma condição, interpretar mal uma regra, digitar algo errado ou tomar uma decisão inadequada durante o trabalho.
O erro aconteceu na atividade da pessoa. Mas ele deixou uma consequência no produto.
O erro deixou algo incorreto no software
O código acabou aceitando qualquer número menor ou igual a 10, inclusive zero e valores negativos.
Defeito
Um defeito é uma imperfeição existente em um artefato do software: pode estar no código, numa regra documentada, numa configuração, num script ou em outro material usado no desenvolvimento.
No dia a dia, você também ouvirá a palavra bug. Ela é muito usada como sinônimo informal de defeito ou problema no software.
O defeito pode ficar escondido
Agora teste mentalmente:
| Quantidade | O que acontece |
|---|---|
| 3 | O pedido parece normal. |
| 8 | O pedido parece normal. |
| 0 | O sistema aceita uma quantidade que não deveria aceitar. |
O defeito já estava no software quando testamos 3 e 8. Só que esses valores não o tornaram visível.
Nem todo defeito produz uma falha em toda execução.
Quando o problema aparece durante o uso
O usuário informa 0 e o sistema adiciona o item ao carrinho.
Agora temos um comportamento observável diferente do esperado.
Falha
Uma falha acontece durante a execução quando o sistema não apresenta o comportamento esperado para aquela situação.
A sequência inteira
Erro humano: o limite mínimo foi esquecido.
Defeito: a lógica ficou incompleta.
Situação: alguém informa quantidade 0.
Falha: o sistema aceita a quantidade inválida.
O teste não criou o defeito
Quando você tentou quantidade 0, o problema já existia.
O teste apenas colocou o sistema numa situação que permitiu revelar o comportamento incorreto.
Testar é procurar evidências sobre o comportamento do software. Alguns testes revelam falhas; outros aumentam nossa confiança de que determinados comportamentos estão funcionando como esperado.
Mas existe um cuidado: dez testes que passam não provam que não exista um décimo primeiro cenário capaz de revelar outro defeito.
“O teste deu erro” pode significar coisas diferentes
Em conversa informal, essa frase aparece bastante. Vale perguntar:
O teste está incorreto?
Talvez o próprio caso de teste tenha sido escrito com um resultado esperado errado.
Ou o teste revelou uma falha?
Talvez o teste esteja certo e tenha acabado de mostrar um problema real no produto.
Mais adiante, quando automatizarmos testes, essa diferença ficará ainda mais visível.
Testar não é a mesma coisa que corrigir
Imagine que você registre:
Entrada: quantidade 0
Esperado: rejeitar
Obtido: aceitou
Esse registro mostra uma falha. A partir daí, alguém investiga a causa, localiza o defeito e altera o software.
Teste
Avalia o comportamento e procura evidências de problemas ou de conformidade com o esperado.
Depuração
Investiga a causa do problema para localizar e corrigir o defeito. Você também verá o termo inglês debugging, que significa depuração.
As atividades se ajudam, mas não são a mesma coisa.
O problema pertence ao produto, não a uma disputa
Em uma equipe saudável, encontrar uma falha não deveria virar:
“Eu achei um bug.” — “Meu código está certo.”
O teste traz uma evidência. O desenvolvimento investiga a causa. A equipe trabalha para melhorar o mesmo produto.
Qualidade funciona melhor quando evidência vale mais do que defesa pessoal.
Vamos tentar com o cupom
A equipe confirma outra regra para este exercício:
O cupom MBB10 só deve ser aceito enquanto estiver válido.
Imagine que o software verifique apenas se o texto digitado é MBB10, sem verificar a data.
Separe os três momentos
- Qual ação ou omissão humana pode ter ocorrido?
- Que defeito ficou no software?
- Que falha o usuário conseguiria observar?
E se a falha estiver visível, mas a causa ainda não?
Suponha que o total mostrado seja R$ 42,00, mas a soma correta seja R$ 38,00.
Já temos uma falha observável: o total está incorreto.
Mas ainda não sabemos automaticamente onde está o defeito. Pode ser no cálculo, no desconto, nos dados recebidos, na interface ou em outro ponto.
Observar a falha não significa conhecer imediatamente sua causa.
Duas perguntas próximas, mas diferentes
Existe ainda uma distinção importante no trabalho de qualidade.
Verificação
Pergunta se o produto ou artefato está de acordo com aquilo que foi especificado. Exemplo: a regra diz “1 a 10”; o sistema implementa essa regra corretamente?
Validação
Pergunta se aquilo que foi construído realmente atende à necessidade de uso. Exemplo: o limite de 10 unidades faz sentido para a rotina real da cantina?
Um sistema pode seguir perfeitamente uma especificação e ainda assim descobrir, no uso real, que a especificação não atendia à necessidade.
Agora você consegue falar com mais precisão
No começo, era natural dizer:
“Tem um erro na quantidade.”
Agora podemos dizer algo mais útil:
“Observei uma falha ao usar quantidade 0. Existe um defeito na lógica que precisa ser investigado.”
Não é apenas trocar palavras. É separar aquilo que observamos daquilo que ainda precisamos descobrir.
Mas de onde veio o “esperado”?
Ao longo desta etapa nós usamos frases como:
“Esperado: rejeitar quantidade 0.”
Por que esse é o resultado esperado? Quem definiu que o mínimo é 1? Onde essa regra deveria estar registrada? E se duas pessoas entenderem a regra de maneiras diferentes?
Para testar com segurança, precisamos parar de depender de suposições.
Antes de seguir
Você deve conseguir explicar, usando um exemplo da Cantina Horizonte:
- a diferença entre erro humano, defeito e falha;
- por que um defeito pode existir sem aparecer em toda execução;
- por que testar e depurar são atividades diferentes;
- a diferença básica entre verificar o que foi especificado e validar se aquilo atende à necessidade real.