Diferença entre gravidade e prioridade nos testes (exemplo)

Gravidade vs. Prioridade: diferença entre eles

• Prioridade é a ordem em que o desenvolvedor deve resolver um defeito, enquanto Gravidade é o grau de impacto que um defeito tem na operação do produto.
• A prioridade é categorizada em três tipos: baixa, média e alta, enquanto a gravidade é categorizada em cinco tipos: crítica, maior, moderada, menor e cosmética.
• A prioridade está associada ao agendamento, enquanto a gravidade está associada à funcionalidade ou aos padrões.
• A Prioridade indica quando o bug deve ser corrigido, enquanto a Gravidade indica a gravidade do defeito na funcionalidade do produto.
• A prioridade dos defeitos é decidida em consulta com o gerente/cliente, enquanto os níveis de gravidade dos defeitos são determinados pelo engenheiro de controle de qualidade.
• A prioridade é impulsionada pelo valor comercial, enquanto a gravidade é impulsionada pela funcionalidade.
• O valor da prioridade é subjetivo e pode mudar ao longo de um período de tempo, dependendo da mudança na situação do projeto, enquanto o valor da gravidade é objetivo e tem menor probabilidade de mudar.
• O status de alta prioridade e baixa gravidade indica que o defeito deve ser corrigido imediatamente, mas não afeta o aplicativo, enquanto o status de alta gravidade e baixa prioridade indica que o defeito deve ser corrigido, mas não em bases imediatas.
• O status de prioridade é baseado nos requisitos do cliente, enquanto o status de gravidade é baseado no aspecto técnico do produto.

O que é a gravidade do bug

Gravidade do bug ou A gravidade do defeito nos testes é o grau de impacto de um bug ou Defeito tem no aplicativo de software em teste. Um efeito maior de bug/defeito na funcionalidade do sistema levará a um nível de gravidade mais alto. A Garantia da Qualidade O engenheiro geralmente determina o nível de gravidade de um bug/defeito.

O que é prioridade?

Prioridade é definida como a ordem em que um defeito deve ser corrigido. Quanto maior a prioridade, mais cedo o defeito deverá ser resolvido.

Os defeitos que deixam o sistema de software inutilizável recebem maior prioridade sobre os defeitos que causam falha em uma pequena funcionalidade do software.

Tipos de gravidade

In Teste de software, Os tipos de gravidade do bug/defeito podem ser categorizados nas seguintes partes:

• Crítico: Este defeito indica o encerramento completo do processo, nada pode prosseguir
• Principal: É um defeito altamente grave e colapsa o sistema. No entanto, certas partes do sistema permanecem funcionais
• Médio: Causa algum comportamento indesejável, mas o sistema ainda está funcional
• Baixo: Não causará nenhuma falha grave no sistema

Tipos de prioridade

Os tipos de prioridade de bug/defeito podem ser categorizados em três partes:

• Low: O Defeito é irritante, mas o reparo pode ser feito assim que o Defeito mais grave for corrigido
• Meio: Durante o curso normal das atividades de desenvolvimento, o defeito deve ser resolvido. Pode esperar até que uma nova versão seja criada
• High: O defeito deve ser resolvido o mais rápido possível, pois afeta gravemente o sistema e não pode ser usado até que seja corrigido

Dicas para determinar a gravidade de um defeito

• Decida a frequência de ocorrência: Em alguns casos, se a ocorrência de um defeito menor for frequente no código, pode ser mais grave. Portanto, do ponto de vista do usuário, é mais sério, embora seja um defeito menor.
• Isolar o defeito: Isolar o defeito pode ajudar a descobrir a gravidade do impacto.

Diferença entre gravidade e prioridade nos testes

Exemplo de gravidade e prioridade de defeito

Vejamos um exemplo de baixa gravidade e alta prioridade e vice-versa

• Uma gravidade muito baixa com alta prioridade: um erro de logotipo para qualquer site de remessa pode ser de gravidade baixa, pois não afetará a funcionalidade do site, mas pode ser de alta prioridade, pois você não deseja que nenhuma remessa adicional prossiga com o logotipo errado.
• Uma gravidade muito alta com uma prioridade baixa: Da mesma forma, para um site de operação de voo, um defeito na funcionalidade de reserva pode ser de alta gravidade, mas pode ser de baixa prioridade, pois pode ser programado para ser lançado em um próximo ciclo.

Triagem de defeitos

A triagem de defeitos é um processo que tenta fazer o reequilíbrio do processo onde a equipe de teste enfrenta o problema de disponibilidade limitada de recursos. Portanto, quando há um grande número de defeitos e testadores limitados para verificá-los, a triagem de defeitos ajuda a tentar resolver o máximo de defeitos com base em parâmetros de defeito, como gravidade e prioridade.

Como determinar a triagem de defeitos:

A maioria dos sistemas utiliza a prioridade como principal critério para avaliar o defeito. No entanto, um bom processo de triagem também considera a gravidade.

O processo de triagem inclui as seguintes etapas

• Revvisualizando todos os defeitos, incluindo defeitos rejeitados pela equipe
• A avaliação inicial dos defeitos é baseada no seu conteúdo e respectivas configurações de prioridade e gravidade
• Priorizando o defeito com base nas entradas
• Atribuir o defeito para liberação correta pelo gerente de produto
• Redireciona o defeito para o proprietário/equipe correto para ações adicionais

Diretrizes que todo testador deve considerar antes de selecionar uma gravidade

O parâmetro de gravidade é avaliado pelo testador, enquanto o parâmetro de prioridade é avaliado pelo gerente de produto ou pela equipe de triagem. Para priorizar o defeito, é fundamental que o testador escolha a gravidade correta para evitar confusão com a equipe de desenvolvimento.

• Entenda bem o conceito de prioridade e gravidade
• Sempre atribua o nível de gravidade com base no tipo de problema, pois isso afetará sua prioridade
• Entenda como um determinado cenário ou Caso de teste afetaria o usuário final
• Precisa considerar quanto tempo levaria para corrigir o defeito com base em sua complexidade e no tempo para verificar o defeito

Conclusão

In Engenharia de Software, Atribuir gravidade errada ao defeito pode atrasar o STLC processo e pode ter algumas implicações drásticas no desempenho geral da equipe. Portanto, o responsável precisa ser preciso e preciso na sua chamada para atribuição do defeito.