sexta-feira, 5 de junho de 2009

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

12 comentários:

  1. Olá Gustavo!!!
    Segue uma dúvida: na Matriz de Teste Por Funcionalidade, onde eu insiro o tempo gasto tanto para a criação deste teste quanto para a execução do mesmo?
    As informações de funcionalidades são colocadas genericamente na planilha para todos os projetos?
    E como, no modelo que você apresentou, é detemrinado o esforço de cada milestone de teste?

    Bom, por enquando são só estas duvidas... como tu ta vendo, esse assunto ainda é novo pra mim... :D

    Abração!

    ResponderExcluir
  2. Opa Elias, tudo beleza?

    Bem, vou tentar esclarecer suas dúvidas...
    Você pode adicionar uma coluna para o tempo gasto no design e na execução de cada caso de teste, desta forma, poderá facilitar o cálculo do esforço de teste. Eu particularmente prefiro ter toda essa parte de histórico de tempo do design e execução de teste separadamente por projeto, mas neste caso é a forma que eu acho melhor para se trabalhar. Adicionar as colunas para tempo na Matriz de Teste Por Funcionalidade também funciona muito bem.

    Todas as informações de testes x funcionalidades são colocadas genericamente na planilha para todos os projetos. A Idéia é ter uma determinada funcionalidade e seus respectivos testes que podem ser aplicados a qualquer projeto.

    Não sei se entendi bem a sua pergunta sobre milestone, mas ai vai... :-) Com essa Matriz você é capaz de identificar todos os testes x funcionalidades já existentes em seus projetos anteriores facilitando assim a fase de uma nova estimativa para um novo projeto. Neste caso, você terá a quantidade de casos de testes que serão necessários para o novo projeto e depois disso você pode identificar os seus milestones, por exemplo, teremos os seguintes milestones: Análise, Design e Execução de Teste. Vamos supor que identificamos 100 CTs para o projeto e através de dados históricos gastamos 10 Min/CT na fase de Análise, 15 Min/CT na fase de Design e 17 Min/CT na fase de Execução. Agora é só fazer as contas:

    Fase de Análise: 100 CTs * 10 Min = 16.66h
    Fase de Design: 100 CTs * 15 Min = 25h
    Fase de Execução : 130 CTs (considerando que teremos 30% de re-teste) * 17 Min = 36.83h
    Total de Esforço do Projeto de Teste = 16.66 + 25 + 36.83 = 78.49h

    Será que esclareceu??? Qualquer dúvida é só entrar em contato.

    Até+,
    Quezada

    ResponderExcluir
  3. Este comentário foi removido pelo autor.

    ResponderExcluir
  4. Oi Gustavo, tu podes dar uma revisada no teu link sobre monte carlo? Fui tentar abrir e nao funcionou.. Esses caracteres especiais não ajudam muito :)

    ResponderExcluir
  5. Olá Sarah, tudo bem?

    Acabei de atualizar o link, agora está funcionando !!
    O Elias tinha comentado isso também ontem mas só tive tempo de atualizar agora :-).

    Até+,
    Quezada

    ResponderExcluir
  6. Gostei muito do artigo Quezada, já utilizamos algo parecido alinhado com a complexidade dos casos de uso e também às plataformas altas e baixas existentes nos projetos da empresa.
    Como sabemos uma especificação de uma determinada rotina em cobol pode parecer bem simples no que se refere a estimar os esforços na elaboração dos roteiros/procedimentos de teste, mas muitas vezes por mais especializada que seja a estimativa sempre podemos ter uma surpresa desagradável na execução. Creio que utilizando essa matriz e também uma avaliação especialista entre os integrantes mais experientes da equipe seria o ideal.
    Você já chegou a medir a produtividade da equipe utilizando essa matriz? Qual o percentual de acerto?
    Parabéns pelo post.
    Abraço.
    Patrick Oliveira
    patrickoliveiras@gmail.com

    ResponderExcluir
  7. Gostei muito do post Quezada, já utilizo algo parecido e alinhado com a complexidade dos casos de uso e também às plataformas altas e baixas existentes nos projetos da empresa categorizando a complexidade e mapeando a quantidade de casos de teste.
    Como sabemos uma especificação de uma determinada rotina em cobol pode parecer bem simples no que se refere a estimar os esforços na elaboração dos roteiros/procedimentos de teste, mas muitas vezes por mais especializada que seja a estimativa sempre podemos ter uma surpresa desagradável na execução. Creio que utilizando essa matriz e também uma avaliação especialista entre os integrantes mais experientes da equipe seria o ideal.
    Você já chegou a medir a produtividade da equipe utilizando essa matriz? Qual o percentual de acerto?
    Parabéns pelo post.
    Abraço.
    Patrick Oliveira

    ResponderExcluir
  8. Olá Patrick,

    Utilizando essa Matriz para realizar as estimativas, somando a intuição e julgamento de um especialista baseados na experiência em planejar e testar sistemas semelhantes e após uma revisão, seja ela formal ou informal, temos em média 85% de acerto. Estou considerando toda a experiência que já tive com essa Matriz na empresa atual e anteriores.

    Que bom que você gostou do post :-) ! Agora é só assinar o RSS do blog!!!

    Até+,
    Quezada

    ResponderExcluir
  9. Gustavo,adorei o seu artigo sempre tive dúvida sobre como estimar o tempo no processo de teste, seu artigo explica tudo de forma clara.
    Abraços Roselle Amaral

    ResponderExcluir
  10. Gustavo, tenho o seguinte problema: preciso estabelecer critérios para definir a prioridade de um caso de teste como, por exemplo, baixa, média ou alta. Com caso de uso eu fiz o seguinte: Caso de Uso Simples - até 2 fluxos ou até 3 regras de negócios; Caso de Uso Médio - de 3 até 6 fluxos ou de 4 até 9 regras de negócios; e Caso de Uso Complexo - acima 6 fluxos ou acima 9 regras de negócios. Será que conseguimos fazer isso com caso de teste ? Preciso de um critério que seja claro e objetivo e que possa ser avaliado e medido antes do caso ficar pronto. Não me parece algo trivial, não acha ?

    ResponderExcluir
  11. Olá Marcus,

    É possível fazer isso com caso de teste sim, mas neste caso, minha sugestão é você utilizar o conceito de nível de regressão. Para facilitar um pouco o entendimento, acesse o artigo que escrevi no link http://www.alats.org.br/Default.aspx?tabid=206&mid=1073&ctl=Details&ItemID=108 e dá uma olhada na página 24, Abordagem para teste de regressão.
    Creio que conseguindo aplicar o nível de regressão para os casos de teste, tudo ficará mais fácil.

    Espero que ajude!!

    Até+,
    Quezada

    ResponderExcluir