O Google demonstrou nessa série que o maior esforço dos testes fica nos próprios desenvolvedores. Contudo, testar um software não é uma tarefas das mais simples, pois testar envolve decidir o que será testado, como será testado e quais as ferramentas que irão auxiliar nesse processo. Processo este que está em constante evolução e varia de um produto para outro.

Diante de tantas questões a serem respondidas para que um teste ajude a trazer a qualidade tão almejada para o produto, parece necessário que haja alguém responsável por responder a essas perguntas. E é aqui que entram os engenheiros de softwares em testes.

Na Dextra, estamos sempre buscando o quanto podemos melhorar o processo atual de testes em cada projeto. Ou, ainda, talvez estejamos descobrindo o quão importante os testes são para começarmos a avaliar se é necessário ter alguém voltado a isto.

De prático, vemos uma conscientização da equipe em relação ao escopo de cada teste, assim todos entendem se o teste está fazendo realmente o que gostariam. Por exemplo, talvez a melhor resposta ao testar determinada funcionalidade não esteja em um teste funcional, mas em um teste unitário.

É importante citar que nem tudo demonstrado na série do Google pode ser aplicado aos projetos que a Dextra detém. Em nosso cenário, muitos clientes pedem novas funcionalidades para entrega em um curto espaço de tempo, mudam as prioridades do que deverá ser entregue, pedem adiantamento de algumas versões, o perfil do usuário é diferente de um usuário comum, etc. Por essas razões, por exemplo, não seria viável criar vários canais de desenvolvimento. Mas poderíamos pensar em uma forma de aplicar essa metodologia e nos beneficiar dela.

A criação de um canal onde fique apenas uma versão estável do software, e que esteja sob testes de forma contínua, pode ser uma saída para evitar bugs de última hora. Na prática, pode ser que atrase o desenvolvimento na entrega de funcionalidades novas, já que é colocado uma “burocracia” ao processo.

Falando em testes de forma contínua, outro ponto para discussão é facilitar o acesso aos novos projetos a um ambiente de testes de integração contínua e com ferramentas de apoio para gerar relatórios, encontrar duplicações no código, avaliar complexidade, etc. Como esses testes são feitos em máquinas na nuvem (que tem a aprovação do Google), poderia haver uma forma de criar uma máquina padrão com todas essas características e que pudesse ser replicada facilmente para outros projetos. O próximo passo seria conscientizar a equipe da importância desses resultados e de como melhorá-los.

Pode ser também que pouca coisa precise ser alterada para termos um bom progresso nos testes em nossa empresa, de uma forma geral. Ou, ainda, possam haver pessoas que defendam que a forma atual de testes é a mais adequada para a nossa realidade. O principal intuito dessa série é provocar uma reflexão.

Por fim, espero que tenham gostado dos textos. Sem dúvida, existem vários outros pontos que poderiam ser analisados e discutidos com base no que foi apresentado nessa série, mas ficarão para próximos textos que eu, e quem mais gostou do assunto, possa vir a escrever. Recomendo a leitura integral dos textos do blog de testes do Google (http://googletesting.blogspot.com/), tanto da série em que foquei quanto nos outros textos presentes lá. Não deixem também de ler os comentários deixados pelos leitores, pois a maioria deles são bem interessantes e acrescentam bastante a discussão.

Obrigado!

Escrito p0r Dherik Barison