Estimativa de Teste utilizando uma Matriz de Teste por Tipo de Funcionalidade

Um assunto que está sendo muito discutido na nossa área de teste atualmente é Estimativa de Esforço de Teste. Essa fase do projeto de teste é muito importante e devemos dar atenção especial para ela, afinal, a estimativa deve ser a mais confiável possível. Devemos tomar muito cuidado com o que é, ou foi estimado, pois a maioria dos Gerentes de Projeto quer que você assine essa estimativa com “sangue” e com certeza irão lembrar-se de você caso o valor realizado seja totalmente diferente do estimado, ou seja, o valor planejado deve ser o mais próximo possível do valor realizado.

O que geralmente acontece é o seguinte: Um analista de teste precisa analisar e estimar os casos de testes que serão desenvolvidos para testar um software. Na maioria das vezes as estimativas não usam qualquer técnica, não são comuns em toda organização e, o que é pior, elas não garantem que a cobertura de testes está validando todos os requisitos.

O objetivo deste artigo é mostrar uma maneira fácil, simples e eficaz de estimar o esforço de teste utilizando uma Matriz de Teste por Tipo de Funcionalidade e o que é mais importante, documentar o “estimado”.

Para que a estimativa de esforço e custo de teste seja feita da maneira mais cuidadosa possível, deve-se levar em consideração algumas atividades para isso, como por exemplo:

• Determinar e manter as estimativas dos produtos de trabalho e tarefas de teste;
• Estudar os fatores que possam influenciar a estimativa;
• Selecionar modelos e/ou dados históricos que servirão para transformar os produtos de trabalho e tarefas de teste em estimativas de esforço e custo;
• Incluir as necessidades de infra-estrutura;
• Documentar os riscos resultantes da análise dos documentos;
• Documentar os dados da estimativa, incluindo as informações necessárias para a reutilização em novas estimativas.

Um “modelo” muito utilizado nas empresas para realizar as estimativas é a intuição e julgamento de um especialista baseados na experiência em planejar e testar sistemas semelhantes. Dessa forma, a precisão da estimativa depende da experiência, competência, objetividade e percepção de quem realiza a estimativa.

Os produtos de trabalhos gerados na fase de estimativa são os critérios de entrada para a fase de planejamento onde é verificado o esforço e custo do projeto incluindo a disponibilidade de recurso, infra-estrutura, negociação com o time de desenvolvimento, etc. Para facilitar essa interação entre a fase de estimativa e planejamento devemos documentar tudo o que foi analisado e estimado. Abaixo seguem alguns itens que podem ser documentados na estimativa de esforço:

• Documentos usados para estimar: Nome e versão dos documentos utilizados durante a estimativa;
• Data: Data quando a estimativa foi completada;
• Data da Requisição: Data quando a estimativa foi solicitada;
• Responsável: Pessoa que fez a estimativa, podendo haver mais de uma pessoa responsável;
• Esforço Atual da Estimativa: Esforço gasto na estimativa;
• Complexidade: Indica se a funcionalidade tem uma complexidade baixa, média ou alta para testar. Considerar quantidade de suporte de teste requerido, riscos e desafios;
• Razão para complexidade: indicar o porquê a funcionalidade foi marcada com a dada complexidade;
• Análise de Teste
• => Requisitos Funcionais: Número de requisitos funcionais aplicáveis;
• => Requisitos de Interface: Número de requisitos de interface aplicáveis;
• => Casos de Teste: Número de Casos de Teste estimado;
• => Premissas: Premissas identificadas para fase de design;
• => Esforço Calculado: Esforço de análise calculado baseado no número de casos de teste estimado;
• => Esforço Calculado para Revisão: Esforço da revisão dos casos de teste sugeridos na fase de análise.
• Design de Teste
• => Casos de Teste: Número de Novos Casos de Teste;
• => Casos de Teste Reutilizados: Número de Casos de Teste Reutilizados (nenhum esforço de design requerido);
• => Premissas: Premissas identificadas para fase de execução;
• => Esforço Calculado: Esforço de design calculado baseado no número de casos de teste a serem criados;
• => Esforço Calculado para Revisão: Esforço da revisão dos casos de teste criados na fase de design.
• Execução de Teste
• => Casos de Teste: Número de Casos de Teste que serão executados para a funcionalidade incluindo testes de regressão;
• => Total de Casos de Teste: Número Total de Casos de Teste que serão executados incluindo a porcentagem de casos de testes falhados e bloqueados para todos os ciclos de execução;
• => Premissas: Premissas identificadas para fase de execução. Podendo conter também indicações sobre casos de teste adicionais de regressão ou reuso, porcentagem de defeitos encontrados, porcentagem de re-execução de casos de teste passados;
• => Esforço Calculado: Esforço de execução calculado baseado no número de casos de teste a serem executados.
• Otimista: Valor otimista da estimativa gerada;
• Mais provável: Valor mais provável da estimativa gerada;
• Pessimista: Valor pessimista da estimativa gerada.

Para ajudar a calcular o valor otimista, mais provável e pessimista, pode-se usar a simulação de Monte Carlo. Uma boa prática para ajudar o trabalho de estimativa de teste é utilizar um mapa da mente, por exemplo, usar o software Free Mind.

Bem, agora que já vimos uma maneira fácil e simples de documentar tudo o que foi estimado, chegou o momento de verificar o que é essa tal Matriz de Teste por Tipo de Funcionalidade. Será que essa matriz é um bicho de 7 cabeças? Claro que não, é uma das coisas mais simples que já desenvolvi e que ajudam muito na hora de fazer uma estimativa de teste.

Quem aqui já precisou fazer uma estimativa para um novo projeto e teve aquela leve impressão de já ter feito uma estimativa anterior para uma mesma funcionalidade que está prevista para o novo projeto? Aquela funcionalidade de leitura de arquivo TXT ou XLS, validação de campos de formulários, realizar operações em Banco de Dados, etc.

Se você já passou por isso, com certeza chegou a hora de criar uma Matriz de Teste por Tipo de Funcionalidade para você nunca mais ficar perdendo tempo na hora de estimar e deixar de identificar casos de teste já identificados anteriormente em projetos anteriores. Essa matriz é uma base de conhecimento onde documentamos todos os testes/cenários necessários para testar um determinado tipo de funcionalidade. Neste momento, você deve estar pensando “Esse cara é maluco, é só isso mesmo?”. A resposta é mais simples ainda... quer dizer, me deixa pensar um pouco... continuo pensando... Ah, já sei... SIM, é só isso mesmo :-) . Segue abaixo um exemplo de uma Matriz de Teste por Tipo de Funcionalidade.

No nosso exemplo usaremos os seguintes campos na nossa Matriz:

• Telas / Funcionalidade
• Testes - Características
• Testes – Sub-características
• Categorias do TesteTipo de Teste

Para ajudar a analisar a matriz, é uma boa prática criar um gráfico, pois assim ficará fácil identificar a quantidade de testes para cada funcionalidade. Abaixo temos a consolidação dos dados (utilizei a Pivot Table do Microsoft Excel para gerar a tabela de dados) e o gráfico gerado para este exemplo.

Depois de ter a primeira versão da Matriz criada é só ir adicionando, modificando os testes/cenários por funcionalidade. Simples assim !!! ;-) Agora você sempre terá uma base de dados histórica de testes por funcionalidade e com certeza não se esquecerá de estimar um determinado teste que já foi desenvolvido em projetos anteriores.

Bem, então, caso o gerente do projeto de teste que você trabalha chegasse para você e pedisse uma nova estimativa de esforço de teste para um novo projeto, qual seria o seu primeiro passo? Pensando... pensando... pensando... cri... cri... cri... cri.. nossa quantos grilos... isso mesmo, analisar a Matriz de Teste por Tipo de Funcionalidade para saber se já existe uma funcionalidade que foi testada anteriormente em outro projeto e que será desenvolvida ou alterada no novo projeto!

Espero que tenham gostado!

Até+,

Quezada