Skip to main content
bug, omissão, falha, erro, falso positivo

Bug, omissão, defeito, falha, erro, engano: O que tudo isso significa?

Por: Rex Black

Existe uma grande quantidade de termos em teste de software, e muitas vezes não se torna claro para nós o que eles realmente significam. Uma confusão comum refere-se aos termos bug, defeito, omissão, falha, incidente, falso positivo, erro e engano. Continue lendo o artigo para entender melhor o que é cada um desses termos!

bug, omissão, falha, erro, falso positivo

O leitor Rodrigo Cursino pergunta:

Eu li o livro [Foundations of Software Testing]… Você definiu bug como um sinônimo de omissão ou defeito. Se exercitarmos a parte do software que contém o bug, nós teremos uma falha.

Agora estou lendo o artigo “Os processos de reporte de bugs”, e me confundi um pouco. O título correto deveria ser “Os processos de reporte de falhas”. Isso por que nós reportamos falhas, e não bugs. Os desenvolvedores, baseados nos passos para se reproduzir a falha, estarão aptos a realizar a depuração e encontrar o bug.

Rodrigo, você está correto. Este foi o caso do uso comum levando a um erro terminológico, eu creio. Muitas pessoas falam sobre “relatório de bugs”, então usei esse termo no artigo e também em meu livro Critical Testing Processes.

Se quisermos ser rigorosos em nossa terminologia, vamos falar agora da maneira de como devemos pensar na sequência de eventos.

Sequência de eventos que envolvem o descobrimento e a correção de um bug

1 – O programador comete um engano (também chamado de erro). Este engano pode ser um equívoco no entendimento do estado interno do software, um descuido em termos de gerenciamento de memória, confusão a respeito da maneira adequada de calcular um valor, etc.

O programador introduz um bug (também chamado de defeito) no código. Esta é a manifestação programática do erro.

2- O testador executa a parte do software que contém o bug.

3- Se o teste foi adequadamente modelado para revelar o bug, o teste pode levar o software “bugado” a ser executado de tal forma que o comportamento do software não é aquele que o testador (que está observando de perto o comportamento) iria esperar.

A diferença entre o comportamento esperado e o comportamento presente é chamado de anomalia.

4- A partir disso, o testador investiga a anomalia para determinar a falha exata. A falha pode ir além dos comportamentos óbvios e imediatamente observáveis associados com a anomalia.

bug, omissão, falha, erro, falso positivo

Por exemplo, os dados podem estar corrompidos, outro processo pode ter sido terminado de forma inadequada, etc.

5- Os resultados dessa investigação são um relatório, o qual é normalmente chamado no mercado de software de relatório de bug, relatório de incidente, relatório de defeitos, uma questão, um relatório de problemas, entre vários outros nomes.

6- Independente da forma como nós o chamamos, o relatório é priorizado e (em alguns casos) finalmente direcionado a um programador. O programador, a partir daí, depura o programa para reparar o bug subjacente.

7- Preferencialmente, a correção do bug (normalmente como parte de uma liberação maior de teste) retorna ao testador que reportou o problema com o objetivo de ser executado um teste de confirmação.

Se o teste de confirmação aprova a correção, o relatório pode ser encerrado como corrigido. Se o teste de confirmação não aprova a correção, o relatório deve ser reaberto.

Alguns pontos adicionais importantes

bug, omissão, falha, erro, falso positivo

1 – Em alguns casos, quando um testador executa um teste, ele observa uma anomalia, mas não devido a uma falha.

Isto ocorre quando a anomalia resulta de um teste ruim, dados de teste inadequados, um ambiente de teste não configurado de forma adequada, ou simplesmente um erro de entendimento por parte do testador.

Esta situação é chamada de falso positivo.

É inevitável que alguns relatórios trarão falsos positivos – testadores são seres humanos, portanto irão inevitavelmente cometer enganos.

Algumas pessoas gostam de se referir a esses relatórios como relatórios de incidentes. Um incidente é qualquer situação que requer investigação posterior, e neste caso o programador irá investigar a medida na qual o incidente foi realmente causado por uma falha.

2 – Bugs (ou defeitos) podem ser introduzidos em produtos de trabalho além de software.

Por exemplo: um analista de negócios pode adicionar um bug em uma especificação de requisitos. Bugs em especificações de requisitos e especificação de modelagem (e código, no caso) são normalmente detectados por revisões.

Quando um bug é detectado por uma revisão (ou por análise estática), note que é o bug que está sendo realmente detectado; o software não está sendo executado, portanto nenhuma falha ocorre.

3 – Algumas pessoas usam a palavra omissão ao invés de bug ou defeito.

Eu não gosto desse termo, e evito-o. Quando eu falo a respeito de uma omissão, talvez isso possa parecer que estou falando a respeito de algo que é resultante da culpa de alguém; e implicações de culpa podem ocorrer.

Bugs acontecem por várias razões, e responsabilização individual não está no topo da lista. Nós devemos ver os bugs (e relatórios de bugs) como uma maneira de entender a capacidade de qualidade do processo de software, e não como uma forma de endereçar culpas.

Então, de volta ao ponto central de Rodrigo: “Realmente é importante a forma como nós chamamos o relatório?”

Se você quiser ter 100% de segurança em sua terminologia, então relatório de incidente é provavelmente o melhor nome. Entretanto, eu acho que relatório de falha também é um bom termo.

Eu também penso que, considerando a larga utilização de tais termos, relatório de defeitos e relatório de bugs também são aceitáveis. Porém, quando utilizamos os termos relatório de bug e relatório de defeitos, é importante que as pessoas tenham em mente a sequência de eventos que apontei acima, e que o relatório na verdade descreve o sintoma de um bug, e não o bug em si.

Gostou do conteúdo? Continue acompanhando nosso blog para mais assuntos correlatos. Você também pode conhecer um pouco mais sobre a RSI, acessando o nosso site!

Leia também: Banco como Plataforma (BaaP), IA e Transformação Digital.


Compartilhar Com
Conteúdos que você pode se interessar

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *