Proposta de alteração nas histórias de Bugs

Por que é impossível resolver todos os bugs?

Resolver todos os bugs de um pequeno sistema pode até ser possível, mas de inúmeros sistemas complexos que cada vez crescem mais em quantidade e complexidade, com vários programadores trabalhando é impossível! Várias podem ser as causas de bugs no sistema, mas sem um histórico de categorização de bugs ocorridos não é possível descobrir a causa raiz e mitigar.

As causas de bugs em sistemas podem ser várias como:

Complexidade do software: Sistemas de software geralmente são extremamente complexos, especialmente se forem grandes e possuírem muitos recursos. Mesmo um pequeno programa pode conter milhares ou até milhões de linhas de código. A complexidade torna difícil identificar e corrigir todos os bugs presentes.

Diversidade de ambientes: Os sistemas de software podem ser executados em uma variedade de ambientes, como diferentes sistemas operacionais, versões de bibliotecas, configurações de hardware e redes. Essas variações podem levar a comportamentos diferentes e a bugs específicos de cada ambiente. É quase impossível testar e corrigir todos os bugs em todas as combinações possíveis de ambientes.

Interações imprevisíveis: O comportamento de um sistema de software pode ser influenciado por uma infinidade de fatores externos, como entradas de usuário, interações com outros sistemas, tráfego de rede e muito mais. É difícil prever todas as possíveis interações e, portanto, é provável que alguns bugs só sejam descobertos em situações específicas de uso.

Restrições de tempo e recursos: A maioria dos projetos de software tem prazos e restrições de recursos. Isso significa que os desenvolvedores precisam priorizar quais bugs corrigir e quais podem ser deixados de lado. Em alguns casos, bugs menores ou que afetam um número muito pequeno de usuários podem não ser considerados críticos o suficiente para receberem atenção imediata.

Introdução de novos bugs: Ao corrigir um bug, é possível introduzir inadvertidamente novos bugs ou efeitos colaterais indesejados. A complexidade do software e as interações entre diferentes partes tornam difícil garantir que uma correção não afetará outras áreas do sistema.

Sabendo que é impossível acabar com os bugs na SETIC, como posso mitigá-los?

Embora seja impossível eliminar todos os bugs de um sistema, existem medidas que podem ser tomadas para mitigar sua ocorrência e minimizar seu impacto.

Como reduzir os bugs antes da entrega?

Testes rigorosos: Realizar testes abrangentes e rigorosos é fundamental para identificar e corrigir bugs antes que eles cheguem aos usuários finais. Isso inclui testes de unidade, testes de integração, testes de sistema e testes de aceitação. Automatizar os testes sempre que possível também ajuda a garantir uma cobertura mais ampla.

Revisões de código: Implementar um processo de revisão de código, onde outros membros da equipe analisam e verificam o código escrito, pode ajudar a identificar possíveis problemas, bugs e melhorar a qualidade geral do código. Este é um problema crônico na SETIC, onde sempre é visto programadores sêniores deixando a desejar ou nem mesmo fazendo revisão de código nos sistemas, deixando passar para o cliente final problemas que em muitas das vezes são simples de serem vistos em uma revisão de código.

Adotar práticas de desenvolvimento seguro: A segurança é uma parte essencial da qualidade do software. Adotar práticas de desenvolvimento seguro, como validação de entrada, controle de acesso adequado e tratamento correto de erros, pode ajudar a reduzir a ocorrência de bugs relacionados à segurança.

Papel de QA na SETIC: 

O QA (Garantia de Qualidade) desempenha um papel crucial na mitigação de bugs em um sistema. Aqui estão algumas razões pelas quais o QA é importante nesse processo:

Identificação precoce de bugs: Os profissionais de QA são responsáveis por testar minuciosamente o sistema em busca de bugs. Eles executam testes de funcionalidade, testes de integração, testes de desempenho, testes de segurança e muitos outros para identificar problemas antes que o sistema seja lançado para os usuários. Ao detectar bugs precocemente, é possível corrigi-los antes que causem impacto significativo.

Melhoria da qualidade do software: O QA ajuda a garantir que o software atenda aos requisitos de qualidade estabelecidos. Eles garantem que o sistema funcione corretamente, atenda aos critérios de desempenho esperados, seja seguro e proporcione uma experiência de usuário satisfatória. Isso contribui para a melhoria contínua da qualidade do software e redução dos bugs.

Testes abrangentes: Os profissionais de QA realizam testes em diferentes cenários e condições para garantir que o sistema seja robusto e estável. Eles simulam diversas situações que podem ocorrer no mundo real, identificando assim bugs que podem surgir em circunstâncias específicas. Essa abordagem abrangente ajuda a identificar e mitigar uma ampla gama de bugs.

Feedback valioso para desenvolvedores: O trabalho do QA envolve fornecer feedback detalhado aos desenvolvedores sobre os bugs encontrados e suas causas. Esse feedback é essencial para que a equipe de desenvolvimento entenda os problemas e possa corrigi-los de forma adequada. A colaboração próxima entre QA e desenvolvedores facilita a comunicação e o processo de resolução de bugs.

Prevenção de regressões: Além de identificar bugs, o QA desempenha um papel fundamental na prevenção de regressões. Ao conduzir testes de regressão, eles verificam se as correções de bugs ou novas implementações introduziram problemas adicionais no sistema. Isso ajuda a evitar que bugs anteriormente resolvidos reapareçam, garantindo a estabilidade do software.

Como reduzir os bugs depois da entrega?

Monitoramento contínuo: Implementar sistemas de monitoramento contínuo ajuda a identificar bugs em produção. Isso pode incluir o monitoramento de logs, métricas de desempenho, erros e exceções do sistema. Essas informações podem ser usadas para identificar e resolver problemas rapidamente. Aqui temos outro problema de hábito dos desenvolvedores e da gestão da SETIC, onde todos tem acessos a atual ferramenta de APM utilizada, vendo todos os bugs antes do reporte do usuário mas ignorando-os. O outro problema é que nossa ferramenta de APM é limitada, não dando informações suficientes ou alertas inteligentes de problemas, porém atendendo dois dos três pilares da observabilidade contínua que é a observabilidade e rastreamento.

Coleta e análise de feedback dos usuários: Incentivar os usuários a relatarem bugs e fornecer um canal para enviar feedback é uma forma valiosa de identificar problemas que podem não ter sido detectados durante os testes internos. A análise desse feedback pode ajudar a priorizar os bugs mais comuns e críticos. Atualmente com o uso do GLPI pela CODE, é possível ter um reporte mais fácil dos usuários quanto aos bugs nos sistemas e gerar dados quantitativos de bugs reportados.

Gerenciamento efetivo de bugs:

Aqui está uma das chaves para a redução exponencial dos bugs nos sistemas. Atualmente temos apenas a prática de dizer que algum comportamento não esperado é um bug mas isso é um grande problema. Catalogar e classificar os bugs de forma adequada é essencial para entender sua causa raiz e abordar os problemas de maneira mais eficaz.

O que podemos fazer para realizar essa catalogação e classificação?

Identificação clara do bug: Ao relatar um bug, é importante fornecer informações detalhadas sobre o problema. Isso inclui uma descrição clara do bug, passos para reproduzir o erro, entradas específicas que causaram o problema, mensagens de erro, capturas de tela e qualquer outra informação relevante. Sabemos que atualmente os clientes reportam o mínimo possível do bug causado, tomando bastante tempo para o realizador da triagem identificar se realmente é um bug e ao próprio desenvolvedor que não sabe ao menos qual o cenário que o usuário estava ao acontecer o bug, mas esse é o menor dos problemas.

Priorização de bugs: Não é estabelecido atualmente os critérios claros para priorizar os bugs. É necessário considerar fatores como impacto do bug no sistema, frequência de ocorrência, número de usuários afetados e consequências para o negócio. Isso ajudará a determinar quais bugs devem ser abordados primeiro.

Classificação de gravidade: É necessário classificar os bugs de acordo com sua gravidade. Por exemplo, pode-se usar categorias como "Bloqueador", "Crítico", "Médio" e "Baixo". Essa classificação permite identificar problemas urgentes e focar naqueles que têm maior impacto no sistema.

Categorização por tipo de bug: É necessário também classificar os bugs em categorias específicas para ajudar a identificar padrões e tendências.

Alguns exemplos de categorias podem ser:

Erros de lógica: Bugs que envolvem problemas na implementação da lógica do código, resultando em comportamento inesperado ou incorreto.

Erros de interface do usuário: Bugs relacionados à interação do usuário com a interface do sistema, como botões que não funcionam corretamente, campos de entrada que não aceitam dados corretamente ou problemas de layout.

Erros de desempenho: Bugs que afetam o desempenho do sistema, resultando em lentidão, alto consumo de recursos ou tempo de resposta excessivamente longo.

Erros de segurança: Bugs que comprometem a segurança do sistema, como vulnerabilidades de injeção de código, falta de autenticação adequada ou autorização incorreta.

Erros de integração: Bugs que ocorrem quando diferentes componentes ou sistemas não se comunicam corretamente entre si, resultando em falhas de integração ou perda de dados.

Erros de compatibilidade: Bugs que ocorrem quando o sistema não é compatível com certas configurações de hardware, sistemas operacionais ou versões de software, levando a problemas de execução ou funcionalidade limitada.

Erros de armazenamento de dados: Bugs que envolvem problemas na manipulação, gravação ou recuperação de dados, resultando em corrupção ou perda de informações.

Erros de usabilidade: Bugs que afetam a experiência do usuário, tornando o sistema difícil de entender, confuso ou pouco intuitivo.

E nem tudo é relacionado a software, é importante também categorizar erros de Rede, Infraestrutura, Banco de Dados e outros fatores que não cabem a resolução da CODE, afinal foi necessário o esforço do desenvolvedor pra descobrir a causa e deixa registrado que nem todos os bugs são relacionados ao desenvolvimento do sistema.

Essa categorização é o item mais importante na mitigação dos bugs na SETIC. Classificar os bugs de forma adequada pode ajudar a identificar áreas problemáticas em um sistema e determinar quais tipos de bugs estão ocorrendo com mais frequência. Ao analisar as categorias e a frequência dos bugs, é possível obter insights valiosos sobre as áreas que mais causam problemas em um sistema. Isso pode ajudar na identificação da causa raiz dos problemas e direcionar esforços de melhoria e correção.

Ao observar quais categorias de bugs estão ocorrendo com mais frequência, é possível identificar tendências e padrões. Por exemplo, se os bugs relacionados a erros de lógica forem mais comuns, isso pode indicar a necessidade de uma revisão mais cuidadosa do código ou testes mais abrangentes nas regras de negócio.

Da mesma forma, se os erros de desempenho forem predominantes, pode ser necessário otimizar o código ou melhorar a arquitetura do sistema para lidar com cargas maiores. Se os erros de segurança estiverem em destaque, isso pode indicar a necessidade de uma auditoria de segurança e implementação de medidas adicionais de proteção.

A análise dos tipos e frequência dos bugs também pode ajudar a estabelecer prioridades na resolução de problemas. Se certas categorias de bugs têm um impacto significativo no funcionamento do sistema ou afetam um grande número de usuários, elas devem ser tratadas com alta prioridade.

É importante também que toda resolução de um bug seja descrita detalhadamente pelo resolvedor do problema, para gerar uma base de conhecimento geral que pode ser consultada e utilizada futuramente por outros motivos.

Nem tudo são bugs🌹🪲

Algo corriqueiro na SETIC é a entrada de bugs que não são bugs, mas como algo assim pode ocorrer? Existem algumas formas disso ocorrer e todas são relacionadas a como a demanda chega ao desenvolvedor, como por exemplo, a falta de mapeamento de fluxo ou a não descrição correta de uma história pode gerar um cenário não previsto pelo desenvolvedor, onde comportamentos inesperados podem acontecer, mas não devem ser considerados bugs. A mitigação disso é feita através do mapeamento de fluxo correta do sistema, histórias bem escritas com cenários detalhados e validações necessárias e um filtro antes do chamado ser passado ao desenvolvedor, buscando prever se o chamado não se encaixa como bug.