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, de quem é a culpa: do desenvolvedor ou do testador?
Antes de iniciar o artigo, é importante frisar que este assunto gera muitas discussões. O que me motivou a escrevê-lo 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 no artigo será bastante imparcial, e somente no final vou manifestar minha opinião, ok?
Imagem via Shutterstock
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 quem ou o que gerou o bug no software.
Se o requisito foi documentado, mas não testado adequadamente, pode-se afirmar que a culpa é do testador. Por outro lado, se o requisito foi impropriamente compreendido, ou seja, sua documentação foi de difícil interpretação técnica, a culpa cai no desenvolvedor, já que, na lógica ideal do processo, a imprecisão da documentação deve ser detectada pelos desenvolvedores e questionada para ser esclarecida. Por fim, se o requisito nem foi documentado, a culpa obviamente é do Analista de Negócios.
Ainda falando sobre requisitos, podemos estender as nossas condições baseando-se na sua complexidade. Se o bug encontrado no software for tão óbvio ao passo que deveria ser testado baseado na documentação do requisito, então a falha ocorreu na fase de testes. Neste caso, é necessário avaliar a eficácia do trabalho dos testadores.
O bug também pode ser resultado da implementação de um código não contemplado na documentação do requisito. Algumas vezes, os desenvolvedores acrescentam códigos (decorrente de uma refatoração, talvez) que afetam outras partes do software, criando bugs paralelos. Como está fora do âmbito do requisito, estes bugs evidentemente não são encontrados pelos testadores, portanto, os desenvolvedores devem ser responsabilizados. Os efeitos colaterais em algum ponto do software causado por novas implementações podem ser evitados com testes automatizados. Isso também nos convém que, se o teste automatizado não detectou o efeito colateral, a responsabilidade é de quem o criou.
Porém, há casos em que o bug somente é encontrado depois de uma bizarra combinação de cenários e variáveis, decorrente de um teste exaustivo. Dependendo do tamanho do requisito, este teste pode levar horas, tornando-se inviável para os testadores. Estes bugs “camuflados” são difíceis de serem direcionados a algum responsável, embora ligeiramente possa aparentar um erro de especificação.
No parágrafo seguinte, vou conceder um pouco de crédito aos testadores.
Para que um bug seja devidamente encontrado pela equipe de testadores, eles precisam ter o ambiente corretamente configurado para essa atividade. Em outras palavras, testadores somente podem exercer adequadamente suas atividades se estiverem providos de recursos, documentação, ferramentas e tempo aceitáveis, na quantidade que eles precisam. Este ambiente aumenta a capacidade dos testadores para encontrar erros no software.
Como desenvolvedor, imagine que nos foi entregue uma documentação mal elaborada e uma ferramenta de desenvolvimento cheia de problemas. A implementação não seria satisfatória, concordam? Esse é o ponto.
Além disso, imaginem a seguinte situação: os testadores realizaram os testes necessários, mas o gerente de projetos, no último minuto antes da liberação da versão, aprovou uma funcionalidade no sistema que se dizia impeditiva. Devido ao prazo curto para liberação, os testadores tiveram de testar às pressas a nova funcionalidade que, ao entrar em produção, ocasionou em um bug no software. Se disserem que a culpa é dos testadores, está correto? Há outros parâmetros nessa situação: a pessoa que detectou a funcionalidade impeditiva, o gerente de projetos e o tempo extremamente curto. Portanto, é algo a se pensar.
Vamos dar sequência na discussão.
Depois que o erro é encontrado, podemos declarar que o procedimento ideal seria:
- Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na ferramenta de controle interno da empresa para fins de documentação;
- Utilizar métodos de análise de causa para descobrir como o erro chegou até a produção;
- Certificar-se de que a causa seja resolvida para evitar ocorrências futuras.
No entanto, muitas empresas apenas cumprem o primeiro passo. E digo: muitas mesmo!
Oras, somente consertar o bug irá gerar um “software funcionando”, porém, não ajudará a revelar o problema recorrente no processo que ocasionou o bug e que provavelmente poderá causar novos erros.
Sim, no processo! Esse é o tema da segunda parte deste artigo, no qual apresentará uma perspectiva diferente sobre essa discussão. Aguardem!
Até a próxima semana!
4 Comentários
Gostei da matéria e estarei acompanhando atentamente… Foi uma ótima proposta de matéria… Existiam duvidas nesse ponto e já inicie uma analise em cima do que relatou na matéria….
Olá, Adelson! Fico contente que tenha se interessado pelo assunto. Espero que também goste da segunda parte! Abraço!
Pingback: Como criar um ambiente inovador na sua empresa! | Fernando Neumann Rodrigues
Prezados, tenho muitas dúvidas em relação a esses acontecimentos frequentemente na empresa.
Tenho 7 anos de carreira e ainda não sei como e onde ver o culpado, em relação a lei e direitos tanto para contratos Pj e CLT.
Um fato, por exemplo: Um analista de negocio ver erro e pede alteração no boleto bancário, analista de software desenvolve procedimentos e fluxos para desenvolvimento, o programador realiza os procedimentos e faz correção.
É feito um teste de software somente pela área de negocio, o mesmo valida. Neste caso outra área descobre um erro no faturamento recorrente a essa alteração. O controlador de versão da aplicação ver o último desenvolvedor que publicou e o culpa. Se for clt demissão por justa causa. Porém de quem é a culpa perante a lei, quais leis se aplica lei de software ou clt ? assuntos ainda não muito discutido no nosso ramo analise e desenvolvimento de sistema.