Bug no software! De quem é a culpa?

Nenhum software está livre de falhas, isso é fato. Quando um software começa a tomar grandes proporções, a probabilidade de surgir erros durante as atividades de manutenção e evolução são consideráveis. Logo, nos deparamos com uma dúvida no ambiente corporativo: quando um bug é encontrado no software, de quem é a culpa: do desenvolvedor ou do testador?

Introdução

Antes de iniciar o artigo, é importante frisar que este assunto gera muitas discussões. O que me motivou a escrever este artigo foi um tópico no LinkedIn que reuniu a opinião de vários profissionais sob diferentes perspectivas. Portanto, você, leitor, naturalmente poderá discordar de alguns (ou muitos) pontos neste texto. A minha postura aqui no artigo será bastante imparcial.

Vamos partir do conceito básico que gera a funcionalidade do software: o requisito. A análise de requisitos é o alicerce do que será projetado, desenvolvido e testado no software, revelando que a sua documentação é muito importante. Por meio deste raciocínio, podemos utilizar o requisito para identificar o que gerou o bug no software. Observação: não estou mencionando “quem”, mas “o que”. Veja o porque logo abaixo.

Correção do Processo

Há quem diga que a “culpa” da ocorrência de um bug é coletiva e não deve ser direcionada a apenas uma pessoa. Por exemplo, a culpa é do Analista de Sistemas por não escrever os requisitos de forma satisfatória, do desenvolvedor por introduzi-lo e do testador por não encontrá-lo. No entanto, ao invés de despediçar tempo procurando o tal do “culpado”, a empresa deveria preocupar-se em corrigir o processo no qual permitiu a ocorrência do bug, como também o processo que falhou em encontrá-lo. Na minha visão, isso faz total sentido.

Ao se esforçar em apontar o dedo em alguém, a empresa será ineficaz e improdutiva. Em um ambiente ideal, a “culpa”, ou melhor, a não conformidade, é resultado da falha de um  processo e cabe à equipe corrigi-la para evitar novas ocorrências. Este é um procedimento condizente com os conceitos do CMMI, portanto, é altamente adequado.
Na verdade, os processos que abrangem desde o desenvolvimento até os testes deverão ser revistos. Em uma primeira instância, os processos envolvidos na garantia da qualidade do software podem ser averiguados, como, por exemplo:

• Quais são os controles de revisão da atividade de desenvolvimento?
• Existe revisão de código (Code Review)?
• Os desenvolvedores executam testes funcionais no código?
• Os desenvolvedores criam testes automatizados?
• Os testadores criam planos de testes devidamente relacionados ao requisito implementado?
• Quais são os processos de comunicação entre a equipe de desenvolvimento e de testes?
• Existe alguma validação para verificar se os testes criados atendem as expectativas?

Observe que os 7 itens acima, ao invés de refletirem a culpa em uma única pessoa, refletem em conjuntos de atividades, ou seja, em processos. Dessa forma, o termo “culpa” é transformado em “falha do processo” e toma uma dimensão abstrata.
Mesmo que uma equipe tenha ótimos desenvolvedores e testadores, é necessário que exista processos bem definidos para a validação da implementação. São os processos que giram as engrenagens no fluxo de atividades de uma empresa.

Para facilitar a compreensão, imagine que, em uma fábrica de móveis, uma determinada peça de um produto está sendo pintada antes de ser cortada. De modo geral, essa falha não está relacionada aos operadores, mas ao processo de fabricação. Basta inverter as funções de corte e pintura para que a falha deixe de existir. O trabalho dos operadores continua o mesmo.

Conclusão

Pensando por um lado mais pessoal, direcionar a culpa pode ser prejudicial para a equipe e é sinônimo de desmotivação. No ambiente corporativo, é comum que um profissional seja raramente reconhecido pelos seus esforços e excessivamente punido pelos seus erros. Se a empresa direcionar o foco para os processos ao invés de incriminar a equipe, essa desmotivação é minimizada.

Certa vez, li um estudo de caso de uma empresa que, ao trocar o direcionamento da culpa pela revisão dos processos, diminuiu a ocorrência dos bugs em produção em 50%. E só pra constar, essa porcentagem não é fixa. Na proporção em que o processo de desenvolvimento é aprimorado, a tendência de erros no software é cada vez menor, naturalmente.

Antes de fechar o artigo, devo dizer que bugs no software não devem ser considerados apenas como vilões. Nós aprendemos com os nossos erros, certo? Portanto, os bugs representam uma excelente oportunidade de aprendizado desde que sejam utilizados a nosso favor. Cada bug identificado, resolvido e rastreado contribui para a maturidade tanto dos processos quantos dos próprios profissionais.

Além disso, equipes devem ser colaborativas e cooperativas. Testadores, por exemplo, enxergam o software em uma perspectiva diferente dos desenvolvedores, os ajudando a identificar suas próprias falhas e aumentar o campo de prevenção de erros. Oras, isso pode ser parte do processo, não é? Claro!

Aqui termino o artigo, leitores.
Espero que os pontos de vista apresentandos aqui tenham sido úteis!
E lembre-se: não se esforce em encontrar o culpado. Se esforce em melhorar os processos!

Semana que vem eu volto!