Capítulo 9: Estimativas de Testes (APT)

Autores: Fabrício Ferrari de Campos e Karine Birnfeld
Revisora: Patrícia Silva Corrêa

Introdução 

A Análise de Pontos de Teste (APT) é uma técnica de medição para a área de Teste de Software, baseada na técnica de medição de Análise de Pontos de Função (APF).

Ela utiliza como base, o tamanho do sistema em pontos de função, oriundos da aplicação da APF, considerando todas as suas funcionalidades.

A APT aplica-se apenas aos testes de caixa preta, visto que para as demais técnicas de teste (caixa branca, por exemplo), as estimativas já estão incluídas na técnica de APF.

A técnica de APT pode ser utilizada quando existem horas de teste pré-determinadas, pois alguns riscos envolvidos podem ser identificados comparando o tempo de testes estimados com APT com o tempo de testes pré-determinados. Com a APT, é possível determinar ou calcular o real valor das funções do sistema, com o objetivo de utilizar o tempo da equipe de testes o mais eficientemente possível [1].

Porém, em torno das estimativas em geral e da APT em específico giram algumas dúvidas como, por exemplo, as dificuldades encontradas para implantar esta técnica de estimativa, as vantagens e custo-benefício bem como pré-condições e dados necessários para sua implantação.

Importância das Estimativas x Controle 

Estimar é uma atividade que pode ser de grande valia no planejamento, gerenciamento e controle dos projetos. Porém, antes de estimar, é necessário saber por que será estimado, ou seja, qual a finalidade de cada estimativa e como ela será utilizada. Estimativas devem existir, principalmente, para melhorar o processo de planejamento e controle e não servir como uma forma de cobrança de profissionais, ou aplicado, apenas porque dizem que estimar é importante.

Segundo o Robson Agapito, atualmente as estimativas são extremamente importantes para fazer previsões mais certeiras, montar cronogramas, prever recursos e custos necessários. Caso não existam estimativas, será mais difícil acompanhar o andamento do projeto, não sendo possível fazer um acompanhamento efetivo a partir do cronograma. É realmente muito difícil planejar sem estimar, mas é bom ter consciência de que estimar não é adivinhar o futuro, ou seja, não é porque existem estimativas que o planejamento será exato, como disse o Fabrício Campos.

Planejar é diferente de controlar. Estimativas são muito importantes para planejar o esforço necessário para as atividades do projeto, que consequentemente, com um planejamento mais coerente, facilitará o controle e acompanhamento do projeto.

Não é impossível controlar algo sem medir, ou melhor, não é regra, que para controlar é necessário sempre medir. Como o próprio autor da frase (Tom DeMarco), disse recentemente: “[…] a ideia de que controle seja talvez o mais importante aspecto de um projeto de software. Mas não é. Muitos projetos foram realizados quase sem controle e produziram produtos maravilhosos, como o Google Earth ou o Wikipedia.” (tradução do José Papo).

Segundo o Fabrício Campos, medir é apenas uma das formas de controlar. Porém, não é uma tarefa tão simples, e nem sempre a mais importante para uma determinada realidade.

Análise de Ponto de Teste (APT) 

O tamanho do sistema a ser testado, medido através da técnica de APF, é a base da APT. Além do tamanho do sistema, existem outros fatores que devem ser considerados para estimar a atividade de testes de software.

Na APT existem três elementos relevantes: o tamanho do sistema a ser testado, a estratégia de teste (seleção de componentes do sistema e características de qualidade a serem testadas e a cobertura dos testes) e o nível de produtividade. O primeiro e o segundo elemento determinam o volume do trabalho de teste empreendido (expresso em pontos de teste). Se o número de pontos de teste for multiplicado pela produtividade (o tempo total para realizar determinado volume de testes) é possível obter a estimativa de testes em horas [1].

A importância da utilização de uma técnica de medição específica para testes de software se deve ao fato da maioria das outras técnicas embutirem o esforço de testes no esforço de desenvolvimento, perdendo-se alguns detalhes que precisam ser considerados para estimar os testes de software de forma mais eficiente.

No livro Base de Conhecimento em Teste de Software, do Anderson Bastos, Emerson Rios, Ricardo Cristalli e Trayahú Moreira, são citados os seguintes fatores que afetam os testes:

  • O grau de complexidade do processo de teste;
  • O nível de qualidade que se pretende alcançar com os testes;
  • O grau de envolvimento dos usuários com os testes;
  • As interfaces que as funções testadas têm com os arquivos;
  • A qualidade do sistema testado (o ciclo de reincidência de defeitos);
  • O nível de cobertura esperado com os testes;
  • A experiência e a produtividade da equipe de testes (medidos através de indicadores históricos);
  • O grau de automação dos testes;
  • A qualidade do ambiente de teste, até mesmo sua capacidade de simular o ambiente de produção;
  • A qualidade da documentação do sistema e, em especial, dos requisitos;

A Figura 9.01 ilustra a visão geral do modelo de APT.

Figura 9.01 – Visão geral da técnica de Análise de Pontos de Teste

O número de pontos de teste necessários para os testes dinâmicos é calculado para cada função com base no número de pontos de função atribuídos à função, os fatores funções dependentes (complexidade, interfaces, uniformidade, importância do usuário e intensidade de uso) e a qualidade dos requisitos relacionados ou a estratégia de teste para as características de qualidade dinâmica. A soma destes pontos de teste atribuídos a cada função é o número de pontos de teste dinâmico.

O número de pontos de teste estático para medir as características de qualidade é calculado com base no número total de pontos de função para o sistema e a qualidade dos requisitos ou estratégia de teste para as características de qualidade estáticas. Isto resulta no número de pontos de teste estático.

O total de pontos de teste é a soma dos pontos de teste dinâmico e estático. O número de horas de teste primárias pode ser calculado multiplicando o número total de pontos de teste pelos fatores ambiente de teste e produtividade. As horas de teste primárias representam o volume de trabalho envolvido nas atividades de teste primárias, como por exemplo, o tempo necessário para as fases de Preparação, Especificação, Execução e Conclusão.

Finalmente, o total de horas de teste é obtido adicionando subsídio para as atividades de teste secundárias (Planejamento e Controle) ao total de horas primárias. O tamanho deste subsídio, que representa o volume de trabalho envolvido nas atividades de gerenciamento, dependem do tamanho do time de teste e da disponibilidade de ferramentas de gerenciamento. O total de horas de teste é uma estimativa requerida para todas as atividades de teste, excluindo a elaboração do plano de teste.

Conforme mencionado no livro Base de Conhecimento em Teste de Software [2], a transformação do tamanho em esforço precisa de um trabalho adicional de calibragem, que demandará algum tempo até que as informações históricas estejam disponíveis.

Utilização da APT no Brasil

Pela discussão realizada no grupo DFTestes, a maior e mais ativa lista da comunidade de Teste de Software brasileira, percebeu-se que a técnica APT é pouco utilizada na realidade brasileira de Teste de Software.

Essa constatação pode levar a várias interpretações, mas é importante salientar que a realidade brasileira é diferente da Européia, onde a técnica é mais popular. Além do mais, a cultura brasileira também, o que faz com que os profissionais busquem outras soluções para suprir a necessidade de medição para a área de teste.

O Robson Agapito ainda ressaltou que para projetos fechados a utilização do APT é mais produtiva do que para projetos de manutenção de um software. Muitos dizem também que o APT é para projetos grandes, pois o PF inicial para se utilizar o APT é de 500 PF (o que equivale para muitas empresas em mais de 2000 horas no projeto) e não é qualquer projeto que tem este tamanho.

Outras formas de estimar

Frente ao pouco uso da APT no Brasil, procurou-se levantar durante a mesa redonda, como é feita a estimação na prática.

Percebeu-se que podemos estimar utilizando diversas técnicas e de formas diferentes, desde utilizando as reuniões do método Delphi até mesmo a utilização de técnicas de divisão de tempo em “caixas de tempo”, como por exemplo utilizando a técnica de Pomodoro.

De acordo com Eduardo Gomes, o fato é que estimar não tem muito valor se não se constroem bases históricas. Só será possível comprovar a efetividade das estimativas quando tivermos bases históricas que contribuam para os ajustes necessários nos modelos e para a utilização com maior segurança dos resultados das estimativas. Antes disso, continua sendo chute. Mas talvez um chute “calibrado”; é um ponto de partida pelo qual temos que passar.

É importante ter em mente que não há uma fórmula mágica que irá te dizer como estimar, por isso é importante experimentar métodos e técnicas diferentes, e ir adaptando a realidade. Lembrando-se que para uma boa estimativa, é importante possuir experiência naquilo que será medido, seja por meio da própria experiência das pessoas, ou utilizando-se de bases históricas.

Conclusão 

Estimar o tempo é uma atividade importante para um bom planejamento e gerenciamento do projeto de teste. A APT e uma técnica madura e focada na estimativa de tempo para a área de Teste de Software.

Todavia, é preciso analisar e avaliar a APT, perante a realidade do projeto no qual ela será aplicada, pois há pré-requisitos que caso não tenhamos, poderá ocasionar um mau uso de tal técnica e acabar resultando em mais problemas, do que soluções com a sua aplicação.

A realidade do mercado brasileiro de Teste de Software é diferente da de outros países, seja por questões econômicas ou culturais, portanto se faz necessário um esforço de adaptação, ao se optar por usar determinada técnica para estimar os esforços de testes.

Técnicas acopladas fortemente a pessoas, como por exemplo o planning poker e pomodoro, podem ser revelar um bom início para a atividade de estimar, principalmente, devido ao fato que estimar envolve pessoas e muitas vezes estimamos um trabalho criativo, que possui variáveis muito inconstantes e subjetivas.

Por fim, é importante buscar arquivar uma base histórica desde o primeiro dia do projeto, pois ela costuma ser uma boa fonte para a atividade de estimar e ao longo do projeto a estimativa acaba sendo mais efetiva, pois uma maior experiência provoca domínio sobre estimativas de determinada realidade

 

Referências Bibliográficas 

[1] Kusters R., A Cowderoy, F. Heemstra and E. van Veenendaal (eds).Testpointanalysis: a method for test estimation. Disponível em: <http://www.erikvanveenendaal.nl/UK/files/Testpointanalysis a method for test estimation.pdf> Acessado em: 04/07/2010

[2] Bastos, A., et al. (2007) Base de Conhecimento em Teste de Software. São Paulo, Martins Fontes, 2ª Edição.