Menu

O que é ciclo de vida de defeito / bug em teste de software? Tutorial de ciclo de vida de defeitos

what is defect bug life cycle software testing

Introdução ao ciclo de vida de defeitos

Neste tutorial, falarei sobre o ciclo de vida de um defeito para torná-lo ciente dos vários estágios de um defeito com o qual um testador deve lidar ao trabalhar em um ambiente de teste.

Também adicionei as perguntas mais frequentes da entrevista sobre o Ciclo de Vida do Defeito. É importante saber sobre os vários estados de um defeito para compreender o ciclo de vida de um defeito. A principal intenção de realizar uma atividade de teste é verificar se o produto apresenta problemas / erros.

Tutorial de ciclo de vida de defeitos

Em termos de cenários reais, erros / erros / falhas são todos referidos como bugs / defeitos e, portanto, podemos dizer que o objetivo principal de fazer o teste é garantir que o produto seja menos sujeito a defeitos (nenhum defeito é uma situação irrealista )

Agora, surge a pergunta sobre o que é um defeito?

O que você aprenderá:

O que é um defeito?

Um Defeito, em termos simples, é uma falha ou erro em um aplicativo que está restringindo o fluxo normal de um aplicativo ao não combinar o comportamento esperado de um aplicativo com o real.

O defeito ocorre quando algum erro é cometido por um desenvolvedor durante o projeto ou construção de um aplicativo e quando essa falha é encontrada por um testador, é denominado como um defeito.

É responsabilidade do testador fazer o teste completo de um aplicativo para encontrar o máximo de defeitos possível para garantir que um produto de qualidade chegue ao cliente.

É importante entender sobre o ciclo de vida do defeito antes de passar para o fluxo de trabalho e os diferentes estados do defeito.

Portanto, vamos saber mais sobre o Ciclo de Vida do Defeito.

Até agora, discutimos o significado de defeito e sua relação no contexto com a atividade de teste. Agora, vamos passar para o ciclo de vida do defeito e entender o fluxo de trabalho de um defeito e os diferentes estados de um defeito.

Ciclo de vida do defeito em detalhe

Um ciclo de vida de defeito, também conhecido como ciclo de vida de um bug, é o ciclo de um defeito a partir do qual ele passa pela cobertura de diferentes estados em toda a sua vida. Isso começa assim que qualquer novo defeito é encontrado por um testador e termina quando um testador fecha o defeito garantindo que ele não será reproduzido novamente.

Fluxo de Trabalho de Defeito

Agora é hora de entender o fluxo de trabalho real de um Ciclo de Vida de Defeito com a ajuda de um diagrama simples, conforme mostrado abaixo.

Ciclo de vida do defeito

Estados de Defeito

# 1) Novo :Este é o primeiro estado de um defeito no Ciclo de Vida do Defeito. Quando qualquer novo defeito é encontrado, ele cai em um estado ‘Novo’, e as validações e testes são realizados neste defeito nos estágios posteriores do Ciclo de Vida do Defeito.

# 2) Atribuído: Nesse estágio, um defeito recém-criado é atribuído à equipe de desenvolvimento para trabalhar no defeito. Isso é atribuído pelo líder do projeto ou gerente da equipe de teste a um desenvolvedor.

# 3) Aberto: Aqui, o desenvolvedor inicia o processo de análise do defeito e trabalha para corrigi-lo, se necessário. Se o desenvolvedor achar que o defeito não é apropriado, ele pode ser transferido para qualquer um dos quatro estados abaixo, a saber Duplicar, adiar, rejeitar ou não é um bug -com base no motivo específico.

Discutirei esses quatro estados daqui a pouco.

# 4) Fixo: Quando o desenvolvedor termina a tarefa de consertar um defeito, fazendo as alterações necessárias, ele pode marcar o status do defeito como 'Corrigido'.

algoritmo de classificação simples c ++

# 5) Reteste pendente: Depois de corrigir o defeito, o desenvolvedor atribui o defeito ao testador para retestar o defeito em seu final, e até que o testador trabalhe em retestar o defeito, o estado do defeito permanece em ‘Reteste pendente’.

# 6) Teste novamente: Neste ponto, o testador inicia a tarefa de trabalhar no reteste do defeito para verificar se o defeito foi corrigido com precisão pelo desenvolvedor de acordo com os requisitos ou não.

# 7) Reabrir: Se algum problema persistir no defeito, ele será atribuído ao desenvolvedor novamente para teste e o status do defeito será alterado para 'Reabrir'.

# 8) Verificado: Se o testador não encontrar nenhum problema no defeito depois de ser atribuído ao desenvolvedor para novo teste e ele sentir que se o defeito foi corrigido com precisão, o status do defeito é atribuído a ‘Verificado’.

# 9) Fechado: Quando o defeito não existe mais, o testador altera o status do defeito para 'Fechado'.

Mais alguns:

  • Rejeitado: Se o defeito não for considerado um defeito genuíno pelo desenvolvedor, ele será marcado como ‘Rejeitado’ pelo desenvolvedor.
  • Duplicado: Se o desenvolvedor encontrar o defeito igual a qualquer outro defeito ou se o conceito do defeito corresponder a qualquer outro defeito, o status do defeito é alterado para 'Duplicado' pelo desenvolvedor.
  • Adiado: Se o desenvolvedor achar que o defeito não tem uma prioridade muito importante e ele pode ser corrigido nas próximas versões ou então, em tal caso, ele pode alterar o status do defeito como 'Adiado'.
  • Não é um bug: Se o defeito não afetar a funcionalidade do aplicativo, o status do defeito será alterado para ‘Não é um bug’.

O campos obrigatórios quando um testador registra qualquer novo bug são Build version, Submit On, Product, Module, Severity, Synopsis e Description to Play

Na lista acima, você pode adicionar alguns campos opcionais se você estiver usando um modelo de envio manual de bug. Esses campos opcionais incluem nome do cliente, navegador, sistema operacional, anexos de arquivo ou capturas de tela.

Os seguintes campos permanecem especificados ou em branco:
Se você tem autoridade para adicionar os campos Status do bug, Prioridade e ‘Atribuído a’, você pode especificar esses campos. Caso contrário, o Test Manager irá definir o status, a prioridade do bug e atribuir o bug ao respectivo proprietário do módulo.

Observe o seguinte ciclo de defeito

Ciclo de vida de defeito / bug

A imagem acima é bastante detalhada e quando você considerar as etapas significativas no ciclo de vida do bug, terá uma ideia rápida sobre isso.

Com o registro bem-sucedido, o bug é revisado pelo gerente de Desenvolvimento ou Teste. O gerenciador de teste pode definir o status do bug como Aberto, pode atribuir o bug ao desenvolvedor ou o bug pode ser adiado até a próxima versão.

Quando um bug é atribuído a um desenvolvedor e ele / ela pode começar a trabalhar nele. O desenvolvedor pode definir o status do bug como não corrigido, Não foi possível reproduzir, Precisa de mais informações ou 'Corrigido'.

Se o status do bug definido pelo desenvolvedor for ‘Precisa de mais informações’ ou Corrigido, o QA responde com uma ação específica. Se o bug for corrigido, o QA verifica o bug e pode definir o status do bug como verificado fechado ou Reabrir.

Diretrizes para implementação do ciclo de vida do defeito

Algumas diretrizes importantes podem ser adotadas antes de começar a trabalhar com o Ciclo de Vida do Defeito.

São os seguintes:

  • É muito importante que antes de começar a trabalhar no Ciclo de Vida do Defeito, toda a equipe entenda claramente os diferentes estados de um defeito (discutidos acima).
  • O ciclo de vida do defeito deve ser devidamente documentado para evitar qualquer confusão no futuro.
  • Certifique-se de que cada indivíduo que recebeu qualquer tarefa relacionada ao Ciclo de Vida do Defeito deve entender sua responsabilidade de forma muito clara para obter melhores resultados.
  • Cada indivíduo que está alterando o status de um defeito deve estar devidamente ciente desse status e deve fornecer detalhes suficientes sobre o status e o motivo para colocar esse status, de modo que todos que estão trabalhando naquele defeito específico possam entender o motivo de tal status de um defeito muito facilmente.
  • A ferramenta de rastreamento de defeitos deve ser manuseada com cuidado para manter a consistência entre os defeitos e, portanto, no fluxo de trabalho do Ciclo de Vida do Defeito.

A seguir, vamos discutir as perguntas da entrevista com base no Ciclo de Vida do Defeito.

FAQs importantes ou perguntas da entrevista sobre o ciclo de vida do bug

P # 1) O que é um defeito na perspectiva do Teste de Software?

Responda: Um defeito é qualquer tipo de falha ou erro no aplicativo que está restringindo o fluxo normal de um aplicativo ao não combinar o comportamento esperado de um aplicativo com o real.

P # 2) Qual é a principal diferença entre Erro, Defeito e Falha?

Resposta: Erro: Se os desenvolvedores descobrirem que há uma incompatibilidade no comportamento real e esperado de um aplicativo na fase de desenvolvimento, eles chamam isso de Erro.

Defeito: Se os testadores encontrarem uma incompatibilidade no comportamento real e esperado de um aplicativo na fase de teste, eles a chamam de Defeito.

Fracasso: Se os clientes ou usuários finais encontrarem uma incompatibilidade no comportamento real e esperado de um aplicativo na fase de produção, eles chamam isso de Falha.

P # 3) Qual é o status de um defeito quando ele é encontrado inicialmente?

Responda: Quando um novo defeito é encontrado, ele está no estado ‘Novo’. Este é o estado inicial de um defeito recém-encontrado.

P # 4) Quais são os diferentes estados de um defeito no ciclo de vida do defeito quando um defeito é aprovado e corrigido por um desenvolvedor?

Responda: Os diferentes estados de um defeito, neste caso, são Novo, Atribuído, Aberto, Fixo, Reteste Pendente, Reteste, Verificado e Fechado.

P # 5) O que acontece se um testador ainda encontrar um problema no defeito que foi corrigido por um desenvolvedor?

Responda: O testador pode marcar o estado do defeito como ‘Reabrir’ se ainda encontrar um problema no defeito corrigido e o defeito for atribuído a um desenvolvedor para novo teste.

Q # 6) O que é um defeito produzível?

Responda: Um defeito que ocorre repetidamente em cada execução e cujas etapas podem ser capturadas em cada execução, então tal defeito é chamado de defeito ‘produzível’.

P # 7) Que tipo de defeito é um defeito não reproduzível?

Responda: Um defeito que não ocorre repetidamente em cada execução e está produzindo apenas em alguns casos e cujas etapas como prova devem ser capturadas com a ajuda de capturas de tela, então tal defeito é chamado de defeito ‘não reproduzível’.

Q # 8) O que é um relatório de defeito?

Responda: Um relatório de defeito é um documento que inclui informações de relatório sobre o defeito ou falha no aplicativo que está causando o fluxo normal de um aplicativo desviado de seu comportamento esperado.

P # 9) Quais detalhes são incluídos em um relatório de defeito?

Responda: Um relatório de defeito consiste nos seguintes detalhes:

ID do defeito, descrição do defeito, nome do recurso, nome do caso de teste, defeito reproduzível ou não, status de um defeito, gravidade e prioridade de um defeito, nome do testador, data de teste do defeito, versão de compilação em que o defeito foi encontrado .

E o Desenvolvedor a quem o defeito foi atribuído, o nome da pessoa que corrigiu o defeito, Capturas de tela de um defeito que descrevem o fluxo das etapas, Fixando a data de um defeito e a pessoa que aprovou o defeito.

P # 10) Quando um defeito é alterado para um estado 'adiado' no ciclo de vida do defeito?

Responda: Quando um defeito encontrado não é de grande importância e aquele que pode ser corrigido nas versões posteriores é movido para um estado 'adiado' no Ciclo de Vida do Defeito.

Informações adicionais sobre defeito ou bug

  • Um defeito pode ser introduzido em qualquer ponto do Ciclo de Vida de Desenvolvimento de Software.
  • Antes que o Defeito seja detectado e removido, menor será o custo geral da qualidade.
  • O custo da qualidade é minimizado quando o defeito é removido na mesma fase em que foi introduzido.
  • O teste estático encontra o defeito, não uma falha. O custo é minimizado porque a depuração não está envolvida.
  • No teste dinâmico, a presença de um defeito é revelada quando ele causa uma falha.

Estados de Defeito

S.No. Estado inicial Estado Devolvido Estado de Confirmação
1Reúna informações para a pessoa responsável por reproduzir o DefeitoO defeito foi rejeitado ou pediu mais informaçõesO defeito é corrigido e deve ser testado e fechado
doisOs estados são abertos ou novosEstados são rejeitados ou esclarecimento.Estados são resolvidos e verificação.

Relatório de defeito inválido e duplicado

  • Às vezes, ocorre defeito, não por causa do código, mas por causa do ambiente de teste ou mal-entendido, tal relatório deve ser fechado como um defeito inválido.
  • No caso de Relatório Duplicado, um é mantido e o outro é encerrado como duplicado. Algum relatório inválido é aceito pelo gerente.
  • O Test Manager (TM) possui o gerenciamento e o processo geral de defeitos e a equipe multifuncional da ferramenta de gerenciamento de defeitos é geralmente responsável por gerenciar os relatórios.
  • Os participantes incluem Test Manager, Developers, PM, Production Manager e outras partes interessadas, que têm interesse.
  • O comitê de gerenciamento de defeitos deve determinar a validade de cada defeito e determinar quando corrigir ou adiar. Para determinar isso, considere o custo, os riscos e os benefícios de não corrigir nenhum defeito.
  • Se o defeito precisa ser corrigido, sua prioridade deve ser determinada.

Dados de Defeito

  • Nome da pessoa.
  • Tipo de Teste
  • Resumo do Problema
  • Descrição detalhada do defeito.
  • Passos para reproduzir
  • Fase do Ciclo de Vida
  • Produto de trabalho onde o Defeito foi introduzido.
  • Gravidade e Prioridade
  • Subsistema ou Componente onde o Defeito é introduzido.
  • Atividade do projeto que ocorre quando o defeito é introduzido.
  • Método de Identificação
  • Tipo de Defeito
  • Projeto e Produto em que existe problema
  • Proprietário Atual
  • O estado atual do relatório
  • Produto de trabalho onde ocorreu o defeito.
  • Impacto no Projeto
  • Risco, perda, oportunidade e benefícios associados à correção ou não do defeito.
  • Datas em que ocorrem várias fases do ciclo de vida do defeito.
  • A descrição de como o defeito foi resolvido e recomendações para teste.
  • Referências

Capacidade do Processo

  • Informações de introdução, detecção e remoção -> Melhore a detecção de defeitos e o custo da qualidade.
  • Introdução -> Análise Praetor do processo em que o maior número de defeitos é introduzido para reduzir o número total de defeitos.
  • Informações da raiz do defeito -> encontre razões sublinhadas para o defeito para reduzir o número total de defeitos.
  • Informações do componente de defeito -> Executar análise de cluster de defeito.

Conclusão

Isso é tudo sobre o ciclo de vida e gerenciamento de defeitos.

Espero que você tenha adquirido imenso conhecimento sobre o ciclo de vida de um defeito. Este tutorial irá, por sua vez, ajudá-lo a trabalhar com os defeitos no futuro de uma maneira fácil.

Leitura recomendada

^