De BISAWiki

Edição atual tal como 13h58min de 30 de abril de 2013

Objetivo

O objetivo deste Guia é apresentar os principais conceitos utilizados na disciplina de teste de software e principalmente como serão desenvolvidas as atividades de teste na empresa BisaWeb abordando técnicas a serem utilizadas durante a sua execução. Seu objetivo é reunir todas as informações necessárias para o planejamento e controle do teste.

Conceitos Básicos

Os principais conceitos da disciplina de teste de software, com o intuito de mostrar onde está baseado o processo da BisaWeb, são apresentados a seguir.

Processo de Teste

O processo de teste pode ser entendido como uma sequência de atividades executada para alcançar um objetivo específico que representa uma estruturação de fases, atividades, artefatos, papéis e responsabilidades que tem o objetivo de padronizar os trabalhos, além de maximizar a organização e monitoramento dos projetos de testes. Portanto, o objetivo do processo de teste é fornecer informação para garantir a qualidade do produto, decisões e processos para uma atividade de teste. Além disso, o processo de teste busca garantir que nenhum passo crítico do processo seja esquecido, ou seja, que todas as atividades sejam realizadas na ordem correta.

Estratégia de Teste

Uma estratégia para o teste de um projeto descreve a abordagem geral e os objetivos das atividades de teste. Ela inclui os estágios de teste (unidade, integração e sistema) que devem ser abordados e os tipos de teste (de função, desempenho, carga, stress, etc.) e técnicas que devem ser executados.

A estratégia define:

• As ferramentas e técnicas de teste a serem empregadas.
• Os critérios de início, suspensão, reinício, conclusão e êxito do teste a serem usados.
• É necessário planejar as atividades de teste com base nas seguintes dimensões:
  • Em que sprint você se encontra e quais são as metas dessa sprint.
  • Que estágio de teste (teste unitário, de integração ou de sistema) está sendo executando. A equipe de teste pode trabalhar todos os estágios de teste em uma Sprint se for necessário.

São importantes para definir a estratégia de teste:

• Tipos de teste (de função, stress, volume, desempenho, usabilidade, distribuição, etc.).
• Critérios de avaliação usados (cobertura de teste baseada em código, cobertura de teste baseada em requisitos, número de defeitos, intervalo entre falhas, etc.)
• Técnicas de teste usadas (manuais e automatizadas)

Não há nenhum padrão geral referente à maneira como os tipos de testes são distribuídos nos ciclos de teste. Dependendo do número de sprints, do tamanho da sprint e do tipo de projeto, a equipe de teste enfatizará diferentes tipos de testes.

A equipe de teste perceberá que o foco do estágio de teste do sistema é garantir que esteja cobrindo todos os requisitos testáveis expressos em um conjunto de casos de teste. Isso significa que os critérios de conclusão se concentrarão na cobertura de teste baseada em requisitos. Nos estágios de teste unitário e de integração, a equipe ainda perceberá que a cobertura de teste baseada em código é um critério de conclusão mais apropriado.

Vertentes de Teste

No contexto do teste de software, é necessário ter a correta compreensão dos três pilares que dão sustentação a todo processo (Ver Figura 1). Eles são a base para o entendimento conceitual, adaptação prática e elaboração efetiva do planejamento do teste em um projeto. Nesse âmbito, os estágios ou níveis de teste abrangem o escopo de quando o teste será realizado. Já a vertente de tipos de teste compreende categorias de teste associadas a partir de um objetivo comum. Por sua vez, as técnicas de teste tratam formas para realizar um projeto de casos de teste.

Estágios de Teste

Os estágios de teste fornecem a indicação sobre o foco do teste e os tipos de problemas a serem encontrados, dependendo do nível em que o teste será realizado. O teste pode ser dividido em: unitário, sistema, integração e, por fim, aceitação. (Para descrição de cada um desses níveis, verificar Estágios dos Testes na BisaWeb)

Quando o teste é realizado no momento da codificação e desenvolvimento do sistema, consideramos o nível de teste unitário. Já, quando o teste é realizado no momento da integração de componentes previamente desenvolvidos, estamos falando do teste de integração.

Após o desenvolvimento do sistema, no momento em que os analistas de teste validam o produto com base nos requisitos, podemos considerar que estamos tratando de teste de sistema. Já no ambiente de produção, considera-se teste de aceitação aquele que é realizado pelo usuário da aplicação ou por terceiros designados, cujo objetivo é de aprovar ou não o software.

Tipos de Testes de Software

Os tipos de teste são definidos de acordo com o nível em que o teste será realizado e também com base nos objetivos de cada um dos níveis de teste. Eles estão organizados em categorias: (i) funcional, (ii) não funcional e (iii) estrutural, conforme descritos a seguir:

Funcional

O teste funcional é utilizado quando o objetivo é verificar se as especificações foram atendidas, ou seja, o foco do teste funcional são os requisitos funcionais do sistema.

Não Funcional

Testes não funcionais incluem, mas não se limitam a: teste de performance; teste de carga; teste de estresse; teste de usabilidade; teste de interoperabilidade; teste de manutenibilidade; teste de confiabilidade e teste de portabilidade. É o teste de “como” o sistema trabalha.

Estrutural

A técnica de teste estrutural é mais conhecida como teste caixa branca. O teste estrutural tem como base o conhecimento da estrutura interna da codificação.

Portanto, o teste estrutural é baseado no código escrito para implementar um componente ou sistema.

Técnicas de Testes de Software

As categorias de técnicas para projeto de teste podem ser baseadas na estrutura ( caixa branca) ou em técnicas baseada na especificação (caixa preta). Técnicas baseadas na experiência utilizam o conhecimento, habilidades e experiência das pessoas, sejam elas técnicas ou de negócio.

As principais técnicas são:

Técnicas baseada em especificação

• Partição por equivalência
• Análise de valor fronteira ou limite
• Tabela de decisão
• Diagrama de transição de estados
• Caso de uso

Técnicas baseada na estrutura

• Cobertura de declaração
• Cobertura de decisão

Técnica baseada na experiência

• Teste exploratório

O Processo de Teste de Software na Empresa BisaWeb

Fluxo de Teste

O fluxo de teste descreve as tarefas realizadas no processo de teste da BisaWeb. O Gerente de Configuração gera o build para teste que é recebido pelo analista que por sua vez, cria os casos de teste ou executa testes exploratórios. Se a versão beta do sistema apresenta falhas, a requisição que impactou negativamente no sistema é atribuída a um desenvolvedor para que os erros encontrados sejam corrigidos.
O detalhamento do processo de execução do teste da BisaWeb pode ser encontrado aqui.

Estágios dos testes

Na BisaWeb, testes de unidade e integração são realizados pelo desenvolvedor no instante em que concluem uma determinada requisição. No teste de unidade, o desenvolvedor verifica se a funcionalidade desenvolvida por ele está de acordo com o requisito. Já no teste de integração, o desenvolvedor verifica o impacto da funcionalidade, que acabou de desenvolver, integrada a um determinado componente do sistema a qual essa funcionalidade faz parte.
Num segundo estágio, o testador realiza testes de sistema, verificando a estabilidade do sistema após ser gerada uma versão de testes (beta). Caso o cliente sinta a necessidade de testar o sistema, no instante da implantação da versão no cliente, o mesmo realiza testes de aceitação observando se a funcionalidade está cumprindo com o que foi pedido por ele.
Os estágios de teste em seus diversos níveis são aplicados na BisaWeb, conforme apresentado no diagrama de Estágios de Testes da BisaWeb.

Critérios do Projeto de Teste

Os critérios projeto de teste adotados pela BisaWeb, são: entrada, saída, suspensão e reinício. Eles acontecem conforme detalhado na tabela abaixo.

Padrões de documentação

Criação da suite de teste

A criação da suite de teste segue a seguinte estrutura:

Campo <Nome da suíte de Teste>

Na suite de teste principal deve-se colocar o nome da rotina do sistema, ao qual deseja-se fazer relação a requisição que vai ser criado o caso de teste.

Na suíte secundaria deve-se ser colocado o nome do módulo ao qual a requisição pertence.

Detalhes: Uma breve descrição sobre a suite que está se criando, por exemplo se a suite for referente a rotina deve-se explicar a rotina, se for referente ao modulo deve-se explicar o modulo

Palavras chaves

Quando for criada a suite principal deve-se criar pelo menos uma palavra chave associada a cada caso de teste.

Quando for criado o módulo deve-se criar uma palavra chave referente ao modulo.

Campos obrigatórios:

Campo <Título do Caso de Teste>

Neste campo deve conter o número do mantis e a descrição

Campo <Objetivo do Teste>

Descrever o objetivo do teste de forma bem clara para que for testar saber o que está testando e verificar se o resultado está de acordo com o esperado.

Campo <Pré-Condição>

Preencher com os dados necessários para a execução do CT

Campo <Pós-Condição>

Campo opcional.

Campo <Tipo de Execução>

Deve-se escolher entre as opções:

Manual - teste executado através dos casos de teste.

Automatizado - irá utilizar uma ferramenta para testes automatizados onde são criados scripts de teste.

Campo <Prioridade do Teste>

Deve-se escolher uma das opções: alto, médio ou baixo.

Campo <Palavras chaves>

Outras palavras chaves devem ser identificadas para apoio no reuso.

Definições para o resultado da execução do caso de teste

Bloqueado: O caso de teste será bloqueado quando o mesmo estiver desatualizado ou quando um passo não estiver bem descrito impossibilitando seguir para o passo seguinte.

Passou: Um caso de teste estará aprovado quando todos os passos forem executados sem falhas e sem bloqueios

Falhou: É dado como falha quando o resultado esperado de um passo está diferente do resultado da aplicação.

Reportando bugs

O erro deverá ser reportado ao desenvolvedor através do Mantis. O status do mantis é alterado para atribuído devolvendo o Mantis para o programador responsável pela requisição.

Campos obrigatórios do Mantis

Campo <Adicionar Anotação>

Nesse campo é descrito passo a passo como reproduzir o erro e qual o real resultado esperado da aplicação.

Campo <Carregar Arquivo>

Nesse campo são adicionadas imagens com o passo a passo reproduzindo o erro.