PROCESSOS, FERRAMENTAS E EQUIPES PARA REALIZAÇÃO DE ATIVIDADES DE TESTE.

Muitos gerentes ainda consideram que a atividade de testes resume-se apenas à execução de testes. No entanto, um processo efetivo de testes envolve diversas outras atividades que devem ser consideradas. A lista abaixo apresenta as atividades de teste mais comuns [4]:

• Planejamento das atividades de teste, coordenação do pessoal envolvido e controle dos equipamentos necessários;

• Configuração do ambiente de testes a ser utilizado;

• Geração de casos de teste de acordo com os níveis de testes a serem realizados;

• Execução de testes;

• Avaliação de resultados de testes para determinar se os mesmos foram realizados com sucesso;

• Acompanhamento de defeitos, identificando quando e onde as falhas foram introduzidas no sistema. Estas informações servem como entrada para a melhoria dos processos de desenvolvimento e de testes.

A adoção de ferramentas para dar suporte ao processo também é fundamental na implementação de um processo efetivo de testes. As ferramentas de teste são categorizadas de acordo com seu objetivo dentro do processo de testes [4]:

• Geração de teste: os geradores de teste auxiliam no desenvolvimento de casos de teste;

• Execução de testes: os frameworks de execução de testes dão suporte à execução de casos de testes de maneira controlada;

• Avaliação de testes: estas ferramentas dão suporte à avaliação dos resultados de teste;

• Gerenciamento de testes: ferramentas que fornecem o suporte para o gerenciamento de todos os aspectos do processo de testes;

• Análise de desempenho: ferramentas para medida e análise do desempenho de software.

Gelpering e Hetzel [14] citam os principais modelos de teste e os classificam em modelos de fase e modelos de ciclo de vida, conforme a Tabela 3:

Tipo do modelo Modelo Objetivo Principal

Demonstração Assegurar que o software satisfaz as especificações

Modelo de Fase

Destruição Detectar falhas de implementação Avaliação Detectar falhas de requisitos,

design e implementação. Modelo de Ciclo de Vida

Prevenção Prevenir falhas de requisitos, design e implementação.

Os modelos de fase têm como foco a execução de testes e, segundo Gelpering e Hetzel, são embasados pela visão errônea e ainda remanescente, criada pela ampla utilização de termos como “test execution” e “code and test”, de que teste é uma fase do ciclo de vida do desenvolvimento realizada apenas na reta final do projeto. Contrapondo esta visão, os modelos de ciclo de vida deslocam o começo das atividades de teste do final para o início do projeto, resultando na visão que teste não é uma fase seqüencial, que impacta apenas a implementação de código, mas uma atividade que dá suporte a todo o ciclo de desenvolvimento de software. A adoção de modelos de teste de ciclo de vida e o aumento da complexidade das aplicações contribuíram para a formação de equipes com foco nas atividades de teste.

Por muito tempo as atividades de testes foram realizadas pelo pessoal da equipe de desenvolvimento que estivesse disponível no momento. Os sistemas, implementados em computadores de grande porte, de forma centralizada, e com poucos recursos computacionais, demandavam uma atividade menos intensa de teste. No entanto, a evolução da tecnologia e o surgimento de aplicações distribuídas, arquiteturas complexas e interfaces gráficas altamente poderosas levaram a um considerável aumento da complexidade e do esforço dos testes. Tornou-se necessário o uso de ferramentas de teste e de atividades mais aprofundadas de planejamento, design e implementação de testes, fazendo com que as organizações alocassem nos projetos pessoas totalmente direcionadas para as atividades de teste.

Os integrantes da equipe alocados para atividades de teste devem ser adequadamente capacitados para que o processo de testes tenha uma boa relação custo x benefício. Hutcheson [44] reporta um estudo de caso realizado onde um grupo de testadores treinados, usando métodos e métricas, encontrou defeitos a uma taxa de 2 ou 3 por hora, enquanto testadores não treinados e que não utilizaram métodos e métricas encontraram 3 defeitos por dia nas mesmas aplicações. Além disso, 90% dos defeitos reportados pelo grupo de testadores treinados eram válidos enquanto cerca de metade dos problemas reportados pelo outro grupo de testadores não eram reproduzíveis. Neste estudo o custo dos testadores treinados era quase o dobro do custo dos testadores não treinados e, mesmo assim, o custo médio para a detecção de um problema no grupo não treinado foi de $50, enquanto no grupo treinado foi de $13, compensando o investimento em treinamentos, métodos e métricas.

A criação de equipes independentes de teste tem sido usada por organizações no intuito de melhorar seu processo de testes de software e, conseqüentemente, a qualidade do software produzido. Pesquisas realizadas pelo Software Testing Institute [45] no ano de 2002 revelam que há uma tendência para que as empresas trabalhem com equipes de teste centralizadas (45,24%) ao invés de utilizarem equipes de teste temporárias que são formadas e dissolvidas em função dos projetos. A adoção de equipes centralizadas requer, certamente, um investimento maior e uma maior necessidade de gerência dos testadores alocados nos projetos, o que pode ser encarado como uma desvantagem deste tipo de estrutura ou como um investimento, a depender dos objetivos da organização.

Em organizações onde os times de teste são temporários e distribuídos entre os projetos, o conhecimento adquirido tende a se perder com o término do projeto se os testadores forem dispensados. O uso de equipes centralizadas de teste estimula a criação de perfis para atividades de teste, o desenvolvimento de carreiras na área de testes e a manutenção do conhecimento adquirido em planejamento, desenvolvimento e execução de testes, processos, metodologias e ferramentas.

2.5 Considerações Finais

Este capítulo forneceu uma visão geral sobre a atividade de testes e dos principais tipos e técnicas de teste.

Diversas técnicas de teste podem ser utilizadas em cada um dos níveis de teste. No entanto as técnicas de caixa branca normalmente são utilizadas em testes unitários, pois exigem conhecimento do código além de demandar, muitas vezes, recursos computacionais para sua viabilidade. As técnicas de caixa preta são mais difundidas e utilizadas por se tratarem de técnicas que podem ser aplicadas nos diversos níveis e utilizadas tanto pela própria equipe de desenvolvimento como também por equipes independentes de teste.

As organizações independentes de teste, normalmente, utilizam as técnicas de caixa preta por não demandar conhecimento do código e pelo fato de que as mesmas focam no comportamento e na adequação da aplicação aos requisitos do usuário. A técnica de testes de regressão é amplamente utilizada, pois se adapta bem a qualquer processo de desenvolvimento e é importante para a garantia da qualidade quando da manutenção das aplicações, uma vez que verifica se novos defeitos não foram inseridos em áreas já consolidadas do software.