Estimativa de Testes (APT)

O tema da Mesa Redonda DFTestes desta semana foi “Estimativa de Testes (APT)”. A discussão teve o total de 18 respostas e 8 participantes: eu, Felipe Silva, Robson Agapito, Renata Eliza, Carolina Baldisserotto, Sarah Pimentel, Eduardo Gomes e a Daiane Casagrande.

De início parecia que o tema não ia gerar muita discussão, pois poucas pessoas utilizam APT no Brasil, porém no decorrer da discussão o Robson Agapito levantou a pergunta sobre como o pessoal estima o tempo de testes na prática, que acabou gerando boas respostas.

Abaixo, faço um resumo da terceira Mesa Redonda DFTestes, lembrando mais uma vez, que se você se interessou pelo assunto, é altamente recomendável ler toda a discussão. 🙂

Antes de tudo, qual a real importância de estimar algo?

Para o Felipe Silva, a importância de estimar algo é a seguinte:

Poder prever recursos e custos necessários.

O Robson Agapito, afirmou que estimar é algo essencial:

Estimativa hoje é essencial para saber lidar com previsões e cronogramas. Hoje sem uma base histórica fica impossível de se avaliar e estimar em quanto tempo iremos trabalhar em um projeto.

Se não possuímos uma estimativa dificilmente saberemos o quanto já caminhamos no projeto, não saberemos o quanto estamos atrasados ou adiantados e nosso cronograma vai por água abaixo.

Na minha opinião, estimar:

• É uma atividade que pode ajudar muito no planejamento, gerenciamento e controle dos projetos. Mas é bom ter consciência que estimar não é adivinhar o futuro;
• Antes de estimar, precisamos saber porque estamos estimando algo, e o que iremos fazer com as informações obtidas, pois precisamos usá-las para melhorar o nosso processo e não como forma de cobrança de profissionais, ou porque todos mundo fala que estimar é importante.

Para a Renata Eliza, planejar sem estimar, é algo impraticável:

Uma coisa é fato, é impossível planejar sem estimar.

“Você não pode controlar o que não pode medir”, isso ainda é uma verdade na empresa de vocês?

O Felipe Silva, disse que:

Sim, mas aqui no final (nível gerencial) tudo acaba deixando de ser número e vira cor (verde, amarelo, vermelho).

Para a Renata Eliza, quando se medi, a probabilidade de falhar é menor:

Sem sombra de dúvidas. Quando se baseia no “achismo” a probabilidade de falhar é imensamente maior.

Na minha opinião, não acredito que não é possível controlar algo sem medir, ou melhor, não acredito que para controlar sempre precisamos medir. Como o próprio autor da frase (Tom DeMarco), disse recentemente: […] a idéia 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). Medir é apenas uma das forma de controlar, adoramos números, tanto que há as mais variadas estatísticas hoje em dia. Porém, não é uma tarefa tão simples, e nem sempre a mais importante para uma determinada realidade.

Quais são as maiores dificuldades de implantar APT?

O Robson Agapito, compartilhou uma experiência vivida ao tentar adaptar a APT:

Sobre o APT alguns dos grandes nomes de testes de software falam que não é utopia e que é possível implantar o mesmo. Eu ainda não consegui, criei um mini APT focado para a empresa, e mesmo assim não consigo ainda medir a quantidade de tempo, pois como precisamos de uma maior agilidade tivemos que redirecionar a quantidade de horas pela complexidade do requisito a ser testado, onde o analista de teste verifica a estimativa de um histórico e realiza um ajuste se necessário.

Eu vejo as seguintes dificuldades:

• Eu nunca usei APT, então não posso falar muito. Mas acho que as maiores dificuldades envolvem a empresa e as pessoas do projeto, todos precisam está alinhados, e cientes da importância da sua implantação;
• Documentação é um problema em muitos projetos, e fazer uma estimação em cima de uma documentação desatualizada ou pouco consistente, é uma perda de tempo;
• A expectativa, muitos acham que estimativas são verdades absolutas, quando na verdade não são, são apenas estimativas, e precisam está sempre sendo atualizadas;
• Vivemos num mundo imediatista (tudo é pra ontem), e todos esperam que usando o APT os resultados apareçam logo, porém isso é muito difícil de acontecer, para não dizer impossível. Uma prática fundamental, quando se usa APT, é ajustar-la, e o ajuste só pode ser feito com o passar do tempo;
• Estimar algo que envolve pessoas, é quase o mesmo que prever o tempo, ou querer saber quanto estará o dólar daqui há 4 meses. Portanto estimar por si só, é uma tarefa bem difícil.

Quais as vantagens de usar APT? O custo-benefício vale a pena?

O Felipe Silva prefere a estimativa com base em histórico:

Pessoalmente não gosto da APT, e acho que é mais um chute do que um cálculo real, prefiro análise com base em histórico, é mais calibrado e funcional.

Na minha opinião, deixando claro que nunca apliquei APT:

• Mais uma vez, só posso responder com base de informações teóricas. No segundo encontro da ALATS-SP (slides), deu para perceber que na empresa da Cristiane eles levam a sério estimativas, e elas já são usadas há um bom tempo, e desta forma, conseguiram construir uma boa base histórica. Com certeza tal base é uma fonte que fornece um bom diferencial e aumenta a eficiência no gerenciamento, planejamento e controle dos processo/projeto de Teste de Software;
• O maior benefício, é que paramos de usar o “achômetro” e passamos a usar informações do nosso histórico.

O que eu necessito para poder utilizar APT?

Segundo o livro Base de conhecimento em teste de software é necessário saber:

• O tamanho do sistema em pontos de função (APF);
• A 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 teste (por meio 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.

Quando usar e quando não usar APT?

Os seguintes momentos foram citados pelo Felipe Silva:

Quando usar: quando ainda não tiver nenhuma forma efetiva de medir, quando esta análise te gerar algum benefício, quando decisões realmente forem tomadas com base na APT (nível gerencial). Quando não usar: Oposto de tudo que eu disse no “quando usar”.

O Robson Agapito lembrou que muitos profissionais acreditam que a APT é só para projetos grandes:

A utilização do APT ou de qualquer outra estimativa é essencial, isto é fato, mas creio 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.

Na minha opinião:

• Sim
  • Quando você tiver a real necessidade, quando o custo-benefício realmente compensar;
  • Quando o seu ambiente permitir;
  • Quando a empresa tiver maturidade suficiente para entender e implantar-la.
• Não
  • Tudo que disse para o “Sim” ao contrário.

Quais são as lições aprendidas que vocês tiveram sobre estimar testes?

O Felipe Silva compartilhou as seguintes lições aprendidas:

Não estimamos com APT. Ajuda na alocação de recursos entre as equipes (dentro do mesmo projeto), é possível saber o quanto se pode implementar para que nós consigamos testar à tempo (aqui é feito duas estimativas: de implementação e de testes, existe uma lista de negócios desejáveis à entrar na build, tudo que for possível de implementar e testar em tempo hábil entra na build), poderia ajudar estimar custo do projeto para o cliente.

As seguintes lições aprendidas eu tirei até o momento:

• Estimar testes não é fácil 😦 (se fosse todo mundo faria) 🙂
• Precisamos estimar com as ferramentas que o nosso ambiente nos dá;
• Mais uma vez, adaptação é essencial;
• Quando não temos uma base histórica, o melhor a ser fazer é entender bem sobre o sistema sob teste e Teste de Software, e aí gerar as estimativas das pessoas. Como por exemplo, usando planning poker;
• O que não podemos fazer, é ficar usando técnicas derivadas do “achômetro”, como por exemplo: “estimativa do dedo”,  “veja bem”, “se” e famoso Cálculo Hipotético Universal Técnico Estimativo (vulgo C.H.U.T.E).

Como vocês estimam na prática o tempo de testes?

O Felipe Silva pratica da seguinte maneira:

Base histórica (conhecimento), e também faço um cálculo bem simples, quantidade de TCs * complexidade da funcionalidade sob teste.

Na empresa do Robson Agapito eles fazem o seguinte:

Aqui fazemos o seguinte, temos divididos os requisitos por tipo, e temos hoje 4 tipos. Como é um ERP possuímos vários sistemas.

Nesse caso criamos as categorias:

SISTEMA 1

TIPO 1

TIPO 2

TIPO 3

TIPO 4

SISTEMA 2

TIPO 1

TIPO 2

TIPO 3

TIPO 4

SISTEMA 3

TIPO 1

TIPO 2

TIPO 3

TIPO 4

…

Então pegamos o tempo histórico dos último 4 meses de um requisito de determinado Tipo e de um sistema específico e calculamos a média. Após isso há o ajuste do analista de teste, que pode opinar e trocar para mais ou para menos o tempo histórico através do seu conhecimento no Sistema/Tipo.

A Carolina Baldisserotto compartilhou algumas experiências vividas com estimativas:

Na empresa anterior eu trabalhava em um projeto de manutenção de software com ciclos pequenos, e em cada ciclo tínhamos alguns requisitos e não ia dar tempo para testar todos, por isso tínhamos que escolher quais iriam ser testados pela equipe de teste e quais apenas o desenvolvedor ia testar.

Então a gente fazia assim:

Duas pessoas de teste estimavam o tempo de cada requisito (cada pessoa fazia a sua estimativa), de acordo com sua experiência, daí a gente tirava a média dos tempos dos dois analistas. Se o tempo estivesse muito diferente, a gente sentava pra ver o porquê da diferença.

Depois a gente classificava os requisitos de acordo com a criticidade (pouco crítico, crítico e muito crítico), então analisávamos os requisitos de acordo com o tempo que o teste ia levar e a criticidade dele, daí então escolhíamos quais a equipes de teste ia testar e quais não.

E na empresa que trabalho hoje, a estimativa do tempo é feita de acordo com a experiência de cada um mesmo.

A Sarah Pimentel, lembrou do método Delphi, que é utilizado em várias áreas:

Nenhum projeto que trabalhei empregou o APT para fazer estimativas. Quando participei de projetos com estimativas formais usávamos Delphi, que não é uma técnica de chute 🙂 Existe uma organização de papeis e fases.

O Eduardo Gomes relatou a sua jornada em estimativas de teste:

Há mais ou menos 1 ano estamos buscando formas de estimar o esforço dos projetos de teste associados aos nossos projetos de desenvolvimento.

Definimos pela utilização em paralelo de algumas técnicas de estimativa, buscando trabalhar com valores médios entre elas para efeito de previsão de esforço de cada projeto, tentando minimizar os efeitos dos desvios de alguma delas.

Escolhemos a APT e também um modelo baseado no tamanho e complexidade dos casos de uso. Partimos do material da CBTS para início da pesquisa e procuramos adaptar os modelos à nossa realidade.

Além dessas estimativas, utilizamos também uma estimativa baseada na experiência dos profissionais. Chute??? Cabe aqui uma ressalva: o sucesso do “chute” depende muito de quem chuta, mas não devemos desconsiderá-lo, pois o mundo é repleto de subjetividade, e o ser humano tem uma capacidade única de análise e de intuição, que pode complementar, ou mesmo, em determinadas situações, ser mais importante que fórmulas complexas ou modelos elaborados.

O fato é que tudo isso 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.

Os resultados já começam a aparecer, tanto no melhor gerenciamento dos projetos, através da construção de cronogramas mais precisos e melhor utilização dos recursos, como pelo fomento a uma mudança cultural dentro da organização. Fica cada vez mais claro para todos os níveis organizacionais, que o esforço de teste não é o que sobra; pelo contrário, é parte significativa do esforço total dos projetos e fundamental para o sucesso dos mesmos.

Conclusões

Desta vez, acredito que deixar de forma explícita as conclusões da Mesa Redonda, se faz necessário, portanto segue abaixo, as conclusões que tive ao ler a discussão:

• Análise de Ponto de Teste (APT) é pouco usada no Brasil;
• Na minha opinião, o fato acima não deve ser encarado como algo ruim (ex. “estamos sempre atrás do resto do mundo mesmo”). Não vejo a menor necessidade de usar algo, só porque lá fora é muito usado. Lá fora a realidade é diferente, portanto muitas vezes temos que utilizar técnicas diferentes. Não podemos nos achar inferiores ou menos competentes, por não conseguir implantar a APT, e sim procurar outras soluções, usar o que temos de melhor e diferencial, a nossa criatividade;
• A base histórica é fundamental para qualquer técnica de estimativa, até para quem usa o Cálculo Hipotético Universal Técnico Estimativo, pois o CHUTE depende de quem está chutando, e o que diferencia o profissional do CHUTE de um amador, é que o primeiro tem uma base histórica, arquivada na memória, mais conhecida como experiência;
• Não há desculpas para não construir uma base histórica, é a melhor forma de fazer isso é documentando, afinal estimar não é uma tarefa solo, e sim de todo o time. E mesmo nos casos em que as estimativas dependem exclusivamente de você, armazenar a sua experiência em um local não volátil, é muito melhor (essa foi bem nerd rs);
• Estimar é necessário, ponto. Técnicas existem, é uma verdade. Não há fórmulas mágicas, não é possível fazer copy paste de uma técnica e querer que ela funcione perfeitamente na sua empresa, portanto adaptar uma técnica é fundamental, ou melhor, calibrar;
• Se uma tarefa for muito grande, então quebre-a! Simples assim, pois estimar tarefas menores é muito mais fácil e os resultados muito mais precisos;
• Estimar envolve pessoas, elas que devem ser o termômetro das nossas estimativas. E pensando nisso, técnicas utilizadas em times ágeis, como o planning poker e pomodoro, podem aumentar a precisão das estimativas, e tornar natural a tarefa de estimar e uma tarefa do time, não de um único indivíduo.

Bem é isso pessoal, a quarta Mesa Redonda vem aí, e para participar é muito simples é só se inscrever no DFTestes. 😉

E fiquem de olho na discussão, pois podem haver novas respostas, após a data desse resumo, como houve na discussão passada sobre Testes Ágeis, onde o Jorge Diz, fez importantes considerações e explicações.

Até mais!

Fique por dentro das novidades, assine o feed do QualidadeBR.

P.S.: Esse post foi feito com 5 tomates, utilizando o focus booster para controlar o tempo. 😉