Bugs funcionais estão relacionados à funcionalidade de uma parte de software. Exemplos: Um botão não envia o formulário, a pesquisa não reage à entrada do usuário, o aplicativo trava. Toda vez que você realiza uma ação e o site/aplicativo não responde como você esperava, pode ser um problema funcional. Nossa informação limitada sobre os produtos de nossos clientes e a falta de conhecimento sobre suas implementações tornam difícil determinar se um comportamento observado é intencional ou realmente um bug. Fazersuposições bem fundamentadas com base na experiência e analisar o comportamento do produto testando diferentes cenários pode ajudá-lo a encontrar uma resposta.

Ao julgar o nível de gravidade funcional de um bug, vários fatores devem ser considerados: o impacto funcional do problema, a extensão do problema, se existem soluções alternativas ou se é um bloqueio, se há perdas potenciais notáveis de vendas e se você pode comparar esse bug com outros bugs da mesma gravidade.

Uma abordagem direta é observar o impacto funcional do bug. Pense em quão grave é que uma função não esteja disponível. A funcionalidade subordinada não bloqueará os usuários para alcançar seu objetivo, ao contrário da funcionalidade principal quebrada. Pergunte a si mesmo o quão relevante aquela parte da funcionalidade é no contexto do produto como um todo.

A questão de quantas pessoas, produtos ou itens são afetados por um problema funcional é um fator determinante para a extensão do problema. Por exemplo, o botão "Adicionar ao Carrinho" não reage em todas as páginas de detalhes do produto de uma loja online ou apenas em uma específica? Um pequeno grupo de usuários é afetado pelo problema ou todos?

Considere se você pode alcançar seu objetivo por meio de um caminho ou opção alternativa ou se uma parte da funcionalidade permanece indisponível. Quando você encontra intuitivamente uma maneira de contornar um bug, essa chamada solução alternativa permite que você ainda alcance seu objetivo. Um bug com uma solução alternativa recebe um nível de gravidade mais baixo do que um bug equivalente sem uma solução alternativa. Finalmente, quando não há solução alternativa para a funcionalidade principal quebrada, é um bloqueio.

Estimar uma possível perda de vendas é uma abordagem secundária, pois muitas vezes você só pode assumir como as pessoas podem reagir a um bug. No entanto, leve em consideração o quão alta é uma possível perda. Faz uma grande diferença se o preço de um produto difere por centavos ou centenas de dólares.

Depois de tudo, você também pode comparar seu bug com os que o mesmo líder de equipe (Team Leader) já aprovou neste teste para descobrir se o seu nível de gravidade é apropriado.

Temos uma lista de casos que têm níveis de gravidade fixos. O esquema de avaliação acima não se aplica a casos nessa lista. Como a lista será atualizada ao longo do tempo, verifique-a regularmente.

Me-leva para a Planilha de Avaliação de Bugs!

Bugs de caso extremo ocorrem quando uma parte da funcionalidade é usada de maneira inadequada. A funcionalidade não está quebrada quando usada com dados e ações de usuário típicos. Aqui estão alguns exemplos:

Cada caso deve ser avaliado separadamente. Bugs de caso extremo relevantes para nossos clientes são encaminhados como bugs de Baixa gravidade. Casos irrelevantes, que representam a maioria dos bugs de caso extremo, são rejeitados.

Forçar um bug por meio de comportamento não típico ou condições especiais geralmente está fora do escopo, pois tais bugs não são relevantes para nossos clientes. Comportamento não típico não reflete o comportamento normal dos usuários. Exemplos de comportamento não típico ou condições especiais incluem: