Os desenvolvedores podem testar seu próprio código?

Por esses dias, estive relendo os posts sobre como são conduzidas as atividades de testes no google, entre outras coisas eles falam sobre os papéis, funções e de que maneira a qualidade de software é conduzida dentro da empresa.

No terceiro post da série, diversas afirmações chamaram a minha atenção e valem a nossa reflexão:

“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place?”

A partir dessa afirmação podemos ver que estamos passando por uma grande transição na engenharia de software. Onde há vários anos as empresas dão uma ênfase cada vez maior aos aspectos relacionados à qualidade de software e diversas estratégias surgiram e vêm sendo utilizadas para a organização das equipes e divisão das tarefas.

Porém, o que mais me chama atenção nessa primeira afirmação é como a idéia a que estava acostumado, de que precisamos de pessoas com dois perfis diferentes para testar e desenvolver um software está ficando ultrapassada.

Make it or Break it

Cada vez mais precisamos unir as duas disciplinas que se completam para assim entregar produtos de maior qualidade.

Claro, que para que isso aconteça é necessária uma mudança cultural e comportamental. Abandonarmos os antigos conceitos de que desenvolvedores não conseguem enxergar as falhas em seu próprio código, não gostam e não querem testar e tornar tudo em uma única tarefa.

Diversos benefícios podem emergir dessa tendência, como: detecção de defeitos cada vez mais cedo, maior liberdade para o engenheiro de teste focar em aspectos não funcionais, fluxos de integração e outros pontos que fogem a unidade do desenvolvedor, etc.

  “quality is more an act of prevention than it is detection”

Desse modo, técnicas como o TDD podem ser excelentes caminhos para eliminar essa separação entre testes e desenvolvimento. Ajudando a tornar a qualidade cada vez mais um ato de prevenção do que detecção.

” Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved”

É óbvio, que existem diferenças entre os diversos tipos de projetos e na realidade de cada uma das empresas, onde cada um possui necessidades diferentes as quais precisam ser avaliadas e planejadas.

Está cada vez mais claro o caminho para produzirmos softwares de maior qualidade, testes e desenvolvimento como uma só tarefa, apresentando um grau de automação cada vez maior. Para seguirmos esse caminho várias mudanças são necessárias tanto nas pessoas, como nos processos e ferramentas.

E vocês o que acham? É esse o caminho a ser seguido?

Anúncios

8 comentários sobre “Os desenvolvedores podem testar seu próprio código?

  1. Carréra, antes de tudo, ótimo post.

    Quando iniciei meu trabalho com testes, eu já havia trabalhado com desenvolvimento. Os conhecimentos de desenvolvimento me foram bem úteis nesse meu período inicial na área (principalmente pelo fato de o produto testado ser um ambiente de desenvolvimento para J2ME). No ânimo da quantidade de bugs encontrados, na busca por técnicas e mais técnicas que comprovavam que um desenvolvedor poderia encontrar vários bugs na aplicação, eu me vi cada vez mais fechado a aceitar que um tester não soubesse desenvolver.

    Eu estava errado!

    Hoje em dia eu considero, muitas vezes, mais importante o desenvolvedor ser capaz de testar do que o testador ser capaz de desenvolver. Por que isso? Vários erros que encontrei, no longo desse meu caminho em testes, poderiam ser simplesmente descobertos se o desenvolvedor estivesse focado em qualidade e procurasse entender o que ele estava fazendo, antes de codificar algo.

    Mas e o engenheiro de testes saber codificar? Em posts anteriores (1 e [2]) eu levantei pontos relacionados a isso. Em certos casos, considero necessário o engenheiro de testes ter conhecimentos de programação e em outras situações desejável. Ao testar um ambiente de desenvolvimento é preciso ter esse conhecimento. Para testar um sistema que possa envolver risco a integridade física de um humano, não recomendo utilizar técnicas de teste caixa-preta. Mas para testar um sistema simples de cadastro e relatórios, codificar pode passar a ser apenas um atributo desejável pro tester.

    Automação de testes, análise estática de código, teste de performance, teste de segurança, aplicação de técnicas de prevenção de falhas, saber trabalhar com banco de dados, entender de arquitetura, conhecer sobre redes, saber as falhas das tecnologias trabalhadas, entender nos mínimos detalhes como o software funciona, tudo isso é interessante para pessoas de teste. Em testes, existem várias áreas de conhecimento a serem exploradas. Entretanto, não sei se exigir que alguém trabalhando com testes de usabilidade, por exemplo, deva saber codificar é uma boa idéia. Cada perfil tem sua importância de acordo com o projeto (as necessidades do cliente, o tempo do projeto, o tamanho do produto, os recursos disponíveis, etc).

    Mas note que em hora alguma eu disse que o testador não deve saber desenvolver. Ainda hoje tento espalhar que é bom o testador saber codificar. Só não acho que isso venha a ser uma obrigação (como eu achava a alguns anos atrás) para todos os casos. E ainda adiciono que os conhecimentos em detalhes, do software, podem vir a ser uma boa arma para um bom engenheiro de testes.

    Acho que com isso eu respondo a tua pergunta (no meu ponto de vista) sobre se esse é o caminho a ser seguido. 🙂

  2. Olá brother,
    Respondendo a sua pergunta, acho muito rico e importante que o desenvolvedor esteja inserido na execução dos testes. Claro, não sou a favor de que ele teste o próprio código desenvolvido. Neste caso deve existir uma troca entre os desenvolvedores. Estou trabalhando num projeto ágil e posso tomá-lo como exemplo para expor os resultados que são positivos, reportados pelos próprios desenvolvedores:
    1. Visão mais ampla do sistema;
    2. Começa a pensar como testador;
    3. Prevenção dos possíveis erros detectados pelos testadores;
    4. Contribuição efetiva para o melhoramento do projeto de testes, indicando pontos mais críticos do sistema e cenários não abordados;
    5. Aumenta o comprometimento e preocupação com o que está entregando para o cliente;
    entre outros…

    Mas, vale salientar que um desenvolvedor só é eficaz nos testes quando ele se compromete.

    Abraços,
    Leandro Santos

  3. Olá Burgos, na minha opinião todo desenvolvedor deveria ser TSTer. O desenvolvedor que passa algum tempo testando o código (de outro desenvolvedor ou não) muda muito a forma de pensar e tende a evitar BUGs que encontrou enquanto testava. Isto melhora muito a qualidade do SW deste desenvolvedor.

    Contudo, isto não significa que o engenheiro de testes deixaria de existir, apenas eles iriam achar menos BUGs triviais, o que infelizmente ainda é bem corriqueiro na maioria dos projetos.

    Enfim, ainda não conheci um bom desenvolvedor que não fosse um bom TSTer. Quanto melhor o desenvolvedor menos BUGs encontramos no seu código, pois a verdade é que ele (às vezes até sem notar) pensa no que pode dar errado durante a codificação (exatamente como um bom TSTer).

    • Ah, eu conheço excelentes desenvolvedores que não são bons testers. É fato, o desenvolvedor é focado em cada pequeno pedaço do sistema. Quem testa, além de ja ter em mente de que ele deve achar bugs, a sua visão é macro. E claro, o dia a dia te mostra os pontos onde podem ocorrer maiores falhas, tanto por conhecimento do sistema, quanto por ter noção de como o desenvolvedor acaba pensando na hora de desenvolver.

  4. Valeu José!
    Cara seu post é realmente muito bom.
    Posso adicionar um link no bugless.wordpress.com para o seu site, como páginas amigas?

    Att.
    Paulo Marcos – bugless.wordpress.com

  5. Trabalhei em diversas empresas de software e o mesmo problema se apresenta entre testadores , analistas ,arquitetos, engenheiros e desenvolvedores. Hj quase ninguém precisa conhecer as tecnologias envolvidas, parece que com um livro magico ou determinado software .
    resolve todos os problemas… Papeis sao criados para justificar necessidades inexistentes enquanto o conhecimento se esvai e pessoas sem conhecimento algum ocupam lugares que nao deveriam.E todo o problema se resume a isso Pessoas nos lugares errados. Todos tem que ter a base do conhecimento da area que atuam nao so word excell e mexer com o mouse.
    Os melhores generais sao aqueles que estiveram no campo de batalha e conhecem os meandros da guerra. Criam-se equipes inteiras gigantes com prerrogativas inuteis onde estratificam-se os papeis ridiculamente priorizando a ignorancia na tecnologia ao inves do conhecimento.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s