O aprendiz foi até o programador mestre e disse:
“Todos os meus testes sempre passam. Não mereço um aumento?”
O mestre acertou uma tapa no rosto do aprendiz e respondeu:
“Se todos os seus testes passam, sempre que são executados,
você precisa escrever testes melhores.”
Com a bochecha vermelha, o aprendiz foi até os recursos humanos para reclamar.
Mas essa é outra estória.
É de fundamental importância que todos os envolvidos no ciclo de vida de um software entendam cada vez mais a integração entre as disciplinas de desenvolvimento e testes, o trecho destacado acima foi retirado do Guia para testes unitários, elaborado por Alberto Savioa da Agitar Software, o qual apresenta de forma simples, divertida e direta um fundamento básico a ser trabalhado em ambas as áreas.
Definir o que é um bom teste de software não é algo simples, seja ele um teste unitário feito pelos desenvolvedores ou mesmo testes funcionais ou não-funcionais elaborados pela equipe de testes. Considerando apenas os aspectos mais básicos, um bom conjunto de testes precisa alcançar uma boa cobertura da aplicação e ser eficiente na tarefa de identificar as falhas presentes no software.
No entanto, me impressiona o número de profissionais de TI, inclusive engenheiros de teste, que não se incomodam quando um ciclo de testes executado apresenta 100% dos casos de teste como passados, e ainda percebem isso como um claro indicador de que o software está “livre” de defeitos. Uma análise, que muitas vezes pode se mostrar enganosa e levar a muitos prejuízos.
Um dos princípios de Testes de Software, segundo o livro “Fundamentos de Testes de Software”, fala sobre a ilusão da ausência de defeitos, o qual tenta alertar contra o fato de que a ausência de bugs, não necessariamente significa que o sistema desenvolvido atende a um determinado padrão de qualidade ou mesmo às necessidades do usuário. Afinal, o problema pode estar nos próprios casos de teste, no planejamento ou até mesmo na maneira como os mesmos foram executados.
Princípio – Não caia na ilusão da ausência de defeitos.
Em outras palavras, um teste que não encontra falhas
é diferente de concluir que o software está livre de defeitos.
Devemos assumir que todo software contém algumas falhas,
ainda que estas estejam escondidas.
Logo, seja você um desenvolvedor ou testador, que cria testes manuais ou automáticos e os executa, é preciso ter bastante cuidado ao analisar a eficiência do seu conjunto de testes. Revisar constantemente os testes mais antigos e avaliar os defeitos escapados são boas práticas que podem contribuir na evolução dos testes.
Por fim, precisamos nos desapegar um pouco da associação teste passado e sucesso, e avaliar a cada estágio de teste o nível de confiança que podemos ter nos resultados obtidos, estando sempre atentos ao significado do termo “qualidade” para cada cliente ou projeto.
Bytes don't Bite! 
Entendi o que o autor quis dizer com “bons testes falham”, legal, mas bons testes também passam, o que faz um teste ser bom ou não ser não se limita apenas a falhar ou passar, é além disso, é mais ou menos uma soma da cobertura (%) com a imprevisibilidade, quero dizer que quanto maior a probabilidade de um teste não ter sido previsto pelo desenvolvedor maior será o risco de existir um risco ali, e quanto maior a abrangência da soma de todos os testes melhor também, as vezes testes “bobos” falham e testes melhores (mais difíceis de serem planejados) passam, concordo que o teste que falha é aquele que ajuda a melhorar a qualidade do sistema, mas o teste que passa (se corretamente executado), principalmente se forem os fluxos mais críticos, podem ser mais confortantes do que achar um erro de layout, por exemplo. Imagino que em parte o autor também entende o que eu digo e que nunca foi intenção do mesmo dizer SÓ os testes que falham que são bons, apenas dei meu comentário ^^
Isso mesmo Felipe, a ideia do post foi focar na importância de termos cuidado também quando nossos testes passarem, deixando claro também a dificuldade natural que existe em avaliar os testes.
No texto falei apenas de cobertura e na capacidade de achar falhas, mas claro que tal qual você mesmo falou, para podermos ter confiança no produto que está sendo desenvolvido precisamos de testes (que podem ser simples) garantam uma cobertura boa da aplicação.
Eu compreendi o que Felipe falou, mas o que Carreira quis dizer eh que quando voce faz um plano de teste e na primeira execucao ele alcanca 100% passed, tem coisa errada nesse planejamento, testes muitos superficiais ou ciclo sem muita cobertura, etc.
Acredito que o esforco do testador para encontrar falhas vai depender muito dos processos (filosofia) da empresa. Eu trabalhei numa empresa que se o cara encontrasse uma falha, tinha que reproduzir com 100% de exatidao e depois de fazer um reset de dados no software, e isso nao existe.
Um grande problema que existe eh que quando novos testadores entram na area, a primeira coisas que eles aprendem eh que achar defeitos eh muito ruim, pois vai atrasar o plano, vai dar retrabalho ao desenvolvedor, se abrir defeito errado vai ficar mal visto pela equipe, essas coisas.
Quando voce da liberdade ao testador para reportar falhas, mesmo que elas nao se reproduzam, voce cria um habito bom de procurar por falhas.
Sempre quando eu passo conhecimento para alguem que esta iniciando, eu digo: “eng. de teste eh algo que vai ao contrario da eng. de software, pois enquanto a eng. de soft cria metodos para evitar erros, eng. de testes so tem razao de existir para quebrar codigo (achar falhas)!!”
Correto, para o engenheiro de testes é fundamental a busca sempre pela falha… O que não quer dizer que não ficamos felizes em ver o software funcionando corretamente, pelo contrário é um processo de amadurecimento da ferramenta e que aos poucos vai alcançando um nível de estabilidade tão bom, que as falhas vão se tornando mais raras.
Ótimo post, só gostaria de ressaltar algo sobre os testes de regressão. Acredito que quando há testes regressivos (automatizados ou não) naquelas áreas vitais do sistema o fato de os mesmos não falharam pode significar que essas áreas adquiriram um certo grau de confiabilidade, claro que apoiado a isso devem estar as métricas de defeitos ocorridos em produção que podem efetivamente demonstrar que os testes estavam “certos” pois também não foram encontrados defeitos em produção nessas áreas.
Perfeito. O importante é ter sempre essa atuação completa, analisando a eficácia de um ciclo não apenas pelo percentual de testes falhados/passados.
Admitindo que seja bom que os testes de regressão não falhem, acredito também ser boa prática dar uma “sacudidela” nos testes que por regra passem sempre.
Os sistemas tendem a evoluir para o equilíbrio e se a “coisa” não for agitada o efeito de pesticida pode-nos dar uma falsa sensação de segurança.
De qualquer forma uma funcionalidade pode ser testada de várias formas e por isso gosto de reescrever os testes que passem sempre de forma a testar doutra forma.
Um abraço do outro lado do Atlântico e parabéns pelo artigo.
Obrigado pela contribuição!
De fato a prática de reavaliar os testes que passem sempre é exemplar!
Dependendo do contexto que eu estou trabalhando eu fico muito feliz quando meus testes automatizados passam 100%, isso é uma garantia de que, aparentemente, nenhum bug novo foi introduzido e de que ciclo a ciclo estamos conseguindo uma boa cobertura de testes.
Uma suite que passa com 100% quer dizer que estamos no caminho certo, mas precisamos melhorar ainda mais a cobertura desenhando novos cenários e possibilidades de teste.
Isso é uma garantia sim, no meu ponto de vista, mas como citado o software não está livre de defeitos.
O que devo fazer quando um ciclo de regressão passa 100%?
Devo primeiro passar dias e dias tentando encontrar um defeito para provar que o software não está bom ou devo confiar na regressão e poder entregar o software com qualidade que o cliente deseja?
PS: ótimo post 🙂
Abraços!
Elias, obrigado pela contribuição. De fato, sua afirmação foi precisa, quando temos um ciclo de testes automatizados, o qual já temos confiança de sua capacidade, o 100% passado de fato nos deixa confiantes de que nenhum bug novo foi introduzido.
De qualquer modo a análise sobre a qualidade e o nível de confiança no software não possui apenas fatores mensuráveis, a análise crítica da equipe é de fundamental importância para liberarmos uma versão desenvolvida.
Muito bom seu artigo. A melhor definição de testes que já encontrei foi de uma pesquisadora do COPPE: “Teste é uma tarefa destrutiva a curto prazo, mas construtiva a longo prazo.”. Isto é temos de tentar destruir um sistema/aplicativo para construir um melhor e mais robusto.
“Como o código é resultado do trabalho intelectual do
programador, procurar erros é uma espécie de ataque às suas próprias convicções.”. WEINBERG, GM. The Pisicology of Computer Programming. Litton Educational
Publishing Inc, 1971.
Isto serve não apenas para código, mas para artefatos de especificação e projeto.
Excelente suas citações Érica. Definem em poucas palavras e de maneira clara esse lado psicológico da atividade.
E de fato não se aplicam apenas ao código, o quanto antes agirmos em relação a todos os artefatos do projeto, com a visão de profissionais diferentes, poderemos iniciar a construção de sistemas mais robustos.
[…] rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham) Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes […]
[…] post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes […]
Qual e o significado da palavra bdb
bytes don’t bite