defect management process
Introdução ao processo de gerenciamento de defeitos:
O processo e os testes mais focados permitirão software com menos bugs no mercado.
Prevenção de Defeitos é muito mais eficiente e eficaz na redução do número de defeitos e também é muito econômico para corrigir os defeitos encontrados durante o estágio inicial do processo de software. A maioria das organizações conduzem Descoberta de Defeito , Remoção de Defeito e então Melhoria de processos que é conhecido coletivamente como um Processo de gestão de defeitos .
qa teste de perguntas e respostas da entrevista para experientes
O que você aprenderá:
- Processo de gerenciamento de metas de defeitos (DMP)
- Ciclo de vida de gerenciamento de defeitos
- Processo de gestão de defeitos
- Conclusão
- Leitura recomendada
Processo de gerenciamento de metas de defeitos (DMP)
A seguir estão os vários objetivos deste processo:
- Previna o Defeito
- Detecção precoce
- Minimize o impacto
- Resolução do Defeito
- Melhoria de processos
Antes de explorar o processo de gerenciamento de defeitos, vamos primeiro entender o que é realmente um defeito ou bug?
Ciclo de vida de gerenciamento de defeitos
Quando um sistema fornece uma saída diferente do requisito comercial real, ou seja, quando há um desvio do requisito comercial real ou original, podemos dizer que há um defeito no sistema / software.
Quando a equipe de teste executa os casos de teste, eles se deparam com uma situação em que o resultado real do teste é diferente do resultado esperado. Esta variação é denominada como Defeito .
Basicamente, um defeito de software é uma condição que não atende aos requisitos de software. O defeito é um erro ou falha que produz um comportamento inesperado ou incorreto no sistema.
Para lidar com os projetos de forma adequada, você precisa saber como lidar com o desenvolvimento e a liberação, mas junto com isso também precisa saber como lidar com os defeitos.
Imagine, o que acontecerá se a equipe de teste relatar os defeitos verbalmente e a equipe de desenvolvimento também atualizar o status do defeito verbalmente? O processo será mais complicado porque esses defeitos incluem todos os defeitos como realmente corrigidos e funcionando conforme o esperado, corrigidos, mas ainda não funcionando, rejeitados, adiados e o processo continua.
No caso acima, conforme o número de defeitos aumenta e a comunicação é realizada verbalmente, a situação logo ficará muito pior. Para controlar e lidar com o defeito com eficácia, você precisa do Ciclo de Vida do Defeito adequado.
O ciclo de vida do defeito garante que o processo seja uniforme e padronizado. Um defeito atinge diferentes estados no ciclo de vida. Depois que um defeito é encontrado, ele passa por vários estágios durante sua vida útil e é comumente conhecido como Ciclo de vida do defeito .
Geralmente, o ciclo de vida do defeito começa no estágio em que o defeito é encontrado ou levantado pela equipe de teste e termina quando um defeito é fechado, garantindo que não seja reproduzível ou rejeitado por uma equipe de desenvolvimento. O número de estados pelos quais um defeito passa varia de projeto para projeto.
Leitura adicional:
O que é ciclo de vida de defeito / bug em teste de software? Tutorial de ciclo de vida de defeitos
Observação: O ciclo abaixo difere ligeiramente de organização para organização.
O ciclo de vida do defeito abaixo cobre todos os status possíveis:
- Sempre que a equipe de teste encontra um defeito no aplicativo, eles levantam o defeito com o status de “ NOVO ”.
- Quando um novo defeito é revisado por um líder de QA e se o defeito for válido, o status do defeito seria “ Abrir ”E está pronto para ser atribuído à equipe de desenvolvimento.
- Quando um líder de QA atribui o defeito ao desenvolvedor correspondente, o status do defeito é marcado como “ Atribuído ”. Um desenvolvedor deve começar a analisar e corrigir o defeito nesta fase.
- Quando o desenvolvedor sente que o defeito não é genuíno ou válido, ele rejeita o defeito. O status do defeito é marcado como “ Rejeitado ”E atribuído de volta à equipe de teste.
- Se o defeito registrado for repetido duas vezes ou ambos os defeitos relatados tiverem resultados e etapas semelhantes para reproduzir, então um status de defeito é alterado para “ Duplicado ”.
- Se houver alguns problemas ou obstáculos na versão atual para corrigir um defeito específico, o defeito será considerado nas próximas versões em vez da versão atual e, em seguida, será marcado como “ Diferido ' ou ' Postergado ”.
- Quando um desenvolvedor não consegue reproduzir o defeito pelas etapas mencionadas em “Passos para reproduzir” pela equipe de teste, o desenvolvedor pode marcar o defeito como “ Não reproduzível' . Neste estágio, a equipe de teste deve fornecer etapas de reprodução detalhadas para um desenvolvedor.
- Se o desenvolvedor não tiver certeza sobre as etapas de reprodução fornecidas por um QA para reproduzir o defeito, ele poderá marcá-lo como “ Precisa de mais informação ”. Nesse caso, a equipe de teste precisa fornecer os detalhes necessários à equipe de desenvolvimento.
- Se um defeito já é conhecido e está atualmente presente no ambiente de produção, então o defeito é marcado como “ Defeito conhecido ”.
- Quando um desenvolvedor faz as alterações necessárias, o defeito é marcado como “ Fixo ”.
- O desenvolvedor agora passa o defeito para a equipe de teste para verificar, então o desenvolvedor altera o status como “ Pronto para novo teste ”.
- Se o defeito não tiver mais problemas e for devidamente verificado, o testador marca o defeito como “ Fechadas ”.
- Ao testar novamente o defeito, se o testador descobrir que o defeito ainda é reproduzível ou parcialmente corrigido, o defeito seria marcado como “ Reaberto ”. Agora, o desenvolvedor precisa examinar novamente esse defeito.
Um Ciclo de Vida de Defeito bem planejado e controlado fornece o número total de defeitos encontrados em uma versão ou em todas as versões. Este processo padronizado fornece uma imagem clara de como o código foi escrito, quão corretamente o teste foi realizado, como o defeito ou software foi lançado, etc. Isso reduzirá o número de defeitos na produção, encontrando os defeitos no teste fase em si.
Processo de gestão de defeitos
O processo de gerenciamento de defeitos é explicado em detalhes a seguir.
# 1) Prevenção de defeitos:
Prevenção de Defeitos é o melhor método para eliminar os defeitos no estágio inicial de teste, em vez de encontrar os defeitos no estágio posterior e corrigi-los. Este método também é econômico, pois o custo necessário para consertar os defeitos encontrados nos estágios iniciais de teste é muito baixo.
No entanto, não é possível remover todos os defeitos, mas pelo menos você pode minimizar o impacto do defeito e o custo para consertá-lo.
As principais etapas envolvidas na prevenção de defeitos são as seguintes:
- Identifique o risco crítico : Identifique os riscos críticos no sistema que terão maior impacto se ocorreram durante o teste ou em um estágio posterior.
- Estimativa do impacto esperado : Para cada risco crítico, calcule quanto seria o impacto financeiro se o risco realmente encontrado.
- Minimize o impacto esperado : Depois de identificar todos os riscos críticos, assuma os riscos mais elevados que podem ser prejudiciais ao sistema se encontrados e tente minimizar ou eliminar o risco. Para riscos que não podem ser eliminados, reduz a probabilidade de ocorrência e o seu impacto financeiro.
# 2) Linha de base de entrega:
Quando uma entrega (sistema, produto ou documento) atinge seu marco pré-definido, você pode dizer que uma entrega é uma linha de base. Nesse processo, o produto ou entrega passa de um estágio para outro e, conforme a entrega passa de um estágio para outro, os defeitos existentes no sistema também são transportados para o próximo marco ou estágio.
Por exemplo, considere um cenário de codificação, teste de unidade e teste de sistema. Se um desenvolvedor realiza codificação e teste de unidade, o teste do sistema é realizado pela equipe de teste. Aqui, codificação e Teste de Unidade são um marco e o Teste de Sistema é outro marco.
melhor extensão de bloqueio de anúncios para Chrome
Portanto, durante o teste de unidade, se o desenvolvedor encontrar alguns problemas, isso não será considerado um defeito, pois esses problemas são identificados antes do cumprimento do prazo final. Assim que a codificação e o teste de unidade forem concluídos, o desenvolvedor entrega o código para o teste do sistema e então você pode dizer que o código é “Linha de base” e pronto para o próximo marco, aqui, neste caso, é o “teste do sistema”.
Agora, se os problemas forem identificados durante o teste, ele é chamado de defeito, pois é identificado após a conclusão da etapa anterior, ou seja, codificação e teste de unidade.
Basicamente, as entregas são definidas como base quando as mudanças nas entregas são finalizadas e todos os defeitos possíveis são identificados e corrigidos. Em seguida, a mesma entrega passa para o próximo grupo que trabalhará nela.
# 3) Descoberta de defeito:
É quase impossível remover todos os defeitos do sistema e torná-lo um sistema sem defeitos. Mas você pode identificar os defeitos logo antes que eles se tornem mais caros para o projeto. Podemos dizer que o defeito descoberto significa que ele é formalmente levado ao conhecimento da equipe de desenvolvimento e após a análise disso, a equipe de desenvolvimento do defeito também o aceitou como um defeito.
As etapas envolvidas na descoberta de defeitos são as seguintes:
- Encontre um Defeito : Identifique os defeitos antes que se tornem um grande problema para o sistema.
- Reportar Defeito : Assim que a equipe de teste encontra um defeito, sua responsabilidade é alertar a equipe de desenvolvimento de que existe um problema identificado que precisa ser analisado e corrigido.
- Reconhecer defeito : Uma vez que a equipe de teste atribui o defeito à equipe de desenvolvimento, é responsabilidade da equipe de desenvolvimento reconhecer o defeito e continuar a corrigi-lo se for um defeito válido.
# 4) Resolução de defeitos:
No processo acima, a equipe de teste identificou o defeito e relatou à equipe de desenvolvimento. Agora, aqui a equipe de desenvolvimento precisa prosseguir para a resolução do defeito.
As etapas envolvidas na resolução do defeito são as seguintes:
- Priorize o risco : A equipe de desenvolvimento analisa o defeito e prioriza a correção do defeito. Se um defeito tem mais impacto no sistema, eles fazem a correção do defeito em alta prioridade.
- Corrija o defeito : Com base na prioridade, a equipe de desenvolvimento corrige o defeito, os defeitos de prioridade mais alta são resolvidos primeiro e os defeitos de prioridade mais baixa são corrigidos no final.
- Reportar a Resolução : É responsabilidade da equipe de desenvolvimento garantir que a equipe de teste esteja ciente quando os defeitos estão indo para uma correção e como o defeito foi corrigido, ou seja, alterando um dos arquivos de configuração ou fazendo algumas alterações de código. Isso será útil para a equipe de teste entender a causa do defeito.
# 5) Melhoria do processo:
Embora no processo de resolução de defeitos os defeitos sejam priorizados e corrigidos, do ponto de vista do processo, isso não significa que os defeitos de prioridade mais baixa não sejam importantes e não tenham um grande impacto no sistema. Do ponto de vista da melhoria do processo, todos os defeitos identificados são iguais a um defeito crítico.
Mesmo esses pequenos defeitos oferecem uma oportunidade de aprender como melhorar o processo e evitar a ocorrência de qualquer defeito que possa impactar a falha do sistema no futuro. A identificação de um defeito com um impacto menor no sistema pode não ser um grande problema, mas as ocorrências de tal defeito no próprio sistema são um grande problema.
Para a melhoria do processo, todos no projeto precisam olhar para trás e verificar de onde o defeito foi originado. Com base nisso, você pode fazer alterações no processo de validação, documento básico, processo de revisão que pode detectar os defeitos no início do processo que são menos caros.
Conclusão
O Processo de Gerenciamento de Defeitos deve ser seguido durante o processo geral de desenvolvimento de software e não apenas para testes específicos ou atividades de desenvolvimento.
Se um defeito for encontrado na fase de teste, pode-se levantar a questão de que, se o defeito for detectado nesta fase, o que dizer dos outros defeitos que estão ativos no sistema e que podem causar falha do sistema se ocorrer e ainda não for descoberto.
Portanto, todos os processos, como processo de revisão, teste estático, inspeção, etc., precisam ser fortalecidos e todos no projeto devem levar o processo a sério e contribuir sempre que necessário. A alta administração da organização também deve compreender e apoiar o processo de gerenciamento de defeitos.
Abordagens de teste, processo de revisão, etc., devem ser escolhidos com base no objetivo do projeto ou processo organizacional.
Espero que este artigo informativo sobre o Processo de gerenciamento de defeitos seja de grande ajuda para você.
Leitura recomendada
- O que é técnica de teste baseada em defeitos?
- Processo de triagem de defeitos e maneiras de lidar com a reunião de triagem de defeitos
- O que é ciclo de vida de defeito / bug em teste de software? Tutorial de ciclo de vida de defeitos
- Tutorial do Bugzilla: Tutorial prático da ferramenta de gerenciamento de defeitos
- Métodos e técnicas de prevenção de defeitos
- Tutorial da ferramenta de gerenciamento de defeitos do IBM Rational Team Concert
- Como reproduzir um defeito não reproduzível e fazer seu esforço de teste valer a pena
- O teste de software tem tudo a ver com ideias (e como gerá-las)