Integração entre Big Data e Internet das Coisas vira tendência
21 de dezembro de 2020PostgreSQL – O Banco do Ano
13 de janeiro de 2021Quanto mais tempo um bug permanece em um programa, a probabilidade de ter código adicional escrito em torno dele é maior. Isso exigiria mais testes, o que geraria um custo adicional para corrigir. A detecção precoce de bugs é necessária para minimizar o custo da correção de bugs.
Estratégias ágeis para lidar com bugs
A abordagem ágil de gerenciamento de projetos ajuda não apenas na detecção precoce de bugs, mas também em uma versão de maior qualidade por meio da colaboração. A colaboração efetiva é importante para priorizar bugs a serem corrigidos.
A principal ênfase em projetos ágeis é a satisfação do cliente. Em comparação com os projetos tradicionais de desenvolvimento de software em cascata; o escopo dos projetos ágeis é flexível. As equipes de desenvolvimento de software estão cientes de que os requisitos irão evoluir ao longo do projeto. Há uma necessidade de envolvimento contínuo do cliente em projetos ágeis. Em projetos ágeis, os bugs são tratados com base no impacto que eles têm no aplicativo em desenvolvimento.
Existem duas estratégias para lidar com bugs em projetos ágeis:
Estratégia 1
Nessa estratégia, assim que um bug é encontrado, a criticidade do bug é determinada. A criticidade do bug depende do impacto do bug na funcionalidade do aplicativo. Então, os bugs são geralmente classificados com os seguintes níveis de criticidade:
Criticidade: Alta
Um bug que impede o cumprimento de uma função essencial.
Criticidade: Média
Um bug que afeta negativamente a realização de uma função essencial e não há soluções alternativas disponíveis.
Criticidade: Baixa
Um bug que causa transtorno ao usuário.
Criticidade: Trivial
Todos os outros erros.
Esses níveis de criticidade não são padronizados, pois o impacto dos bugs varia de acordo com a indústria. Ao decidir a prioridade de correção de bugs, a probabilidade de ocorrência também é levada em consideração. Um bug com alta criticidade que ocorre muito raramente é de baixa prioridade para correção. Esta é uma abordagem de teste de software baseada em risco, em que a probabilidade de ocorrência de um bug e o impacto do bug quando ele ocorre são considerados. Os bugs com alta probabilidade e alto impacto são programados primeiro para correção (elabore uma matriz de risco).
À medida que os bugs são detectados, para lidar com eles de forma eficaz, são organizadas reuniões “Três Amigos”. Essas reuniões envolvem um product owner ou analista de negócios, um desenvolvedor e um testador de QA para revisar todos os bugs. A ideia por trás dessas reuniões é obter três pontos de vista diferentes ao definir a prioridade dos bugs para correção. Esses três pontos de vista são:
Negócios – Quais são os problemas que estamos tentando resolver?
Desenvolvimento – Como podemos resolver esses problemas?
Testador– O que poderia acontecer ao resolvermos esses problemas?
O product owner é o representante da empresa e explica o risco de bugs para a empresa. O programador destaca os detalhes de implementação das iniciativas de correção de bugs. O testador, por outro lado, apresenta opiniões sobre o que pode dar errado. A reunião “Três Amigos” não está limitada a três pessoas, mas pode incluir outros membros também.
Estratégia 2
Existe uma escola de pensamento que diz que qualquer erro encontrado na fase de desenvolvimento não é um bug, pois o software ainda está em desenvolvimento. A segunda estratégia para projetos ágeis enfatiza a abordagem de prevenção é melhor do que remediar. Os bugs encontrados na fase de produção são resultados de um processo de desenvolvimento, teste ou entrega ineficiente.
O Desenvolvimento Contínuo (CD) é uma abordagem de desenvolvimento de software que otimiza o processo de entrega para enviar software de alta qualidade aos clientes o mais rápido possível. No CD, você pode obter feedback antecipado lançando um protótipo ou Produto Mínimo Viável (MVP). Você pode obter feedback sobre o MVP rastreando os padrões de uso.
Você pode então medir a cada liberação os comportamentos dos usuários em termos do que você deseja alcançar. O produto MVP básico com recursos mínimos necessários para resolver um problema de negócios específico reduzirá qualquer esforço de desenvolvimento desperdiçado que pode levar a mais bugs.
Com o Desenvolvimento Contínuo (CD), a equipe de desenvolvimento deve realizar a Integração Contínua, que é um processo para verificar o código em um repositório compartilhado várias vezes ao dia. Uma compilação automatizada para detectar erros o mais rápido possível verifica cada check-in. O teste é realizado continuamente como testes de unidade, testes de componentes e uma variedade de testes de aceitação e integração são executados em cada check-in.
Existem diferentes estratégias de implantação em CD para atingir o tempo de inatividade zero em projetos ágeis. As duas estratégias de implantação importantes são:
Liberação de canário
Nessa estratégia, a próxima versão de seu software lançado em produção é exposta a apenas uma pequena porcentagem de sua base de usuários. Conforme a versão passa nos testes de ambiente, ela é disponibilizada para um grande número de usuários.
Implantação azul-verde
Nesta estratégia, um clone idêntico de sua pilha de aplicativos de produção é necessário. A versão mais recente do seu aplicativo é configurada no clone. Em seguida, o tráfego é comutado da pilha de produção atual para a nova após o teste. Essa abordagem é adequada para recursos de nuvem e infraestrutura virtual.
A partir das estratégias acima, podemos deduzir que, para reduzir o custo da correção de bugs, você precisa de um nível mais alto de colaboração. Para melhorar o processo de documentação de bugs e colaborar em iniciativas de correção de bugs, você precisa da ferramenta certa.
Encontre e corrija bugs no início
Você pode relatar os bugs quando os encontrar. Atribua os bugs a desenvolvedores individuais para corrigi-los. Você deve garantir que nenhum bug chegue à fase de produção e, assim, minimizar o custo dos bugs.
Visão de nível de projeto de bugs
Um gráfico de burndown fornece uma visão dos bugs no nível do projeto. Você pode saber facilmente o número total de bugs no projeto. Dessa forma, você pode acompanhar quando sua contagem de bugs aumenta.
Relate bugs com a ajuda de imagens / vídeos
É interessante utilizar um aplicativo para capturar bugs com vídeo ou imagens e carregá-los como anexos. Você pode documentar bugs de forma fácil e rápida, sem a necessidade de qualquer explicação. Como resultado, tanto os testadores quanto os desenvolvedores podem economizar muito do tempo necessário para explicação detalhada do problema.
Para minimizar o custo dos bugs, você precisa localizá-los e corrigi-los no início do ciclo de desenvolvimento de software.
Este texto é uma adaptação livre do artigo publicado em:
https://reqtest.com/testing-blog/how-to-reduce-the-cost-of-bugs/
Clique aqui e veja como nós podemos te ajudar na implantação de processos de Qualidade e Testes de Software.