4. Técnicas de Modelagem de Testes - O que é análise de Teste? Ou como identificar as condições para o Teste?

Análise de Teste: Identificando condições para teste
A análise do teste é o processo que procura por algo que possa ser convertido em informações para teste. Também é chamada de Base do Teste.

• A base do teste é a informação necessária para começar a análise do teste e criar nossos próprios casos de teste. É uma documentação na qual casos de teste são baseados, tais como requisitos, especificações de projeto, análises de risco de produto, arquitetura e interfaces com o usuário.
• Podemos utilizar os documentos da base de teste para compreender o que o sistema fará quando for construído. Em alguns casos, os testes pode se basear no conhecimento que o usuário tem do sistema e isso pode não estar documentado.
• Da perspectiva do teste, nós olhamos a base de testes para ver o que pode ser testado. Essas são as condições de teste.  Uma condição de teste é algo que nós podemos testar.
• Enquanto identificamos as condições de teste ideal dentro das muitas condições que temos e então selecionar quais delas serão realmente úteis em nossos casos de testes, a isso chamados de possibilidade de teste.
• Como já é sabido, testar tudo no sistema é impraticável, tal procedimento é chama-se teste exaustivo. Devemos escolher apenas um conjunto dos testes possíveis. Na prática, tal conjunto pode ser pequeno diante do tamanho sistema, porém, ele tem uma grande probabilidade de encontrar a maioria dos defeitos.
• Precisamos de muita inteligência no processo para organizar nosso conjunto e a essa inteligência damos o nome de técnicas de teste. As condições para teste que foram escolhidas, vão depender da estratégia de teste ou de uma abordagem de teste mais detalhada. Por exemplo, precisam ser baseados no risco, modelos de sistema e etc.
• Uma vez identificada a lista de condições para o teste, é muito importante priorizá-los, então a condições mais importante será identificada. Tais condições podem ser identificadas por dados de testes bem como para entradas e para saídas, por exemplo diferentes tipos de registros, diferentes tamanhos de registros ou campos em um registro. As condições de teste estão documentadas na IEEE 829 que se chama "Especificação de Modelagem para Testes".

Fonte: ISTQB

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