defect severity priority testing with examples
Neste tutorial, você aprenderá o que é Gravidade e Prioridade do Defeito em testes, como definir a prioridade do defeito e os níveis de gravidade com exemplos para entender o conceito claramente.
Também abordaremos em detalhes como classificar os defeitos em diferentes categorias e sua relevância no ciclo de vida do defeito. Também cobriremos o papel crucial da classificação com um conjunto de exemplos ao vivo.
Os defeitos de arquivamento são muito importantes parte do ciclo de vida do teste de software . Existem várias práticas recomendadas definidas para Relatório de defeitos eficaz na Internet ou em organizações.
O que você aprenderá:
- Visão geral do rastreamento de defeitos
Visão geral do rastreamento de defeitos
Um dos aspectos importantes do ciclo de vida do defeito em um nível genérico inclui o rastreamento de defeitos. Isso é importante porque as equipes de teste descobrem vários defeitos ao testar um software, que só é multiplicado se o sistema em teste específico for complexo. Em tal cenário, gerenciar esses defeitos e analisá-los para conduzir o fechamento pode ser uma tarefa difícil.
Em linha com os processos de manutenção de defeitos, quando qualquer testador arquiva um defeito - além do método / descrição para reproduzir o problema visto, ele também deve fornecer algumas informações categóricas que ajudariam na classificação imprecisa do defeito. Isso, por sua vez, ajudaria em processos de manutenção / rastreamento de defeitos eficientes e também formaria a base para um tempo de resposta de defeito mais rápido.
Os dois parâmetros principais que formam a base para o rastreamento e resolução de defeitos eficazes são:
- Prioridade de defeito no teste
- Gravidade do defeito no teste
Esses são frequentemente um conceito confuso e quase são usados indistintamente não apenas entre equipes de teste, mas também entre equipes de desenvolvimento. Há uma linha tênue entre os dois e é importante entender que realmente existem diferenças entre os dois.
Vamos entender brevemente as definições teóricas dos dois parâmetros na próxima seção.
O que é gravidade e prioridade do defeito?
A prioridade pela definição inglesa é usada na comparação de duas coisas ou condições, onde uma deve receber mais importância do que a outra e deve ser tratada / resolvida primeiro, antes de prosseguir para a (s) próxima (s). Portanto, no contexto de defeitos, a prioridade de um defeito indicaria a urgência com que ele precisaria ser corrigido.
Severidade pela definição inglesa é usada para descrever a gravidade de uma ocorrência indesejável. Portanto, quando se trata de bugs, a gravidade de um bug indicaria o efeito que ele tem no sistema em termos de seu impacto.
Quem os define?
O controle de qualidade classifica o defeito sob a gravidade apropriada com base na complexidade e na criticidade dos defeitos.
Todas as partes interessadas do negócio, incluindo gerentes de projeto, analistas de negócios, proprietário do produto, definem a prioridade dos defeitos.
A figura a seguir descreve a função que possui e classifica a criticidade e gravidade dos defeitos.
Como escolher esses níveis?
Como já discutimos, o parâmetro de gravidade é avaliado pelo testador, enquanto o parâmetro de prioridade é avaliado principalmente pelo Gerente de Produto ou basicamente pela equipe de triagem. Mesmo quando este for o caso, a gravidade de um defeito é definitivamente um dos fatores governantes e influenciadores para priorizar o defeito. Por isso, é importante, como testador, selecionar a gravidade certa para evitar confusão com as equipes de desenvolvimento.
Diferença entre gravidade e prioridade
A prioridade está associada ao agendamento e a “gravidade” está associada aos padrões.
“Prioridade” significa que algo é concedido ou merece atenção prévia; precedência estabelecida por ordem de importância (ou urgência).
“Gravidade” é o estado ou qualidade de ser grave; severo implica adesão a padrões rigorosos ou princípios elevados e freqüentemente sugere aspereza; grave é marcado por ou requer estrita adesão a padrões rigorosos ou princípios elevados, Por exemplo, um código de comportamento severo.
As palavras prioridade e gravidade aparecem no rastreamento de bugs.
Uma variedade de ferramentas comerciais de software de rastreamento / gerenciamento de problemas está disponível. Essas ferramentas, com a entrada detalhada de engenheiros de teste de software, fornecem à equipe informações completas para que os desenvolvedores possam entender o bug, ter uma ideia de sua ‘Severidade’, reproduzi-lo e corrigi-lo.
As correções são baseadas nas ‘Prioridades’ e ‘Gravidade’ dos bugs do projeto.
A ‘Gravidade’ de um problema é definida de acordo com a avaliação de risco do cliente e registrada em sua ferramenta de rastreamento selecionada.
O software com erros pode afetar 'severamente' os cronogramas, o que, por sua vez, pode levar a uma reavaliação e renegociação de 'prioridades'.
O que é prioridade?
Prioridade, como o nome sugere, é priorizar um defeito com base nas necessidades do negócio e na gravidade do defeito. Prioridade significa a importância ou urgência de corrigir um defeito.
Ao abrir um defeito, o testador geralmente atribui a prioridade inicialmente à medida que vê o produto da perspectiva do usuário final. De acordo com eles, existem diferentes níveis:
Em termos gerais, a prioridade dos defeitos pode ser classificada da seguinte forma:
Prioridade # 1) Imediato / Crítico (P1)
Isso deve ser corrigido imediatamente dentro de 24 horas. Isso geralmente ocorre nos casos em que uma funcionalidade inteira é bloqueada e nenhum teste pode prosseguir como resultado disso. Ou, em alguns outros casos, se houver vazamentos de memória significativos, geralmente o defeito é classificado como prioridade -1, o que significa que o programa / recurso está inutilizável no estado atual.
Qualquer defeito que necessite de atenção imediata e que afete o processo de teste será classificado na categoria imediata
Todos Gravidade crítica os defeitos se enquadram nesta categoria (a menos que seja priorizado novamente pelo negócio / partes interessadas)
Prioridade # 2) Alta (P2)
Uma vez que os defeitos críticos tenham sido corrigidos, um defeito com essa prioridade é o próximo candidato que deve ser corrigido para qualquer atividade de teste para corresponder aos critérios de “saída”. Normalmente, quando um recurso não pode ser usado como deveria, devido a um defeito do programa ou que um novo código deve ser escrito ou, às vezes, até porque algum problema ambiental deve ser tratado por meio do código, um defeito pode ser qualificado para uma prioridade 2 .
Este é o defeito ou problema que deve ser resolvido antes da liberação. Esses defeitos devem ser resolvidos assim que os problemas críticos forem resolvidos.
Todos Principal gravidade os defeitos se enquadram nesta categoria.
Prioridade # 3) Média (P3)
Um defeito com esta prioridade deve estar em disputa para ser corrigido, pois também pode lidar com problemas de funcionalidade que não estão de acordo com o esperado. Às vezes, até mesmo erros estéticos, como esperar a mensagem de erro certa durante a falha, podem ser qualificados como um defeito de prioridade 3.
Esse defeito deve ser resolvido depois que todos os bugs sérios forem corrigidos.
Assim que os bugs críticos e de alta prioridade forem concluídos, podemos ir para os bugs de prioridade média.
Todos Menor gravidade os defeitos se enquadram nesta categoria.
Prioridade # 4) Baixa (P4)
Um defeito com baixa prioridade indica que definitivamente há um problema, mas não precisa ser corrigido para corresponder aos critérios de 'saída'. No entanto, isso deve ser corrigido antes que o GA seja feito. Normalmente, alguns erros de digitação ou mesmo erros cosméticos, conforme discutido anteriormente, podem ser categorizados aqui.
Às vezes, defeitos com baixa prioridade também são abertos para sugerir alguns aprimoramentos no design existente ou uma solicitação para implementar um pequeno recurso para aprimorar a experiência do usuário.
Este defeito pode ser resolvido no futuro e não precisa de qualquer atenção imediata e o Baixa gravidade os defeitos se enquadram nesta categoria.
Como já discutido, a prioridade determina a rapidez com que o tempo de resposta do defeito deve ser. Se houver vários defeitos, a prioridade decide qual defeito deve ser corrigido e verificado imediatamente, em comparação com qual defeito pode ser corrigido um pouco mais tarde.
O que é gravidade?
A gravidade define até que ponto um defeito específico pode criar um impacto no aplicativo ou sistema.
A gravidade é um parâmetro para denotar a implicação do defeito no sistema - quão crítico é o defeito e qual é o impacto do defeito em toda a funcionalidade do sistema? A gravidade é um parâmetro definido pelo testador enquanto ele abre um defeito e está principalmente no controle do testador. Novamente, diferentes organizações têm diferentes ferramentas para usar para defeitos, mas em um nível genérico, esses são os seguintes níveis de gravidade:
Por exemplo, Considere os seguintes cenários
- Se o usuário tentar fazer compras online e o aplicativo não carregar ou uma mensagem de servidor indisponível for exibida.
- O usuário executa a adição de um item ao carrinho, o número de quantidades adicionadas está incorreto / produto errado é adicionado.
- O usuário efetua o pagamento e após o pagamento, o pedido permanece no carrinho como reservado ao invés de confirmado.
- O sistema aceita o pedido, mas, finalmente, o cancela após meia hora devido a quaisquer problemas.
- O sistema aceita “Adicionar ao carrinho” apenas com um clique duplo em vez de com um único clique.
- O botão Adicionar ao carrinho é escrito como Adicionar ao carrinho.
Qual seria a experiência do usuário, se algum dos cenários acima pudesse acontecer?
Em termos gerais, os defeitos podem ser classificados da seguinte forma:
# 1) Crítico (S1)
Um defeito que dificulta ou bloqueia completamente o teste do produto / recurso é um defeito crítico. Um exemplo seria o caso de teste de IU em que, depois de passar por um assistente, a IU apenas trava em um painel ou não vai além para acionar a função. Ou em alguns outros casos, quando o próprio recurso desenvolvido está faltando na construção.
Por qualquer motivo, se o aplicativo travar ou se tornar inutilizável / incapaz de prosseguir, o defeito pode ser classificado como gravidade crítica.
exemplos de script de shell unix para iniciantes
Quaisquer falhas catastróficas do sistema podem levar o usuário à não usabilidade dos aplicativos e podem ser classificados na gravidade Crítica
Por exemplo, No provedor de serviço de e-mail como Yahoo ou Gmail, após digitar o nome de usuário e a senha corretos, ao invés de fazer o login, o sistema trava ou lança a mensagem de erro, esse defeito é classificado como crítico, pois torna todo o aplicativo inutilizável.
O cenário no ponto 1 discutido acima pode ser classificado como Defeito Crítico, pois o aplicativo online se torna completamente inutilizável.
# 2) Maior (S2)
Qualquer recurso Principal implementado que não atenda aos seus requisitos / casos de uso e se comporte de maneira diferente do esperado, pode ser classificado em Severidade Principal.
Um grande defeito ocorre quando a funcionalidade está funcionando muito longe das expectativas ou não está fazendo o que deveria. Um exemplo poderia ser: Digamos que uma VLAN precisa ser implantada no switch e você está usando um modelo de IU que aciona essa função. Quando este modelo para configurar VLAN falha no switch, ele é classificado como uma desvantagem de funcionalidade severa.
Por exemplo, No provedor de serviços de e-mail como Yahoo ou Gmail, quando você não tem permissão para adicionar mais de um destinatário na seção CC, esse defeito é classificado como o defeito principal, pois a funcionalidade principal do aplicativo não está funcionando corretamente.
O que se espera do comportamento da seção CC no e-mail, deve permitir ao usuário adicionar vários usuários. Portanto, quando a principal funcionalidade do aplicativo não está funcionando corretamente ou quando se comporta de maneira diferente do esperado, é um defeito grave.
Os cenários nos pontos 2 e 3 discutidos acima podem ser classificados como Defeito Principal, já que o pedido deve se mover suavemente para a próxima fase do ciclo de vida do pedido, mas na realidade, ele varia em comportamento.
Qualquer defeito que possa levar à persistência de dados incorretos, problemas de dados ou comportamentos incorretos do aplicativo pode ser amplamente classificado na gravidade Principal.
# 3) Menor / Moderado (S3)
Qualquer recurso implementado que não atenda aos seus requisitos / casos de uso e se comporte de maneira diferente do esperado, mas o impacto seja insignificante até certo ponto ou não tenha um grande impacto no aplicativo, pode ser classificado como Gravidade Menor.
Um defeito moderado ocorre quando o produto ou aplicativo não atende a certos critérios ou ainda exibe algum comportamento não natural, no entanto, a funcionalidade como um todo não é afetada. Por exemplo, no modelo de VLAN implementado acima, um defeito moderado ou normal ocorreria quando o modelo fosse implementado com sucesso no switch, no entanto, não há nenhuma indicação sendo enviada ao usuário.
Por exemplo, No provedor de serviço de e-mail como Yahoo ou Gmail, existe a opção chamada “Termos e Condições” e nessa opção, haverá vários links referentes aos termos e condições do site, quando um entre os vários links não está funcionando bem, é chamado de gravidade secundária, pois afeta apenas a funcionalidade secundária do aplicativo e não tem grande impacto na usabilidade do aplicativo.
O cenário no ponto 5 discutido acima pode ser classificado como Defeito Menor, já que não há perda de dados ou falha na ordem do fluxo do sistema, mas um pequeno inconveniente no que diz respeito à experiência do usuário.
Esses tipos de defeito resultam em perda mínima de funcionalidade ou experiência do usuário.
como implementar uma árvore de pesquisa binária em java
# 4) Baixo (S4)
Quaisquer defeitos cosméticos, incluindo erros ortográficos ou problemas de alinhamento ou caixa da fonte, podem ser classificados em Gravidade Baixa.
Um pequeno bug de baixa gravidade ocorre quando quase não há impacto na funcionalidade, mas ainda é um defeito válido que deve ser corrigido. Exemplos disso podem incluir erros de grafia em mensagens de erro impressas para usuários ou defeitos para aprimorar a aparência de um recurso.
Por exemplo, No provedor de serviço de e-mail como Yahoo ou Gmail, você deve ter notado a “página de licença”, se houver algum erro de ortografia ou desalinhamento na página, esse defeito é classificado como Baixo.
O cenário no ponto 6 discutido acima pode ser classificado como Baixo defeito, pois o botão Adicionar é exibido no revestimento errado. Este tipo de defeito não terá qualquer impacto no comportamento do sistema ou apresentação de dados ou perda de dados ou fluxo de dados ou mesmo na experiência do usuário, mas será muito cosmético.
Para resumir, a figura a seguir descreve a ampla classificação de Defeito com base na Gravidade e na Prioridade:
Exemplos
Como já mencionado, uma vez que diferentes organizações usam diferentes tipos de ferramentas para rastreamento de defeitos e seus processos relacionados, torna-se um sistema de rastreamento comum entre vários níveis de gestão e pessoal técnico.
Como a Gravidade do Defeito está mais dentro do alcance da funcionalidade, o Engenheiro de Teste define a gravidade do defeito. Às vezes, os desenvolvedores participam de influenciar a gravidade do defeito, mas principalmente depende do testador, pois ele avalia o quanto um determinado recurso pode afetar o funcionamento geral.
Por outro lado, quando se trata de definir a prioridade do defeito, embora inicialmente, o originador do defeito defina a prioridade, na verdade ela é definida pelo Gerente de Produto, pois ele tem uma visão geral do produto e a rapidez com que um defeito específico deve ser resolvido . Um testador não é a pessoa ideal para definir a prioridade do defeito.
Por mais chocante que possa parecer, existem dois exemplos distintos do motivo:
Exemplo 1) Considere que há uma situação em que o usuário encontra um erro na nomenclatura do próprio produto ou algum problema com a documentação da IU. Um testador normalmente abriria um pequeno defeito / cosmético e pode ser muito simples de corrigir, mas quando se trata da aparência do produto / experiência do usuário, isso pode causar um sério impacto.
Exemplo # 2) Pode haver certas condições sob as quais ocorre um defeito específico que pode ser extremamente raro ou sem possibilidade de ocorrer no ambiente do cliente. Mesmo que em termos de funcionalidade, isso possa parecer um defeito de alta prioridade para um testador, considerando sua raridade de ocorrência e alto custo para consertar - isso seria classificado como um defeito de baixa prioridade.
Conseqüentemente, a prioridade do defeito é geralmente definida pelo gerente de produto em uma reunião de “triagem de defeito”.
Niveis diferentes
Prioridade e Gravidade têm algumas classificações entre elas que ajudam a determinar como o defeito deve ser tratado. Muitas organizações diferentes têm diferentes ferramentas de registro de defeitos , então os níveis podem variar.
Vamos dar uma olhada nos diferentes níveis de Prioridade e Gravidade.
- Alta prioridade, alta gravidade
- Alta prioridade, baixa gravidade
- Alta Gravidade, Baixa Prioridade
- Baixa Gravidade, Baixa Prioridade
A figura a seguir descreve a classificação das categorias em um único trecho.
# 1) Alta Severidade e Alta Prioridade
Qualquer falha crítica / importante no caso de negócios é automaticamente promovida para esta categoria.
Qualquer defeito devido ao qual o teste não pode continuar a qualquer custo ou faz com que uma falha grave do sistema caia nesta categoria. Por exemplo, clicar em um botão específico não carrega o próprio recurso. Ou executar uma função específica desativa o servidor de forma consistente e causa perda de dados. As linhas vermelhas na figura acima indicam esses tipos de defeitos.
Por exemplo,
O sistema trava após você efetuar o pagamento ou quando você não consegue adicionar os itens ao carrinho, esse defeito é marcado como Severidade alta e defeito de alta prioridade.
Outro exemplo seria o recurso de moeda de venda automática em ATM em que, após inserir o nome de usuário e a senha corretos, a máquina não distribui dinheiro, mas deduz o transferido de sua conta.
# 2) Alta prioridade e baixa gravidade
Qualquer defeito de gravidade menor que possa impactar diretamente a experiência do usuário é automaticamente promovido a esta categoria.
Os defeitos que precisam ser corrigidos, mas não afetam o aplicativo, entram nesta categoria.
Por exemplo, espera-se que o recurso exiba um erro específico para o usuário em relação ao seu código de retorno. Nesse caso, funcionalmente, o código gerará um erro, mas a mensagem precisará ser mais relevante para o código de retorno gerado. As linhas azuis na figura indicam esses tipos de defeitos.
Por exemplo,
O logotipo da empresa na primeira página está errado, é considerado Alta prioridade e baixa gravidade defeito .
Exemplo 1) No site de compras online, quando o logotipo do FrontPage está incorreto, por exemplo, em vez de Flipkart, ele é escrito Flipkart.
Exemplo 2) No logotipo do banco, em vez de ICICI, está escrito como ICCCI.
Em termos de funcionalidade, não está afetando nada, portanto podemos marcar como Baixa Severidade, mas tem impacto na experiência do usuário. Esse tipo de defeito precisa ser corrigido em alta prioridade, embora tenha muito menos impacto no lado do aplicativo.
# 3) Alta Severidade e Baixa Prioridade
Qualquer defeito que não atenda funcionalmente aos requisitos ou tenha alguma implicação funcional no sistema, mas deixado de lado pelas partes interessadas no que diz respeito à criticidade do negócio, é automaticamente promovido a esta categoria.
Defeitos que precisam ser corrigidos, mas não imediatamente. Isso pode ocorrer especificamente durante o teste ad-hoc. Isso significa que a funcionalidade é afetada em grande medida, mas é observada apenas quando certos parâmetros de entrada incomuns são usados.
Por exemplo, uma funcionalidade específica pode ser usada apenas em uma versão posterior do firmware, portanto, para verificar isso, o testador realmente faz o downgrade de seu sistema, executa o teste e observa um sério problema de funcionalidade que é válido. Nesse caso, os defeitos serão classificados nesta categoria denotada por linhas rosa, já que normalmente espera-se que os usuários finais tenham uma versão superior do firmware.
Por exemplo,
Em um site de rede social, se uma versão beta de um novo recurso for lançada com poucos usuários ativos usando esse recurso até hoje. Qualquer defeito encontrado neste recurso pode ser classificado como de baixa prioridade, pois o recurso fica em segundo plano devido à classificação do negócio como não importante.
Embora esse recurso tenha um defeito funcional, já que não está afetando diretamente os clientes finais, uma parte interessada do negócio pode classificar o defeito como baixa prioridade, embora tenha um impacto funcional severo no aplicativo.
Esta é uma falha de alta gravidade, mas pode ser priorizada para baixa prioridade, pois pode ser corrigida com a próxima versão como uma solicitação de mudança. As partes interessadas da empresa também priorizam esse recurso como um recurso raramente usado e não impacta nenhum outro recurso que tenha um impacto direto na experiência do usuário. Este tipo de defeito pode ser classificado na Alta gravidade, mas baixa prioridade categoria.
# 4) Baixa Gravidade e Baixa Prioridade
Quaisquer erros de grafia / maiúsculas / minúsculas / desalinhamento no parágrafo do 3rdou 4ºpágina do aplicativo e não na página / título principal ou frontal.
Esses defeitos são classificados nas linhas verdes conforme mostrado na figura e ocorrem quando não há impacto na funcionalidade, mas ainda não atendem aos padrões em pequena escala. Geralmente, os erros cosméticos ou, digamos, as dimensões de uma célula em uma tabela na IU são classificados aqui.
Por exemplo,
Se a política de privacidade do site contém um erro ortográfico, esse defeito é definido como Baixa gravidade e baixa prioridade.
Diretrizes
Abaixo estão algumas diretrizes que todo testador deve tentar seguir:
- Em primeiro lugar, compreenda bem os conceitos de prioridade e gravidade. Evite confundir um com o outro e usá-los de forma intercambiável. Em linha com isso, siga as diretrizes de gravidade publicadas por sua organização / equipe para que todos estejam na mesma página.
- Sempre escolha o nível de gravidade com base no tipo de problema, pois isso afetará sua prioridade. Alguns exemplos são:
- Para um problema que é crítico, como todo o sistema cai e nada pode ser feito - essa gravidade não deve ser usada para corrigir defeitos do programa.
- Para um problema grave, como nos casos em que a função não está funcionando conforme o esperado - essa gravidade pode ser usada para tratar de novas funções ou melhorar o funcionamento atual.
Lembre-se de que escolher o nível de severidade certo, por sua vez, dará o defeito, é a prioridade devida.
- Como um testador - compreender como uma funcionalidade específica, em vez de aprofundar mais - compreender como um determinado cenário ou caso de teste afetaria o usuário final. Isso envolve muita colaboração e interação com a equipe de desenvolvimento, analistas de negócios, arquitetos, líder de teste e líder de desenvolvimento. Em suas discussões, você também precisa levar em consideração quanto tempo levaria para consertar o defeito com base em sua complexidade e tempo para verificar esse defeito.
- Finalmente , é sempre o proprietário do produto que possui o poder de veto da liberação do defeito deve ser corrigido. No entanto, como as sessões de triagem de defeitos contêm membros variados para apresentar sua perspectiva sobre o defeito com base no caso, nesse momento, se os desenvolvedores e testadores estiverem em sincronia, isso certamente ajuda a influenciar a decisão.
Conclusão
Ao abrir defeitos, é responsabilidade do testador atribuir a severidade certa aos defeitos. A gravidade incorreta e, portanto, o mapeamento de prioridade podem ter implicações muito drásticas no processo STLC geral e no produto como um todo. Em várias entrevistas de emprego - várias perguntas são feitas sobre prioridade e gravidade para garantir que, como testador, você tenha esses conceitos impecavelmente claros em sua mente.
Além disso, vimos exemplos ao vivo de como classificar o defeito em vários baldes de Severidade / Prioridade. Agora, gostaria que você tivesse esclarecimento suficiente sobre a classificação de defeitos nos intervalos de gravidade / prioridade.
Espero que este artigo seja um guia completo para entender os níveis de prioridade e gravidade do defeito. Deixe-nos saber sua opinião / dúvida nos comentários abaixo.
Leitura recomendada
- O que é técnica de teste baseada em defeitos?
- O que é ciclo de vida de defeito / bug em teste de software? Tutorial de ciclo de vida de defeitos
- Processo de gerenciamento de defeitos: como gerenciar um defeito de forma eficaz
- Como reproduzir um defeito não reproduzível e fazer seu esforço de teste valer a pena
- 7 Princípios de Teste de Software: Clustering de Defeitos e Princípio de Pareto
- Métodos e técnicas de prevenção de defeitos
- Diferença exata entre verificação e validação com exemplos
- 3 estratégias para lidar com um defeito bloqueador