Checar não é testar

Pare de fazer o trabalho dos outros e comece a fazer o seu direito!

Em seis anos trabalhando com testes já vi bastante coisa. Eu já fiz teste manual, automatizado, de interface, de API, de performance, de segurança e muitos outros com os mais variados nomes. Se tem algo que eu gosto de fazer é testar e se tem algo que eu odeio fazer é “testar”.

Quando eu estava começando a trabalhar na área, durante meus estudos li diferentes livros, apostilas e outros materiais, cada um com uma definição diferente para “teste de software”. Esse termo passou a fazer parte do meu dia a dia, mas ainda não sabia qual das definições explicava melhor aquilo que eu fazia, até que o tempo me levou a crer que era a seguinte:

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modelling, observation, inference, etc.” Martin Fowler & Michael Bolton

Existem muitas outras definições baseadas em atender ou não requisitos, verificar diferença entre resultado encontrado e esperado. Essa acima é a mais correta na minha opinião.

O tempo foi passando, muitos testes e “testes” foram feitos e muitas vezes eu me perguntava coisas como “Eu deveria mesmo estar fazendo isso?”, “Sério mesmo que querem que eu faça isso?” ou “Por que eu tenho que fazer isso?”. Algumas coisas que me pediam (e ainda pedem) para fazer que me faziam pensar:

  • Escrever casos de teste para cada requisito;
  • Conferir se o botão ‘X’ faz o que se espera;
  • Comparar a tela com o design para ver se está igual;
  • Verificar se o sistema atende ao requisito escrito;
  • Entre outras…

Essas situações, aliadas às perguntas que me fazia e com a definição que julgo mais correta para teste de software, me levaram a pensar: “Não estou testando nada!”.

Post_Marcelo

Quando escrevo “testar” (assim entre aspas mesmo, até faço as aspas com as mãos), me refiro ao que seria, na definição acima, checar. A ideia desse post não é definir conceitos ou cravar o que é certo ou errado, mas sim fazer com que nós, testadores, botemos a mão na consciência e pensemos “Era isso mesmo que eu deveria estar fazendo?” . Se em um caso de teste está escrito que quando o usuário preencher os campos obrigatórios de um formulário e clicar em “submit” o conteúdo deve ser armazenado em uma tabela no banco de dados, é realmente necessário que alguém, além do desenvolvedor, verifique se o comportamento do sistema é esse? Verificar coisas como essa, ou comparar a imagem criada pelo designer com a tela feita pelo front-end é o mesmo que corrigir uma prova de alguém que a fez com o gabarito em mãos.

Já tive casos como esse do formulário que ao clicar no botão de envio nada acontecia e ao verificar com o desenvolvedor o botão chamava uma função vazia. Em muitas organizações o testador funciona como uma “muleta” para desenvolvedores preguiçosos e, se o problema chega ao usuário final, a culpa é nossa que “não pegamos o problema antes do usuário”. Quantos de vocês já receberam a aplicação cheia de defeitos por que a data estava estourando? E ainda acharam legal porque “UAU encontrei 59 bugs!”.

O trabalho do testador é testar, mas não só isso. Conhecer o sistema, suas funcionalidades, seus pontos fortes e fracos e usar isso para IMPEDIR que os problemas ocorram, sentar com o desenvolvedor e discutir, trocar ideias, desenvolver em par se necessário, entrar no meio do processo de desenvolvimento a fim de evitar surpresas, retrabalho e gastos desnecessários. Encontrar bugs é ruim! Significa que alguém, em alguma etapa do processo, fez algo errado e a responsabilidade é do time TODO, inclusive sua. Se é para testar o sistema depois de pronto, que possamos “gastar” tempo EXPLORANDO a aplicação, achando problemas de verdade, que teriam impacto para o usuário final e para sua empresa.

Checar se o sistema está funcionando é sempre importante! Por isso você e seu time devem automatizar esse tipo de teste, de preferência da maneira mais rápida possível (testes unitários), para que tenham tempo de fazer testes exploratórios depois. Não passe o dia conferindo o trabalho dos outros, faça-se parte da equipe e entenda seu valor como testador.


face

Marcelo Soares, 28 anos, formado em Ciência da Computação pela UNESP-Bauru, trabalha com teste de software desde 2010. Já trabalhou com testes manuais, builds automáticos, testes de performance e muitos outros tipos de teste, atualmente trabalha quase que exclusivamente com automação de testes e melhorias nos processos, como QA Lead na Global Digital Community. Entusiasta da qualidade de software, tem como objetivo difundir a importância dos testadores no processo de desenvolvimento.