Para que um produto de software receba uma cobertura de testes satisfatória, de forma a encontrar a maior quantidade possível de defeitos, faz-se necessário a adoção de um processo de testes para padronizar os trabalhos e ampliar a organização e controle dos projetos de testes. Este processo integra métodos de projeto de casos de teste em uma série bem planejada de passos, que resultam na construção bem-sucedida de software. O processo fornece um roteiro que descreve os passos a serem conduzidos como parte do teste, quando esses passos são planejados e depois executados, quanto de esforço, tempo e recursos serão necessários. Assim, qualquer processo de teste deve incorporar planejamento de teste, projeto de casos de teste, execução dos casos de teste e a resultante coleta e avaliação de dados (PRESSMAN, 2006).
Para Bartié (2002), a etapa de planejamento dos testes caracteriza-se pela definição de uma proposta de testes baseada nas expectativas do cliente em relação à prazos, custos e qualidade esperada, possibilitando dimensionar a equipe e estabelecer um esforço de acordo com as necessidades apontadas pelo cliente. Tal planejamento pode ser composto de muitas atividades, mas, basicamente, consideram-se as seguintes:
Estudo do projeto: o projeto deve ser estudado a fim de verificar os requisitos ou as possíveis modificações de requisitos ou arquitetura do software. Estudam-se as lições aprendidas dos projetos de testes anteriores, as expectativas de custos, prazos e os riscos envolvidos no projeto e seus impactos.
Avaliação de impacto: avalia-se a necessidade de criar ou modificar casos de teste. Se houverem casos de teste automatizados, deve ser verificado se existe a necessidade de adequar o código e ferramentas ou até mesmo adquirir novas ferramentas.
Análise de esforço interno e externo: estima-se o esforço interno para condução das atividades. Métricas de projetos anteriores podem ser avaliadas para auxiliar na elaboração das estimativas. Se houver necessidade de terceirar parte do serviço, faz-se necessário avaliar a disponibilidade de espaço físico e infraestrutura e especificar as métricas de qualidade e produtividade esperadas.
Definição de cenários possíveis: avalia-se a lista de projetos de teste em andamento e a serem iniciados com o objetivo de verificar a disponibilidade de recursos internos para alocação no projeto.
Após isto, a proposta será enviada para aprovação pelo cliente interno ou externo.
Aprovação do planejamento: com a aprovação da proposta apresentada, o planejamento pode ser divulgado aos colaboradores internos ou externos.
Normalmente, os papéis envolvidos no planejamento dos testes são Coordenador de Testes, Líder de Testes e Arquiteto de Testes (BARTIÉ, 2002).
Craig e Jaskiel (2002) acreditam que o planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software.
Dessa forma, o planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja:
1. Inicialmente é planejado o Teste de Aceitação a partir do documento de requisitos;
2. Após isso é planejado o Teste de Sistema a partir do projeto de alto nível do software;
3. Em seguida ocorre o planejamento dos Testes de Integração a partir do projeto detalhado; e 4. Por fim, o planejamento dos testes a partir da codificação.
Já a execução ocorre no sentido inverso, como pode ser observado na Figura 6.
Figura 6. Modelo V: paralelismo entre as atividades de desenvolvimento e teste de software.
Fonte: Craig e Jaskiel (2002).
A visão de Myers, Badgett e Sandler (2011) quanto ao planejamento dos testes é semelhante, com exceção da adição de outras duas etapas: Teste de Função, que está relacionado a etapa do processo de design de Especificação Externa e o Teste de Instalação, que não está associado a nenhuma das etapas do processo de design, pois seu objetivo não é o de encontrar erros do software e sim os possíveis erros que podem ocorrer durante o processo de instalação do software.
Concluído o planejamento, a próxima etapa é a Especificação dos Testes. Nesta etapa são identificados os casos de teste que deverão ser construídos ou modificados com base nos requisitos do software. Nesta etapa é realizada a análise dos novos requisitos ou modificação dos existentes, juntamente com os casos de uso, com o objetivo de garantir que todos serão cobertos por casos de teste (BARTIÉ, 2002).
Caso de teste: um caso de teste descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.
Procedimento de teste: um caso de teste ou um grupo de casos de teste pode requerer um procedimento de teste que descreva os passos necessários para executá-los (CRAIG & JASKIEL, 2002).
Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001). Os critérios de teste podem ser utilizados como;
Critério de Cobertura dos testes: permitem a identificação de partes do software que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS & WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.
Critério de Adequação de Casos de Teste: quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério.
Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001).
Critério de Geração de Casos de teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001).
Especifica-se, caso necessário, a adequação das ferramentas existentes ou novas ferramentas e códigos de testes automatizados. Analistas de teste avaliam o nível de cobertura alcançado pelos casos de teste e sugerem melhorias até que seja alcançado um patamar satisfatório. Os papéis envolvidos nesta etapa normalmente são Coordenador de Testes, Líder de Testes, Analista de Testes, Arquiteto de Testes e Automatizador de Testes (BARTIÉ, 2002).
O projeto dos casos de teste é a chave para um teste bem-sucedido. Se os casos de teste não forem representativos e não envolverem todas as possibilidades de exercício das funções que demonstram a correção e a validade do sistema, então, o restante do processo de testes é inútil.
Portanto, a execução de um teste começa com a revisão dos casos de teste, a fim de verificar se estão corretos, se são viáveis, se fornecem o grau desejado de cobertura e se demonstram a funcionalidade pretendida. Uma vez que essas verificações tenham sido feitas, pode-se realmente executar os testes (PFLEEGER, 2004).
A etapa seguinte é a de execução dos casos de teste com o objetivo de conferir os testes planejados, de forma a garantir que o comportamento do aplicativo permanece em conformidade com os requisitos contratados pelo cliente. Cada defeito descoberto durante os testes deve ser documentado para ajudar no registro desses defeitos. Um relato de problema é gerado quando um procedimento de teste dá origem a um evento que não pode ser explicado pelo testador. O relato do problema documenta os detalhes do evento e inclui, pelo menos, esses itens: Identificação do problema; Autor;
Versão da Release/Build; Data de abertura; Data de encerramento; Área do problema; Defeito ou melhoria; Ambiente de teste; Tipo de defeito; Quem detectou; Como detectou; Atribuído à; Prioridade;
Severidade; Estado (BARTIÉ, 2002).