Quando observamos os perfis psicológicos de desenvolvedores e testadores, percebemos algumas diferenças importantes na maneira de pensar desses profissionais.
Basicamente, os desenvolvedores têm suas energias direcionadas para a conclusão do projeto, sempre buscando executar com sucesso a implementação do software e provar que ele funciona. É uma forma de pensar muito diferente dos testadores, que estão sempre em busca de defeitos, certamente com o objetivo de trazer mais qualidade ao software, mas que pode parecer conflitante com a idéia de entrega do produto final. Até fora do trabalho, os testadores estão sempre procurando defeitos. Qual testador nunca se pegou perseguindo defeitos em placas de trânsito e anúncios pelas ruas ou em embalagens de produtos no supermercado? Esse comportamento faz parte do perfil do testador, que é um crítico por natureza.
Mas voltando aos desenvolvedores, sabemos que os testes podem e devem ser realizados também por eles. A grande questão é como convencer um desenvolvedor a investir esforço em testar o seu produto. Os testes seriam sempre direcionados a provar que a aplicação funciona ou podemos adotar alguma abordagem que garanta uma certa isenção do desenvolvedor em relação ao produto e mais qualidade para os testes?
Sabemos que uma boa parte dos defeitos pode ser identificada nos testes em nível unitário e integração, que normalmente ficam à cargo da equipe de desenvolvimento, quando existe na organização uma separação de papéis entre desenvolvedores e testadores. Dessa forma, a capacitação dos desenvolvedores para que realizem mais e melhor os testes sob sua responsabilidade, pode ser um investimento com possibilidades de excelente retorno para os projetos de desenvolvimento. Passar aos desenvolvedores conhecimentos básicos sobre testes pode fazer uma grande diferença na qualidade das aplicações. E nada que exija técnicas elaboradas de teste ou um esforço muito maior do que aquele já investido. Todo desenvolvedor testa, de alguma forma, a sua aplicação. O quanto ele testa é que é o problema. Como o seu foco é provar que a aplicação funciona, normalmente apenas o "caminho feliz" é testado e grande parte do código não é exercitado.
Mesmo sem exigir profundos conhecimentos em testes, podemos ampliar significativamente a quantidade de testes executados, se no planejamento dos testes unitários e de integração for acordado um determinado nível de cobertura sobre o código, compatível com a criticidade da aplicação e com os riscos do projeto. Dessa forma, o desenvolvedor deverá perseguir essa cobertura do código em seus testes, sem necessariamente ter que modificar muita coisa na sua forma de testar. É claro que para que isso seja possível, será necessária a utilização de ferramentas apropriadas para avaliar o atingimento da cobertura esperada. Os testes nos níveis a cargo do desenvolvedor precisam ser apoiados por ferramental específico, de tal forma que o desenvolvedor possa direcionar sua atenção prioritariamente para o desenvolvimento e os testes ocorram de uma maneira natural para ele e com o menor esforço possível. A automação criteriosa dos testes e o direcionamento à cobertura do código podem evitar que grande parte dos defeitos seja identificada apenas em níveis posteriores de testes ou mesmo em produção, quando os custos de correção são muito maiores.
O mais importante de tudo isso é conseguir que o desenvolvedor teste o seu código com uma profundidade adequada, sem ser obrigado a realizar atividades que sejam conflitantes com o seu perfil. Com o apoio de ferramentas para avaliação da cobertura de código na execução dos testes, o teste será encarado como um aliado pelos desenvolvedores, e a qualidade final do software será a grande beneficiada.
