segunda-feira, 12 de abril de 2010

Desenvolvedores não gostam de testar!

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.

3 comentários:

  1. Olá Eduardo!

    Eu acrescentaria uma interrogação no final do título do seu post: "Desenvolvedores não gostam de testar!?" :)

    Concordo contigo sobre o testador e o desenvolvedor terem perfis psicológicos diferentes e que precisamos passar aos desenvolvedores alguns conhecimentos básicos de Teste de Software, como por exemplo, técnicas de modelagem de teste baseadas em estrutura.

    Na minha opinião, quando o desenvolvedor percebe que os testes não existem apenas para encontrar defeitos, e que podem ser utilizados para ganhar confiança, eles podem sim começar a gostar de testar.

    Os testes de unidade e integração fornecem uma "rede de segurança" para os desenvolvedores. Refatorar um código coberto por testes é MUITO mais tranquilo, do que refatorar um código sem nenhum testes.

    Precisamos esclarecer para os desenvolvedores que os testes podem apoiar o trabalho deles, como o Brian Marick mostra no quadrante dos testes ágeis.

    Abraços!

    ResponderExcluir
  2. Oi Fabrício!

    Perfeita a sua observação. O titulo do post tenta, de fato, provocar essa discussão!

    Todos sabemos que testar não é o que um desenvolvedor mais gosta de fazer. Talvez por desconhecimento, não tenha tanto gosto pelo teste, o que é agravado pelas pressões que sabemos existir sobre o seu trabalho.

    É exatamente de uma mudança cultural que estou falando. Reconhecendo o quanto o teste pode agregar à qualidade do software e sabendo o que e como fazer, certamente o desenvolvedor terá maior aceitação sobre as atividades de teste que lhe couberem.

    No final, todos saem ganhando, principalmente o cliente que receberá um produto com mais qualidade.

    Grande abraço e obrigado pela contribuição!

    ResponderExcluir
  3. Olá pessoal,
    Também gostei bastante do post e realmente vivemos hoje esse momento de mudança das visões a respeito das áreas e atuações... Também falei sobre o assunto no meu primeiro post para o blog Bytes don't bite...
    http://bytesdontbite.com/2011/04/26/os-desenvolvedores-podem-testar-seu-proprio-codigo/

    ResponderExcluir