1º Testing Dojo Paraíba
Para Michael Eason
[1], a relação entre os testadores e os desenvolvedores de um
projeto pode ser estimada com base na seguinte generalização
(testador:desenvolvedor):
- 1:3: Quando o processo é bastante maduro e os requisitos são detalhados e consistentes;
- 1:1: Quando o processo é imaturo, ou não existe processo e os requisitos são ambíguos, inconsistentes e desatualizados.
Kathy Iberle [2]
defende que a proporção entre testadores e desenvolvedores não
pode ser definida linearmente. Para ela, a quantidade de testadores
em relação aos desenvolvedores de um projeto deve ser estimada com
base no histórico dos projetos anteriores da organização e num
modelo (proposto por ela) onde essa relação é calibrada em função
de fatores ambientais (complexidade do projeto, nível de experiência
dos desenvolvedores ou testadores, entre outros). Dentre os
principais fatores descritos por Iberle, podemos destacar:
- A experiência dos testadores e desenvolvedores;
- A freqüência em que o desenvolvedor insere defeitos na aplicação (e a severidade desses defeitos);
- A eficiência do desenvolvedor em detectar e resolver defeitos antes de liberar a aplicação para a execução dos testes;
- A eficiência do testador em detectar defeitos;
- Entre outros.
Johanna Rothman
[3], no seu artigo “It Depends: Deciding on the Correct Ratio of
Developers to Testers”, corrobora a visão de Iberle. Para ela, não
existe uma melhor prática que possa ser aplicada em todas as
organizações. Ou seja, não existe resposta certa para a proporção
entre testadores e desenvolvedores de um projeto. Cada organização
deve analisar a sua realidade e definir os seus próprios patamares.
Adicionalmente, Rothman afirma que durante essa análise, devem ser
considerados os seguintes pontos:
- Produto: a qualidade dos requisitos, o tamanho e a complexidade do produto;
- Projeto: o processo de desenvolvimento, a tolerância do cliente em relação à quantidade defeitos ou atrasos nas entregas;
- Pessoal: a experiência dos testadores e desenvolvedores e as suas responsabilidades.
Randall Rice [4],
realizou uma pesquisa informal em 2000 durante a conferência “QAI's
20th Annual Software Testing Conference” e chegou à seguinte
conclusão:
- Proporção mais comum: 1 testador para cada 3 desenvolvedores;
- Proporção média: 1 testador para cada 7 desenvolvedores.
Para Rice, não
existe um número mágico que possa ser adotado para qualquer
organização. Além disso, as pesquisas sobre a relação
testador:desenvolvedor normalmente não adotam metodologias formais e
não representam a realidade do mercado em virtude de que o número
de participantes não é suficiente para determinar uma média
precisa.
Realidade Brasileira
Para delinear a
proporção mais comum de testadores em relação aos desenvolvedores
no cenário Brasileiro, foi realizada uma enquete no portal gratuito
de testes e qualidade de software TestExpert (www.testexpert.com.br).
Esta enquete foi realizada no período de 11 de outubro de 2007 a 22
de novembro de 2007 e contou com a participação de 231
respondentes. O resultado da enquete pode ser observado na Figura 1.
Curiosamente, o resultado mais comum é compatível ao resultado da
pesquisa realizada por Randall Rice. A proporção mais comum foi de
1 testador para cada 3 desenvolvedores.
Figura 1: Resultado da Enquete (Testador:Desenvolvedor)
Trocando em miúdos:
não existe uma solução que sirva para todas as organizações. O
orçamento do projeto e o risco que um defeito na aplicação pode
trazer ao negócio são fatores que influenciam diretamente a
quantidade de testadores de um projeto. Ou seja, uma aplicação
simples de baixo risco, pode estimar uma proporção de “1:>10”.
No entanto, se a aplicação for utilizada em equipamentos médicos,
sem dúvida, a proporção deverá ser muito próxima de “1:1”.
De qualquer forma, uma grande quantidade de testadores por si só não
garante que a aplicação tenha mais qualidade e seja livre de
defeitos críticos. Grandes empresas como por exemplo, a Microsoft,
que podem dar-se ao luxo de ter a proporção de “1:1” em
praticamente todos os projetos , frequentemente liberam produtos
no mercado repletos de defeitos críticos. Ou seja: Tudo depende!
Referências
[1] EASON, Michael.
Sizing a Software Quality Assurance Group: Theory and Application
[2] IBERLE, Kathy.
Estimating Tester to Developer Ratios (or Not)
[3] ROTHMAN,
Johanna. It Depends: Deciding on the Correct Ratio of Developers to
Testers.
[4] RICE, Randall.
The Elusive Tester to Developer Ratio.
[5]
Microsoft Test center aims to help corporate programmers avoid buggy
code. Disponível
em: http://www.networkworld.com/community/node/20877
[6] Qual é a proporção de
testadores em relação aos desenvolvedores nos seus projetos
(Testador:Desenvolvedor)?. Disponível
em: http://www.testexpert.com.br/?q=node/263
Post criado
por: Cristiano Caetano - É certificado CBTS pela ALATS. Consultor de
teste de software sênior com mais de 10 anos de experiência, já
trabalhou na área de qualidade e teste de software para grandes
empresas como Zero G, DELL e HP Invent.
Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
