Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

A 16ª Mesa Redonda DFTestes teve  como tema “Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?”. A discussão teve 12 respostas e 6 participantes, sendo eles: eu, Elias Nogueira, Marcelo Andrade, Sarah Pimentel, Felipe Silva e o Rodrigo Almeida de Oliveira.

A seguir faço um “resumo” do que foi discutido na mesa redonda, quem quiser conferir a discussão na íntegra pode acessar esse link (é necessário cadastro).

Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

O Elias Nogueira deu a sua resposta dizendo:

Olha, esse é um tema bem amplo e geralmente o terror de muitos testadores…
Já ví muitos “chefes” querendo medir a produtividade de um Analista de Teste pela quantidade de Casos de Teste criados, e isso é totalmente errôneo no meu ponto de vista.

A medição de produtividade, também ao meu ver, deve ser feita através de bases históricas, relacionando o tempo que um Analista de Teste levou para criar o Caso de Teste e quanto tempo um Testador levou para testar ou retestar. Só que precisamos dessas métricas, logo para ter uma estimativa aceitável para que eu possa chegar num Analista ou Testador e dizer que ele não está produzindo eu preciso de algo que me diga prove isso.

O normal que eu vejo é utilizar o bom senso em equipes que não possuem um base para estimativa e definir metas diárias ou semanais de execução e acompanhar o andamento, não em termos de cobrança mas para resolver os problemas que possam ocorrer e que geram uma parada nestas atividades.

O Elias ainda resumiu a sua opinião dizendo:

-> Só se pode medir produtividade se sabemos realmente quanto tempo é gasto na atividade (necessidade de base histórica);
-> Muitos problemas ocorrem durante essa fase (design e execução de teste) que influenciam, como requisitos mal escritos ou a falta dele, e até o não entendimento dos requisitos pela equipe;
-> Medir produtividade por quantidade de Casos de Teste criados não é legal!

A Sarah Pimentel fez a seguinte explanação sobre a questão:

Se determinada métrica é sentida pelo time como um objeto de pressão, talvez algo precise ser readequado, a métrica ou até mesmo a sua interpretação. O mais importante ai é que números são apenas números e sem explicações, sem o background de um cenário, eles não dizem muita coisa e o que dizem ainda pode estar errado.

Primeiro, pra que você quer medir a produtividade do seu time?

Crie uma resposta humana para essa pergunta e atenha-se a ela quando quiser medir a produtividade.

Medir a quantidade de casos de teste produzidos por dia (e agora sem considerar por analista) pode me ajudar a ver o percentual consumido do meu schedule até então e me ajudar a replanejá-lo, se for o caso,  para que as atividades sejam finalizadas.

Medir a quantidade de casos de teste produzidos por analista em um dia pode me ajudar a identificar problemas/dificuldades que não me foram diretamente sinalizadas por um membro da minha equipe quando sua média estiver muito aquém da margem dos seus colegas.  Ou se estiver muito além pode sinalizar um problema na elaboração dos casos (alguém já viu gente que cria um caso de teste de um step e dá ele como finalizado?).

Lembrando que existe uma média de produção diária, existem ocorrências que aceleram ou retardam essa produção, e existe a capacidade de produção de cada um que é diferente. Uns demoram mais, outros menos, e isso deve ser perfeitamente natural e aceitável em qualquer atividade.

Como medir produtividade de um time? Com alguém que entenda além de números e métodos estatísticos, de pessoas!

O Felipe Silva respondeu a questão dizendo:

Eu não conheço uma boa. A principal que conheço quantidades de TCs criados ou executados por determinado tempo. Sou totalmente contra este tipo de avaliação, pois desconsidera quase todos os fatores influenciadores, o primeiro desconsiderado nesta métrica é a qualidade, é fato que um teste feito com qualidade leva mais tempo que um teste feito de qualquer jeito (o que é facilmente descoberto quando os bugs que deveria ter sido pegos aparecem), ou fator desconsiderado é a complexidade da funcionalidade sob teste, testar 50PF (isso quando existe um tipo de métrica como PF) não é o mesmo que testar 5PF e também não é o mesmo que testar 5 funcionalidades de 10PF, e o terceiro fator desconsiderado que penso de primeira instancia é a qualidade inicial do código, pois testar uma funcionalidade que “funciona” é mais rápido do que testar uma que não funciona (tempo para relatar defeito, lerdeza da funcionalidade, fluxos que não funcionam e etc)

Não me perguntem uma forma de avaliar individualmente cada testador, pois não conheço um jeito justo e fácil (que não leve muito tempo para coletar), se for para avaliar “A equipe”, ai sim daria para calcular uma produtividade média.

O Rodrigo Almeida compartilhou como ele avalia a produtividade da sua equipe:

Aqui eu meço a produtividade da equipe baseado nas atividades entregues, tempo por atividade (gravação de caso de teste, execução dos testes manual/automatizado). E também avalio alguns itens subjetivos como postura profissional, trabalho em equipe, relacionamento, etc.

A Sarah ainda fez algumas sugestões de métricas que podem ser usadas:

Percentual de consumo de schedule :
-> para elaboração de casos de teste
->para execução de casos de teste no ciclos
Esse percentual pode ser medido levando em consideração:
-> quantidades (quantos casos de teste tenho a elaborar, quantos casos de teste tenho a executar, …), que não é muito real, mas ajuda;
-> tamanho (em relação ao tamanho total do software quanto você já cobriu considerando a representatividade do requisito coberto em UCPs ou FPs)
-> risco (utilizando o fator de risco de cada requisito)
Na minha opinião a “melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores” é a que traga bons resultados e incentive a melhoria contínua na sua equipe.😀
Pode ser tanto usando métricas, quanto pelo feeling. Uma junção dos dois pode ser interessante.

Com tanta coisa para fazer, por que eu ainda vou querer medir a produtividade dos testadores? Para fazer uma plaquinha de melhor testador do mês?

Segundo o Elias pode até ser feito bom uso da “plaquinha de melhor testador do mês”:

No termo da “plaquinha de funcionário do mês” dá pra fazer algumas coisas sim, e acho isso muito bom.

Um exemplo é ter a métrica de falsos-positivos por testador, que é, por exemplo, os bugs que são abertos que não são bugs ou mesmo a execução do Caso de Teste sem a devida atenção.

Outro é medir o tempo de reteste de um bug, onde tu vê se o testador está levando quase o mesmo tempo de execução do Caso de Teste.

Segue abaixo a minha resposta para a pergunta realizada.

Por que você é um gerente ausente?

Explicando melhor o motivo da minha pergunta.

Por que você é um gerente ausente?

Essa pergunta vale para quando essa necessidade de medir a produtividade vem do gerente/líder/coordenador da equipe.

A minha visão e opinião sobre uma pessoa que exerce um dos papéis citados acima, é que ela tem que interagir bastante com a equipe e conhecer bem ela.

Nos projetos que participei na empresa, que não é uma mega corporação, nunca tivemos a necessidade de medir a produtividade dos testadores, ou de qualquer outro membro da equipe. E isso deve ao fato de todos trabalharem juntos, fazerem reuniões periódicas sobre o andamento das tarefas, etc. Ou seja, todos atuando como um verdadeiro time.

E neste cenário os gerentes/líderes tem conhecimento de como estavam a produtividade de cada membro da equipe, e até os próprios membros da equipe tem essa informação, se eles se atentarem a ela.

Uma analogia que pode ajudar a entender melhor o que quero dizer:

Temos dois torcedores brasileiros: um vai assistir o jogo no estádio e o segundo vai ver pela TV.

No final do jogo quem terá uma melhor avaliação do desempenho da seleção brasileira?

O que viu no estádio, pois ele tem uma visão de todo o jogo e do comportamento dos jogadores quando estão sem a bola também. Na televisão a câmera foca onde está a bola, e assim o telespectador tem uma visão limitada do jogo.

Agora se a demanda por essa informação vem de outros e esses outros adoram métricas, o que é muito comum em nível gerencial, acredito que uma boa forma de informar essas métricas é através de resultados concretos obtidos pelos testadores, alguns exemplos:

  • Quantidade de casos de testes executados;
  • Número de bugs encontrados;
  • Quantidade de novos cenários de teste encontrados;
  • Quantidade de melhoria sugeridas.

Algo muito importante ao fazer um relatório sobre a produtividade do time é saber avaliar as métricas, pois números por si só são só números, nem sempre o testador que encontra mais bugs é o melhor ou mais produtivo.

E como disse antes, tentar medir trabalho cognitivo não é fácil e muitas vezes não é nem necessário utilizar métricas para isso, mas infelizmente muitas pessoas seguem o caminho da tirinha do Nerdson, compartilhada pelo Marcelo, que como um amigo meu diria, é uma verdadeira “PALHA-ASSADA”.

O Marcelo Andrade fez uma questão bem pertinente a discussão, sobre a definição de produtividade.

Afinal de contas, o que é “produtividade”?

A Sarah Pimentel respondeu a pergunta trazendo a definição da Wikipédia:

“A produtividade é basicamente definida como a relação entre a produção e os factores de produção utilizados. A produção é definida como os bens produzidos (quantidade de produtos produzidos). Os factores de produção são definidos como sejam pessoas, máquinas, materiais e outros. Quanto maior for a relação entre a quantidade produzida por factores utilizados maior é a produtividade.”

Sendo assim, a quantidade de casos de teste criados por um analista em um dia é sim uma métrica de produtividade. Se ela deve ser utilizada ou como ela deve ser utilizada é outro ponto.

Eu vejo que produtividade é: tempo de trabalho – tempo trabalhado  X resultados

Exemplo: o Zé trabalhou 8 horas, mas só durante 6 horas 100% focado no trabalho (1 de almoço e mais 1 de procrastinação) e nesta 6 horas ele conseguiu:

  • Preparar o ambiente de teste.
  • Executar os casos de testes da funcionalidade X e Y;
  • Reportar 6 bugs.

Mas e aí, o Zé foi produtivo ou não? Para saber é necessário ter uma base histórica, analisar as características das atividades (ex.: o ambiente de teste era Windows/Linux, quais softwares teve que instalar, etc). Ou seja, as métricas em si não são o fim, e sim o início para avaliar a produtividade do testador.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

2 comentários sobre “Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s