Desenvolvimento

Ξ 4 comentários

Estimando esforço para Teste de Software

publicado por Samanta Cicilia

O maior desafio das chamadas Fábricas de Software é entregar um produto funcional e com qualidade, visto que muitas delas se preocupam em analisar, requisitar e construir, deixando de lado as atividades referentes à avaliação da qualidade. Muitas vezes o orçamento pequeno, prazo apertado e cobranças acabam fazendo com que alguns processos tomem o lugar de outros que, a princípio, eram considerados menos importantes.

A disciplina de Teste de Software é um desses processos que era deixado de lado, mas que, com o passar do tempo, tem se tornado independente e importante no escopo do desenvolvimento de software, exigindo assim planejamento e estimativas mais específicas.

Essa estimativa específica para o Teste é muito importante para mensurar todo esforço e custo que essa etapa irá demandar e, através de iterações, agregar sucessivas melhorias.

Atualmente no mercado não há técnicas de estimativa de esforço adotadas como padrão para teste de software, existem muitas pesquisas e literaturas com abordagens diferenciadas, mas que ainda não alcançaram a precisão esperada para realizar estimativa de forma confiável. Existe ainda uma diferença entre estimar o esforço apenas para execução dos casos de teste e para toda a fase de teste (planejamento, construção dos casos de teste, execucação dos casos de teste)

A maioria dos profissionais em teste de software utilizam uma base histórica ou a experiência do testador para estimar o esforço na execução de casos de teste.

Esse tipo de estimativa, apesar de muito difundida, acaba sendo um pouco imprecisa, já que depende de muitos fatores subjetivos. Por exemplo, uma base histórica pode ter outliers, ou seja, valores que se distanciam muito da realidade. Um caso de teste pode ser executado em mais ou menos tempo dependendo do conhecimento do testador sobre aquele caso de teste. Um outro exemplo seria a forma de armazenamento dessas informações, um testador pode estar passando mal em determinado dia e levar mais tempo para realizar uma tarefa do que levaria se estivesse bem disposto, e se estes dados forem utilizados para realizar estimativas, é provável que o resultado não seja confiável.

Essas variações podem afetar o resultado da estimativa e causar problemas de cronograma e alocação de recursos. Por esse motivo, existem técnicas sendo avaliadas e melhoradas para proporcionar uma estimativa mais objetiva. Dentre elas podemos citar a Análise por Pontos de Teste, proposta por Veenendaal e Dekkers, que é baseada em três elementos que determinam a medição, o tamanho do sistema a ser testado, a estratégia de teste e a produtividade. O volume de trabalho em pontos de teste é determinado pelo primeiro e segundo elementos. Para obter a estimativa em horas, o número de pontos de teste é multiplicado pela produtividade.É uma técnica que não cobre os testes de alto nível, sendo aplicada aos testes unitários e de integração.

Outra técnica é a Análise de Pontos por Casos de Teste (Nguyen, Pham e Lam) que utiliza casos de teste como entrada para fornecer a estimativa do esforço a ser gasto para executar esses casos de testes, gerando a pontuação de cada caso de teste. Para essa técnica a complexidade dos casos de teste está baseada em quatro fatores: resultados esperados, pré-condições, dados de teste e tipo do caso de teste. Esses elementos são divididos em dois grupos, os três primeiros determinam a grandeza do caso de teste e o último normaliza a complexidade dos diferentes tipos de teste existentes (performance, desempenho, usabilidade, etc). O escopo desse método abrange os testes que são executados manualmente, como testes de aceite, não cobrindo testes que envolvem a utilização de scripts, como os testes unitários.

Essas são apenas algumas técnicas das muitas que existem, principalmente na literatura acadêmica, e que visam estimar de forma mais próxima da realidade o esforço gasto em teste de software, reduzindo assim os problemas de escopo, tempo e recursos, agregando cada vez mais valor aos produtos desenvolvidos.

Referências:

VEENENDAAL, E. V.; DEKKERS, T. Test point analysis: a method for test estimation, 1999. Disponivel em: <http://www.vietnamesetestingboard.org/zbxe/?document_srl=22272>. Acesso em: 15 maio 2012.

NGUYEN, V.; PHAM, V.; LAM, V. Test Case Point Analysis: An Approach to Estimating Software Testing Size. Disponivel em: <http://www-scf.usc.edu/~nguyenvu/papers/TR-TCPA-01-2012.pdf>. Acesso em: 10 abr. 2012.

 

Abraços,

Samanta Cicília

Autor

Samanta Cicilia é carioca, graduada em Sistemas de Informação na Universidade do Gande Rio, trabalhando na área de Qualidade e Teste de Software na Infoglobo e certificada pelo ISTQB como CTFL. Com alguns textos publicados no Blog de Tecnologia do Jornal O Globo e com o blog testedesoftware.com. Linkedin: http://www.linkedin.com/pub/samanta-cicilia-ctfl/30/660/930

Samanta Cicilia

Comentários

4 Comments

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes