O que é Bug?
Um bug é a consequência / resultado de uma falha de codificação.
Defeito no teste de software
Um Defeito no Teste de Software é uma variação ou desvio do aplicativo de software dos requisitos do usuário final ou requisitos comerciais originais. Um defeito de software é um erro de codificação que causa resultados incorretos ou inesperados de um programa de software que não atende aos requisitos reais. Os testadores podem encontrar tais defeitos durante a execução dos casos de teste.
Esses dois termos têm uma linha muito tênue de diferença. Na indústria, ambos são falhas que precisam ser consertadas e, portanto, usados de forma intercambiável por algumas das equipes de teste.
Quando os testadores executam os casos de teste, eles podem encontrar tais resultados de teste que são contraditórios aos resultados esperados. Essa variação nos resultados do teste é chamada de Defeito de Software. Esses defeitos ou variações são referidos por diferentes nomes em diferentes organizações, como questões, problemas, bugs ou incidentes.
Neste tutorial, você aprenderá-
- Relatório de erro
- Processo de gestão de defeitos
- Descoberta
- Categorização
- Resolução
- Verificação
- Fecho
- Comunicando
- Métricas de defeito importantes
Relatório de bug em teste de software
Um relatório de bug em teste de software é um documento detalhado sobre bugs encontrados no aplicativo de software. O relatório de bug contém cada detalhe sobre bugs como descrição, data em que o bug foi encontrado, nome do testador que o encontrou, nome do desenvolvedor que o corrigiu, etc. O relatório de bug ajuda a identificar bugs semelhantes no futuro para que possa ser evitado.
Ao relatar o bug para o desenvolvedor, seu relatório de bug deve conter as seguintes informações
- Defect_ID - Número de identificação exclusivo do defeito.
- Descrição do Defeito - descrição detalhada do Defeito, incluindo informações sobre o módulo no qual o Defeito foi encontrado.
- Versão - Versão do aplicativo em que o defeito foi encontrado.
- Etapas - etapas detalhadas junto com capturas de tela com as quais o desenvolvedor pode reproduzir os defeitos.
- Data de aumento - Data em que o defeito é levantado
- Referência - onde em você Fornece referência aos documentos como. requisitos, design, arquitetura ou talvez até capturas de tela do erro para ajudar a entender o defeito
- Detectado por - Nome / ID do testador que levantou o defeito
- Status - Status do defeito, mais sobre isso mais tarde
- Corrigido por - Nome / ID do desenvolvedor que o corrigiu
- Data de Fechamento - Data em que o defeito é fechado
- Gravidade que descreve o impacto do defeito no aplicativo
- Prioridade que está relacionada à urgência na correção de defeitos. A prioridade de gravidade pode ser Alta / Média / Baixa com base na urgência do impacto em que o defeito deve ser corrigido, respectivamente
Clique aqui se o vídeo não estiver acessível
Recursos
Baixe um modelo de relatório de defeitos de amostra
Considere o seguinte como um gerente de teste
Sua equipe encontrou bugs ao testar o projeto Guru99 Banking.
Depois de uma semana, o desenvolvedor responde -
Na próxima semana, o testador responde
Como no caso acima, se a comunicação do defeito for feita verbalmente, logo as coisas ficam muito complicadas. Para controlar e gerenciar os bugs com eficácia, você precisa de um ciclo de vida do defeito.
O que é o processo de gerenciamento de defeitos?
O gerenciamento de defeitos é um processo sistemático para identificar e corrigir bugs. Um ciclo de gerenciamento de defeitos contém os seguintes estágios 1) Descoberta do defeito, 2) Categorização do defeito 3) Correção do defeito pelos desenvolvedores 4) Verificação pelos testadores, 5) Fechamento do defeito 6) Relatórios de defeito no final do projeto
Este tópico irá guiá-lo sobre como aplicar o processo de gerenciamento de defeitos ao site do projeto Guru99 Bank. Você pode seguir as etapas abaixo para gerenciar defeitos.
Descoberta
Na fase de descoberta, as equipes de projeto precisam descobrir o máximo de defeitos possível, antes que o cliente final possa descobri-los. Diz-se que um defeito é descoberto e muda para o status de aceito quando é reconhecido e aceito pelos desenvolvedores
No cenário acima, os testadores descobriram 84 defeitos no site Guru99.
Vamos dar uma olhada no seguinte cenário; sua equipe de teste descobriu alguns problemas no site do Guru99 Bank. Eles os consideram como defeitos e são relatados à equipe de desenvolvimento, mas há um conflito -
Nesse caso, como Gerente de Teste, o que você fará?
A) Concordar com a equipe de teste que é um defeito
B) O gerente de teste assume o papel de juiz para decidir se o problema é defeito ou não
C) Concordar com a equipe de desenvolvimento que não é um defeito Correto InCorrect
Nesse caso, um processo de resolução deve ser aplicado para resolver o conflito, você assume o papel de juiz para decidir se o problema do site é um defeito ou não.
Categorização
A categorização de defeitos ajuda os desenvolvedores de software a priorizar suas tarefas. Isso significa que esse tipo de prioridade ajuda os desenvolvedores a consertar primeiro os defeitos que são altamente cruciais.
Os defeitos são geralmente categorizados pelo Test Manager -
Vamos fazer um pequeno exercício conforme arrastar e soltar a prioridade de defeito abaixo
- Crítico
- Alto
- Médio
- Baixo
| 1) O desempenho do site está muito lento |
|
| 2) A função de login do site não funciona corretamente |
|
| 3) A GUI do site não é exibida corretamente em dispositivos móveis |
|
| 4) O site não conseguiu lembrar a sessão de login do usuário |
|
| 5) Alguns links não funcionam |
|
Aqui estão as respostas recomendadas
| Não. | Descrição | Prioridade | Explicação |
|---|---|---|---|
| 1 | O desempenho do site está muito lento | Alto | O bug de desempenho pode causar grandes transtornos ao usuário. |
| 2 | A função de login do site não funciona corretamente | Crítico | O login é uma das funções principais do site do banco, se esse recurso não funcionar, é um bug grave |
| 3 | A GUI do site não é exibida corretamente em dispositivos móveis | Médio | O defeito afeta o usuário que usa o Smartphone para visualizar o site. |
| 4 | O site não lembra da sessão de login do usuário | Alto | Este é um problema sério, pois o usuário será capaz de fazer o login, mas não poderá realizar nenhuma outra transação |
| 5 | Alguns links não funcionam | Baixo | Esta é uma solução fácil para o pessoal de desenvolvimento e o usuário ainda pode acessar o site sem esses links |
Resolução de defeitos
A resolução de defeitos em testes de software é um processo passo a passo de correção dos defeitos. O processo de resolução de defeitos começa com a atribuição de defeitos aos desenvolvedores, em seguida, os desenvolvedores planejam a correção do defeito de acordo com a prioridade, os defeitos são corrigidos e, finalmente, os desenvolvedores enviam um relatório de resolução ao gerente de teste. Este processo ajuda a corrigir e rastrear defeitos facilmente.
Você pode seguir as etapas a seguir para corrigir o defeito.
- Atribuição : Atribuída a um desenvolvedor ou outro técnico para consertar e alterar o status para Respondendo .
- Fixação do cronograma : o lado do desenvolvedor assume o controle nesta fase. Eles criarão um cronograma para corrigir esses defeitos, dependendo da prioridade do defeito.
- Corrija o defeito : Enquanto a equipe de desenvolvimento está corrigindo os defeitos, o Test Manager acompanha o processo de correção de defeitos em comparação com o cronograma acima.
- Relatar a resolução : Obtenha um relatório da resolução dos desenvolvedores quando os defeitos forem corrigidos.
Verificação
Depois que a equipe de desenvolvimento corrigiu e relatou o defeito, a equipe de teste verifica se os defeitos foram realmente resolvidos.
Por exemplo, no cenário acima, quando a equipe de desenvolvimento relatou que já corrigiu 61 defeitos, sua equipe testaria novamente para verificar se esses defeitos foram realmente corrigidos ou não.
Fecho
Depois que um defeito foi resolvido e verificado, o status do defeito é alterado como fechado . Caso contrário, você enviou um aviso ao empreendimento para verificar o defeito novamente.
Relatório de Defeito
Relatório de defeitos em testes de software é um processo no qual os gerentes de teste preparam e enviam o relatório de defeitos à equipe de gerenciamento para feedback sobre o processo de gerenciamento de defeitos e o status dos defeitos. Em seguida, a equipe de gerenciamento verifica o relatório de defeito e envia feedback ou fornece suporte adicional, se necessário. O relatório de defeitos ajuda a comunicar melhor, rastrear e explicar os defeitos em detalhes.
O conselho de administração tem o direito de saber o status do defeito. Eles devem compreender o processo de gerenciamento de defeitos para apoiá-lo neste projeto. Portanto, você deve relatar a eles a situação de defeito atual para obter feedback deles.
Métricas de defeito importantes
Volte ao cenário acima. O desenvolvedor e as equipes de teste revisam os defeitos relatados. Aqui está o resultado dessa discussão
Como medir e avaliar a qualidade da execução do teste?
Esta é uma pergunta que todo Test Manager (TM) deseja saber. Existem 2 parâmetros que você pode considerar como os seguintes
No cenário acima, você pode calcular a taxa de rejeição de deserção (DRR) é 20/84 = 0,238 (23,8%).
Outro exemplo, supõe-se que o site do banco Guru99 tem um total de 64 defeitos, mas sua equipe de teste detectou apenas 44 defeitos, ou seja, eles perderam 20 defeitos. Portanto, você pode calcular a taxa de vazamento de defeito (DLR) é 20/64 = 0,312 (31,2%).
Conclusão, a qualidade da execução do teste é avaliada seguindo dois parâmetros
Quanto menor for o valor de DRR e DLR, melhor será a qualidade da execução do teste. Qual é a faixa de razão aceitável ? Este intervalo pode ser definido e aceito com base na meta do projeto ou você pode consultar as métricas de projetos semelhantes.
Neste projeto, o valor recomendado de razão aceitável é 5 ~ 10%. Isso significa que a qualidade da execução do teste é baixa. Você deve encontrar contramedidas para reduzir essas proporções, como
- Melhore as habilidades de teste do membro.
- Gaste mais tempo para a execução do teste, especialmente para revisar os resultados da execução do teste.