Bug no software! De quem é a culpa? – Parte 1

Bug no software! De quem é a culpa? - Parte 1Nenhum 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 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 no artigo será bastante imparcial, e somente no final vou manifestar minha opinião, ok?

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 desenvolvedores, 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 quem 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:
1) Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na ferramenta de controle interno da empresa para fins de documentação;
2) Utilizar métodos de análise de causa para descobrir como o erro chegou até a produção;
3) 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!


Confira também as outras partes dessa série de artigos:

Bug no software! De quem é a culpa? – Parte 1
Bug no software! De quem é a culpa? – Parte 2


Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

8 comentários

  1. Excelente artigo e mostra em fundo a realidade da maioria das pequenas e médias empresas que trabalham com desenvolvimento de software, não tem uma cultura de fazer uma correta análise de requisitos e quando a fazem não conseguem trabalhar nos detalhes como regras de negócios, prazos e etc.

    Parabéns pelo artigo aguardando a continuação.

    1. Olá, Wanderson. Exatamente, muitas inconsistências encontradas no software são reflexos de falhas nos métodos de levantamento e análise de requisitos, nos quais as empresas não conseguem detectar.
      Obrigado pelo feedback! Na próxima semana eu publico a segunda parte! Abraço!

  2. Ola Andre,

    Excelente conjunto de artigos, parabéns e obrigado por compartilhar informações em uma linguagem agradável e objetiva. Isso, sem duvidas, valoriza nossa área.

    Grande Abraço.

  3. nossa! parabens pelo artigo, confesso que sempre tive esta duvida, sou iniciante em Delphi 7 e enfrento dificuldades em falhas e bug’s no programa. Geralmente acabo esquecendo do campos Required no formulário. Opção boa é levar o Software a uns 4 usuário bem chato e cricri para eles possam detonar com o sistema, assim encontrando falhas e bug’s.

    abraço vlw pelos esclarecimentos no artigo !

    1. Olá, Flávio! Testes no software são tão importantes quanto a própria implementação. Alocar algumas pessoas (ou usuários) para testar o software é uma boa alternativa, mas eu ainda sugiro os testes automatizados como melhor opção, principalmente por não permitir que futuras manutenções tenham impactos inconsistentes no software.
      Obrigado pelo comentário! Abraço!

  4. O ideal e ter uma equipe de testes de software e não usuários testando o sistema, usuários fazem um tipo especifico de testes e não estão preparados para os outros 80% dos casos.

    1. Olá, André! Concordo com a sua afirmação. A área de testes está se tornando cada vez mais essencial no ciclo de desenvolvimento de software. Acredito que, com as capacitações e treinamentos adequados na área de testes, cada vez menos bugs serão registrados em produção.
      Obrigado pelo comentário! Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.