Qual o significado de Defeito, Bug ou Erro e Falhas em Teste de Software?

Um regrinha rápida para compreender:

1) Erro é cometido por um ser humano

2) um Defeito é gerado no Sistema, quando programado de forma errada.

3) Falha é o que é retornado para o usuário através de um aviso na tela.

4) Bug é quando uma grande quantidade de erros, defeitos ou falhas são encontrados no Software. 

Para evitar essa dor de cabeça quando o seu Produto de Software for entregue, é muito útil que se use o Teste de Software, como já dissemos, durante todo o seu ALM.
Agora, vamos de definição.

Definição:

• Um defeito é um erro ou um bug, dentro da aplicação quando ela é criada. Um desenvolvedor quando está modelando e construindo o Sistema, pode cometer enganos ou erro. Esses enganos ou erros significam que existem falhas no Sistema, tais falhas são chamadas de defeitos.
• Quando o resultado atual desvia do resultado esperado durante os testes então isso é um defeito. Consequentemente, qualquer desvio da especificação mencionado no Documento de Especificação funcional do produto é considerado um defeto. Em empresas diferentes isso é frequentemente chamado de bug, issue, problema ou incidente.
• Quando a Produto final não supre a expectativa do usuario final ou não respeita os Requistos Modelados, então isso resultado em um Bug ou Defeito. Esses defeitos, ou bug, ocorrem porque houve um erro de lógica ou erro no código que resulta em uma falha ou resultado imprevisivel ou imprevisto.

Informações adicionais sobre Defeitos/Bugs:

Quando uma aplicação ou um Produto de Software é testado, se um grande número de defeitos são encontrados então ela é considerada "Bugada" ou que contém um "Bug".

Quando um testador encontra um Bug ou um Defeito,é necessário informar sobre os mesmos com os desenvolvedores. Para tal, ele coloca tais defeitos em um Relatório detalhando os passos efetuados até chegar no defeito encontrado, esse Relatório tem vários nomes: Relatório de Bugs, Relatório de Issues, Relatório de Defeitos, Relatório de Problemas e etc.

Este Relatório consiste, basicamente, em conter a seguinte informação:

• ID do Defeito – Todo Bug ou Defeito tem um número de identificação único.
• Descrição do Defeito – A explicação sobre o que foi encontrado.
• Versão do Produto – A versão do Produto, aplicação, no qual o defeito é encontrado.
• Detalhes Passo a passo – Os passos detalhados do problema com prints de tela anexados para que os desenvolvedores possam simular o mesmo em seu ambiente.
• Data do Ocorrido – A data de quando o Bug foi encontrado e relatado.
• Reportado Por – As informações do Testador que encontrou e reportou o Problema, tais como o nome e o Id do Testador.
• Estado – O Estado do defeito como: Novo, Encaminhado à alguém, Aberto, Retestado, Verificação, Fechado, Falho, Igorado ou Deferred e etc.
• Corrigido por – Os detalhes do desenvolvedor que corrigiu o defeito como Id e Nome do Desenvolvedor.
• Data de Finalização – A data em que o defeito foi resolvido e a entrada finalizada.
• Severidade – Baseado na severidade (Crítica, Principal, Menor), nos diz sobre o impacto do defeito ou bug na aplicação.
• Prioridade – Baseado em um conjunto de prioridades (Alta, Média, Baixa), a ordem de corrigir o defeito pode ser dada.

Fonte: ISTQB

1. Fundamentos de Teste - 1. O que é Teste?

Teste de software é o processo de executar uma aplicação com a intenção de encontrar bugs. Também pode ser definido como o processo de validação e verificação feito em um software:

• Atende aos requisitos técnicos e de negócios que orientaram seu design e desenvolvimento.
• Trabalha como esperado.

• Pode ser implementado com características similares.

Colocando uma Máquina de Raios-X sobre a definição de Teste de Software, a vemos em partes, como já dizia Jack:

1)  Processo:  Testar é um processo, e esse processo é melhor do que uma atividade única, ou fazer algo de uma única vez e validar no final.

2)  Ativo em todo o Ciclo de Vida: Teste é um processo que é executado durante todo o Ciclo de Vida da Aplicação (ALM).

• O processo de modelagem dos testes, desde o inicio e durante o ciclo de vida, pode ajudar a prevenir defeitos antes que estes sejam introduzidos no código. Algumas vezes é definido como “verificação da base de testes de acordo com a modelagem do Sistema.”

• A Base de Testes inclui documentos, tais como as especificações de Requisitos e de Modelagem da aplicação.

 3)  Teste Estático: Quando executado, pode encontrar defeitos sem precisar executar o código. O Teste Estático inclui revisão de documentos (incluindo código fonte da aplicação) e análise estática de código. É um teste útil e barato. Esse tipo de teste é muito executado pelas IDEs modernas como Visual Studio, Eclipse, NetBeans e afins, para ver na prática, basta errar alguma palavra reservada da linguagem  ou algum comando que a IDE vai sublinhar o erro e com isso evitando que a aplicação seja montada e executada até que o erro seja corrigido.

4)  Teste Dinâmico: Em um teste dinâmico, o código fonte que precisamos testar é executado, ou "rodado", para demonstrar como ele responde. É feito durante o processo de validação. Exemplos de testes dinâmicos: teste unitário, teste de integração, teste de sistema e etc.

 5)  Planejamento:  Precisamos planejar o que queremos fazer. Controlando as atividades do teste, informando o progresso do teste e o estado do sistema durante os testes, ou seja, como o sistema responde durante essa tarefa, é muito importante anotar tudo o que se encontra e depois fazer uma reunião para selecionar que informação realmente importa ou não.

6)  Preparação:  Precisamos escolher qual tipo de teste faremos, escolhendo as condições para teste e modelando os casos de teste.

7)  Avaliação: Durante a avaliação, precisamos checar os resultados e avaliar o software sob nossa responsabilidade e os critérios de compleição, critério de "passou", "falhou" ou "inconclusivo", que nos ajuda a decidir quando terminar de testar e se o produto passou nos testes propostos.

8)  Produtos de Software e artefatos de resultado gerados:  Junto com o teste de código, os testes de Requisitos e as especificações de modelagem e outros documentos relacionados ao usuário, materiais de treinamento são muito importantes.

Fonte: ISTQB