Bug no software! De quem é a culpa?

Na primeira parte do artigo sobre quem leva a culpa quando um bug é encontrado no software, alguns critérios foram empregados para definir a discussão, como a documentação, ambiente de testes e complexidade do requisito funcional. Em continuidade à discussão, este artigo traz uma perspectiva voltada para o processo ao invés de um recurso físico. Vamos continuar?

Há quem diga que a culpa é coletiva e não deve ser direcionada a apenas uma pessoa. Por exemplo, a culpa é do Analista de Sistemas por não alertar a equipe sobre a probabilidade do bug, do desenvolvedor por introduzi-lo e do testador por não encontrá-lo. No entanto, ao invés de despediçar tempo procurando o 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.

Imagem via Shutterstock

Ao se esforçar em decretar a culpa 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 simplesmente continua o mesmo.

Pensando por um lado mais pessoal, direcionar 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, levando-o a procurar por outras oportunidades de emprego. Se a empresa direcionar o foco para os processos ao invés de incriminar a equipe, essa desmotivação se torna um problema a menos e mantém bons profissionais comprometidos.

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!