A origem dos bugs de software

bugs de softwareQual é a origem dos bugs de software? As causas estão apenas no código fonte “bugados”? Exception é o único efeito causado pelos bugs?

É algo surpreendente quando entendemos que a maior causa dos bugs não está no código fonte.

Neste post vamos entender como os bugs surgem nos projetos de software, e perceberemos que o problema vai muito além de furos na codificação

Bugs são Defeitos

Em termos práticos, bug de software é um defeito no software. Por uma questão de lógica tendemos a pensar que apenas uma coisa em funcionamento pode ter defeito.

Se algo não está funcionando como deveria, há um defeito.

Mas é uma visão muito materialista acerca dessa questão. Vamos pensar em dois cenários distintos para compreender melhor este raciocínio.

Bugs se manifestam apenas no produto final?

bugs de software - Causa e Efeito

Imaginemos um bebê que nasce com alguma deficiência, ou uma fruta que nasce com alguma deficiência.

Quando um bebê nasce com alguma deficiência física, por exemplo, identifica-se tal deficiência a partir de algum exame físico no corpo do bebê.

Se não há um corpo, a maioria entende que, em princípio, não há como identificar a deficiência, pois “não há o que examinar”.

No caso da fruta, se tivermos por exemplo, duas bananas coladas (ao invés de separadas – quando eu era criança minha mãe falava que eram bananas gêmeas, rs), o raciocínio aplicável é semelhante.

Identifica-se a deficiência na banana porque ela está materializada. Se não há banana, a maioria entende que não há como identificar a deficiência, pois não há o que examinar.

Mas precisamos entender que antes de algo se materializar “de fato”, é necessário haver um projeto daquilo, que é refletido em um modelo. Não é plausível algo ser produzido sem um modelo anterior. Se assim fosse, o mundo perderia sua lógica, pois haveria mágica ao invés de engenharia!

/* Lembrando que mágica é uma ilusão. Todo efeito tem causa, isso é uma lei (procure sobre Lei de Causa e Efeito) para entender melhor.*/

No caso dos bebês, há modelos genéticos por trás do corpo materializado, onde informações diversas estão organizadas para se “compilar” o produto disso no corpo do bebê. Por exemplo: material genético dos pais, remédios tomados pela mãe durante a gestação, estrutura do DNA da criança etc.

No caso da banana, vai na mesma linha.

Antes de se ter a banana houve um trabalho de se “projetar” a bananeira, onde podemos considerar: qualidade das sementes, qualidade e trato do solo, volume de chuvas no local, combate a pragas, fase da lua na data da semeadura etc.

Quando falamos de software, pensamos que apenas o software executável é origem dos bugs, pois é a parte mais material para nós, é a mais perceptível.

Mas antes do software executável, que obviamente é produzido a partir de um modelo de código fonte, várias outros modelos são produzidos para se chegar até esse momento.

Bugs de software que não estão no software?

Reflita rapidamente sobre as perguntas abaixo:

  • Se o software funciona mas está muito lento, é bug?
  • Se o software faz bem tudo que foi construído, mas não faz tudo que estava no escopo, é bug?
  • Se o software faz mais coisas do que deveria fazer, é bug?
  • Se o software não faz tudo que está no escopo, é bug?
  • Se o software não faz corretamente o que está no escopo, é bug?
  • Se o software é difícil de usar, confunde o usuário, não possui help etc. é bug?

Precisamos rever nossa visão a respeito de bugs de software…

Bugs vão muito além das exceptions

bugs de software tela azul do windows

Isso que vemos acima é, sem dúvida, um bug. Um dos mais famosos, talvez. E é uma exception de software, no software que talvez seja o mais famoso do mundo: o sistema operacional Windows, principalmente em suas versões mais antigas.

Mas bugs vão muito além das Exceptions.

Muito do conteúdo deste post são pontos que podem ser estudados no livro Software Testing, de Ron Patton. Eu acho este livro espetacular e recomendo não apenas para os profissionais de Qualidade de Software, mas para qualquer Analista de Sistemas ou Gerente de Projetos que trabalhem com produção de software.

Segundo este livro, bugs de software podem ser (a grosso modo) classificados, ou ter causa atribuída, a:

  • Performance proibitiva na execução do software.
  • Recursos não previstos implementados no software.
  • Recursos implementados no software mas ausentes no escopo.
  • Processamento incorreto – diferente do que estava no escopo.
  • Dificuldades proibitivas em termos de usabilidade.

E a maioria das causas citadas acima não estão apenas na codificação (ou programação), que produz diretamente o software executável, mas refletem-se nesta entrega, obviamente.

As causas estão, na maioria dos casos, nos modelos produzidos que servem de entrada para a produção do modelo de código fonte, que quando compilado, geram o software executável (onde as exceptions explodem).

A maior parte do problema nasce no início – nas Especificações

bugs de software - A maioria dos bugs nasce nos RequisitosO gráfico nos mostra onde nascem os bugs de um software, em quais áreas (ou disciplinas) da produção de software eles são gerados.

Segundo Ron Patton (o gráfico está no livro que citei) a maior parte dos bugs são gerados na Especificação, ou seja, no início de tudo, na Concepção do software.

Isso pode soar estranho para alguns, pois como já citamos, associamos defeito a algo já produzido, já materializado.

Mas como também citamos, um software não se materializa do nada, ele precisa ser modelado antes, ser projetado, ser “pensando”.

Causas comuns do nascimento dos bugs em função de problemas de Especificação

Como podemos ver no gráfico anterior, não é apenas nos Requisitos que está a causa dos bugs.

Temos uma grande parcela associada a problemas de design, uma parcela menor em problemas de construção (aqui entra o código fonte), e uma parcela menor atribuída a “outros fatores”.

Mas vou me ater aos bugs gerados nos requisitos, na concepção do software, pois eu defendo que o que começa errado fatalmente vai terminar errado. Além de ser a disciplina mais importante dos projetos de software, e que muitas vezes é jogada para segundo plano, por uma cultura de que “software bom é software rodando”.

Quando o assunto é especificação de requisitos, as principais causas que geram os bugs são:

  • Não houve Especificação de Requisitos.
  • Houve Especificação de Requisitos mas foi especificado incorretamente (geralmente sem o nível de detalhe e clareza suficientes).
  • Mudanças de escopo que não foram refletidas na Especificação de Requisitos.
  • Houve Especificação de Requisitos mas não houve comunicação adequada com o time de projeto e desenvolvimento.

Isso é um tanto óbvio, não?

O Analista de Sistemas precisa entender que fazer software é um processo de engenharia e que demanda, no caso de produção de software, de refinamento contínuo, onde o refinamento vai sendo feito conforme o nível de abstração de cada disciplina.

Produzir software não é apenas programar software!

A primeira vez que vi equipes de Testes e QA (QA – Quality Assurance) trabalhando, abrindo defeitos (registrando bugs para posterior correção) para processamentos lentos demais, telas difíceis de usar, regras de negócio difíceis de entender, diagramas de classes com alto acoplamento etc. eu pensei: esse povo é doido?

Depois vi que eles estavam certos e eu estava equivocado. Tive que rever os meus conceitos…

Conclusão

Devemos realmente entender o problema do cliente, pensar a solução em todos os detalhes, e então iniciar a tradução disso para software.

E software, como qualquer produto, antes precisa ser idealizado, analisado, concebido, para então ser materializado.

E sem o devido cuidado na definição do modelo inicial do sistema, que é o modelo conceitual, por questões de causa e efeito, todo o trabalho produzido nos modelos posteriores estará com sua qualidade fatalmente comprometida, gerando bugs e mais bugs.

Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! :)

Aceita uma dica?

Seja você um Desenvolvedor, um Analista de Negócios, Analista de Testes ou Gerente de Projetos, entender melhor sobre a Concepção do software fará toda a diferença na sua performance profissional.

Se você quiser dar um salto no seu curriculum quando o assunto é Concepção de Software, conheça nosso curso sobre Engenharia de Requisitos, onde abordamos o tema Engenharia de Requisitos de uma forma pragmática, voltada ao mercado, sem deixar de lado os fundamentos mais relevantes da teoria.

bugs de software - Curso de Engenharia de Requisitos

Grande abraço!

  • Excelente artigo! Achei ótima a lista de principais causas de bugs relacionados à engenharia de requisitos. Realmente, a maior parte das empresas infelizmente negligencia esta disciplina. Consideram documentação e especificação uma perda de tempo, deve-se apenas “ir no cliente e ver o que ele quer”, por isso a péssima qualidade de grande parte dos softwares produzidos.

    • Plínio Ventura

      Oi Armando! Obrigado!

      Exato, é uma pena as maioria das empresas negligenciar isso. Por isso, dentro das possibilidades, precisamos fazer diferente. E é possível melhorar, até mesmo as empresas mais capitalistas percebem uma hora que tem que pensar software como engenharia, com qualidade.

      Abraço!

  • Diego Giglio

    Olá, Plínio. Novamente, um grande artigo.
    Caiu-me como uma luva para discussões sobre o tempo investido em engenharia de software. Algumas empresas insistem em ver essa etapa como “demasiadamente demorada” ou tentam desesperadamente estabelecer um prazo para sua conclusão, o que de certa forma é conveniente para os tomadores de decisão que, como explica o artigo, acabam atribuindo a responsabilidade pela baixa qualidade (ainda que indiretamente) aos desenvolvedores ou analistas.

    Abraço e obrigado pela dica de leitura.

    • Plínio Ventura

      Oi Diego. Eu quem agradeço sua leitura! :)

      Pois é, essa realidade precisa ser mudada. É claro que a Engenharia de Requisitos não deve ser um processo sem fim, mas como demanda criação, reflexão, síntese etc., e é o momento de entender o “core” da solução, não dá para conduzi-lo como se fosse uma pastelaria, onde basta ter gordura fervendo, joga-se o pastel e em 2 minutos está pronto para comer.

      Investir, com bom senso e foco prático, na Engenharia de Requisitos com excelência, gera benefícios gigantes no futuro dos sistemas, mas muitos tomadores de decisão são imediatistas, não entendem (ou não querem entender às vezes) que é melhor investir no início com o cuidado necessário, do que produzir um software “todo bugado”, e diminuir suas margens e esgotar suas equipes.

      Não há milagre, é engenharia aplicada, e se os pedreiros tentarem levantar um prédio sem uma arquitetura bem feita antes, o prédio vai cair…

      Mas aos poucos as coisas vão mudando, façamos nossa parte e tenhamos paciência! :)

      Abraço!

  • Roberto Slomka

    Muito bom o artigo. É preciso chamar a atenção para o fato de que construir software não é o mesmo que “cuspir código”. Por paradoxal que pareça a tecnologia (ferramentas e linguagens) é o fator MENOS influente para a qualidade de software. Se assim não o fosse, bastaria a melhor ferramenta para ter a melhor empresa de software. É importantíssimo valorizar o elemento humano e suas habilidades – principalmente as relacionadas à comunicação – para obter o máximo em qualidade.
    Só uma ressalva: bananeiras não nascem de sementes…

    • Plínio Ventura

      Oi Roberto, obrigado pela leitura!

      Sua observação é muito pertinente. Muito relevante o que disse, pois sem dúvida alguma, tecnologia é o menor problema quando o assunto é produção de software. E o fator humano, neste contexto tantas vezes menosprezado, é a variável de maior influência na qualidade do produto final.

      Mas ainda vivemos num mundo onde a Lei do Menor Esforço faz parte do status quo. Infelizmente é necessário que erremos muito para um dia, quando a dor foi muito forte, reflitamos sobre outros caminhos.

      Sobre a bananeira, realmente não sabia, rs. Sou muito ignorante em assuntos agrônomos, por exemplo.

      Abraço!