Qual é 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?
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
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
O 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! 🙂
Grande abraço!