Medição do indicador Bugs por Desenvolvedor

[Lih]

Olá colegas, mais uma vez estou precisando da ajuda de vocês. rsrsrsrs

A empresa que trabalho precisa medir a quantidade de defeitos por desenvolvedor. Como a empresa trabalha com Caso de Uso, pensei em classificar os casos de uso  de acordo com complexidade (baixa, média, alta) e definir uma quantidade de bugs aceitável de acordo com a complexidade do UC. Mas estou aqui pensando,  qual seria a quantidade ideal? Como medir isso? Existem outras opções que podem me ajudar ?

Se alguém  tiver alguma idéia ou já tiver passado por esta necessidade, com certeza todas as dicas serão bem vindas.

muitoo obrigadaa!

--
Eliane Somavilla
Bacharel em Sistemas de Informação
Pós Graduação em Engenharia de Projetos de Software
ISTQB Certified Tester - CTFL
ITIL V3 Certified Fundation
Auditora ISO 9001:2008
(48) 8453-4621
Florianópolis - SC

[Karla Viana]

Olá,

vou citar um exemplo lá da empresa que  trabalhei. eram definidos bugs de acordo com alguns critérios (block,major) eram críticos tais parte da aplicação não realizava operações simples (CRUD) ou quando na regressão aparecia uma nova falha.. e minor e text era para coisas mais visual mesmo um label errado coisa desse  tipo  e usabilidade.

Não sei como é  a organização de sua empresa , se existe algum plano de testes ou pode ser uma coisa mais informal se caso tenha contato com  cliente.. cada caso e um caso..

--
--
Você recebeu esta mensagem porque está inscrito para o Google
Grupos "Grupo de Usuarios de Teste de Software - SUCESU-RS" grupo.

Para postar neste grupo, envie um email para guts-rs...@googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para
guts-rs-suces...@googlegroups.com
Para mais opções, visite este grupo em
http://groups.google.com/group/guts-rs-sucesu?hl=pt?hl=en
---
Você está recebendo esta mensagem porque se inscreveu no grupo "GUTS - Grupo de Usuários de Testes de Software - SUCESU-RS" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para guts-rs-suces...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--

Karla Maria Viana da Costa Pereira, CTFL

[Karla Viana]

No próprio mantis se  vc tiver acesso administrador ele  lhe dirá quantos bugs aberto atribuindo ao desenvolvedor e  juntamente com seu gerente poderá definir uma politica de  bugs aceitáveis oras para liberar release ...se faziam um métrica de esforço por desenvolvedor levando em consideração o caso de uso e usava la as metricas.. 

[Lih]

Não há uma definição com o cliente.  Este indicadores foi solicitado pelos gestores para a equipe de QA. Já temos a definição de  bugs com criticidade Alta, Média, Baixa. A questão é, por exemplo, em um caso de uso complexo, qual a quantidade de bugs aceitável?

Em 14 de maio de 2013 13:05, Karla Viana <karlavi...@gmail.com> escreveu:

[Vanessa Vareira]

Oi Eliane, concordo com a Karla, acho que primeiro deve definir o que é criticidade Alta, Média e Baixa. Por exemplo se definir que uma falha com criticidade alta é quando a falha impede o uso da aplicação, acho que a quantidade aceitável seria zero.

[Lih]

Lucas, a idéia do  histórico de projetos é boa.  Vou passar essa idéia pra galera amanhã.

Também quero deixar claro que sei de todos os problemas causados pela medição deste indicador, mas é pedido dos gestores da empresa. Nem sempre tenho o poder de participar da decisão do que será medido. O que me resta é buscar a melhor solução e trazer o mínimo de problemas para o relacionamento entre QA e desenvolvimento.

Obrigada galera!

Em 14 de maio de 2013 20:30, Raphael Soares <raf...@gmail.com> escreveu:

Uma forma fácil de medir é usando o mantis ou outra ferramenta de gestão de bugs, porém pensem bem se vale a pena esse tipo de métrica porque geralmente desmotiva e aumenta a distância entre qa e desenvolvimento, o trabalho ideal é unir todos e não apontar um culpado pelos erros. Uma opção é medir mas não expor, em reuniões tentar usar exemplos reais para todos no geral e não apontar ninguém, com o intuito de incentivar a melhoria da qualidade.

Boa sorte.

Raphael Soares

--

--
Você recebeu esta mensagem porque está inscrito no Grupo "BSTQB" no Grupos do Google.
(1) Para postar neste grupo, envie um e-mail para bs...@googlegroups.com
(2) Para cancelar a sua inscrição neste grupo, envie um e-mail para bstqb-un...@googlegroups.com
(3) Para ver mais opções, visite este grupo em http://groups.google.com.br/group/bstqb
(4) Para ver as regras da lista acesse: http://www.bstqb.org.br/?q=node/656
---
Você está recebendo esta mensagem porque se inscreveu no grupo "BSTQB" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para bstqb+un...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
--
Você recebeu esta mensagem porque está inscrito no Grupo "BSTQB" no Grupos do Google.
(1) Para postar neste grupo, envie um e-mail para bs...@googlegroups.com
(2) Para cancelar a sua inscrição neste grupo, envie um e-mail para bstqb-un...@googlegroups.com
(3) Para ver mais opções, visite este grupo em http://groups.google.com.br/group/bstqb
(4) Para ver as regras da lista acesse: http://www.bstqb.org.br/?q=node/656
---
Você está recebendo esta mensagem porque se inscreveu no grupo "BSTQB" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para bstqb+un...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Karla Viana]

Obrigada Vanessa :)

[Dionatan Moura]

Eu sugeriria então que vocês aproximem muito mais os times de QA e Dev, fazendo que eles pensem na qualidade, e não em bugs. Talvez a pressão pra desenvolver faça os bugs e não dê tempo de pensar na qualidade. Talvez o problema seja no processo de vocês. Bugs sempre vão existir, mas é óbvio que tem desenvolvedores que testam mais antes de entregar pro QA testar... Talvez vocês precisem de mais técnicas de inspeção, por exemplo peer review antes para cada commit, isso dá a responsabilidade para o revisor também. São ideias para melhorar a qualidade, repensar... Porque nunca vi bem isso de controlar bugs por desenvolvedor, isso é muito relativo. O mesmo vejo para controlar a produtividade de cada desenvolvedor, é bem relativo, porque pode ser sêniors que ajudam muito a equipe e vivem fazendo reuniões, e não conseguem produzir tanto (código).

São as minhas opiniões. :)

Abraços!

2013/5/14 Lih <eliane.s...@gmail.com>

Você recebeu esta mensagem porque está inscrito para o Google
Grupos "Grupo de Usuarios de Teste de Software - SUCESU-RS" grupo.

Para postar neste grupo, envie um email para guts-rs...@googlegroups.com

Para cancelar a sua inscrição neste grupo, envie um e-mail para

guts-rs-suces...@googlegroups.com
Para mais opções, visite este grupo em
http://groups.google.com/group/guts-rs-sucesu?hl=pt?hl=en
---
Você está recebendo esta mensagem porque se inscreveu no grupo "GUTS - Grupo de Usuários de Testes de Software - SUCESU-RS" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para guts-rs-suces...@googlegroups.com.

[Lih]

Pessoal, obrigada por todas as respostas.

Aqui na empresa o objetivo é encontrar os problemas que causam o número elevado de defeitos. Por exemplo, verificar que um projeto teve  alto numero de defeitos porque a pessoa alocada não recebeu o treinamento adequado. Para evitar ruidos e auxiliar na medição deste indicador, eu elaborei um questionário com 5 perguntas para os desenvolvedores para que eles descrevam como foi a fase de implementação (se estavam com super alocação, se encontraram problemas que não estavam previstos no planejamento, se receberam treinamento etc). Creio que estas perguntas aliadas ao indicador ajudarão na interpretação do porquê de tanto defeito.

Como eu não expliquei no inicio o motivo da gestão da empresa ter solicitado este indicador, algumas pessoas pensaram apenas nas dificuldades para medi-lo.

Não trabalhamos com Pontos de Função aqui, mas por pacote de trabalho. Vou usar estas medidas para  tentar entrar em consenso com a equipe sobre um numero aceitável de bugs de acordo com a complexidade do desenvolvimento. Acho que seja a melhor saida agora já que não temos base histórica de outros projetos.

Muito obrigada a todos mais uma vez! Ajudaram muito :)

Em 15 de maio de 2013 09:01, Luiz Modesti <lu...@triadsystems.com.br> escreveu:

Bom dia  a todos.

Estão se falando em medir defeitos por desenvolvedor e comentando-se que isso pode ser  nocivo. Depende o objetivo:  Se a intenção for atacar a causa raiz  eu acho que esta certo em descobrir onde estão as falhas sim.  Pois você pode estar no  entendimento de requisitos, ai cairia bem um peer review.  Você pode ter problemas de entendimento de regras de negocio , ai caberia bem uma explicação mais detalhada sobre o projeto. Voce poderia ter uma deficiência em sql , ai caberia um treinamento etc.  Então eu discordo dessa nocividade em caça as bruxas , mas depende a intenção.

E quanto a métricas , se bem usadas, ferramentas de  bug tracking podem ajudar a medir a qualidade do software.

 

Att;

 

De: bs...@googlegroups.com [mailto:bs...@googlegroups.com] Em nome de Thiago Silva Conceição
Enviada em: quarta-feira, 15 de maio de 2013 07:15
Para: bs...@googlegroups.com
Assunto: Re: [BSTQB] Medição do indicador Bugs por Desenvolvedor

 

Bom dia Lih, tudo bom?

 

Espero que sim!

 

Recomendo que mensure os UCS com a medida de pontos de função e monte uma métricas de Defeitos/PFs.

 

Definir complexidade de UCs é algo muito relativo já que depende do

conceito pessoal de cada um sobre o que se considera complexo e simples. Isto em geral costuma culminar em interpretações diferentes por profissionais diferentes, quando em verdade medidas e métricas devem ser interpretadas por toda e qualquer pessoas da mesma maneira e imparcialmente.

 

Com uma matriz de rastreabilidade UC X Desenvolvedor identifique através de um indicador a eficiência e eficácia de cada um.

 

Porém o ponto mais importante é entender que as medidas, métricas e indicadores devem orientar a melhoria dos seus processos de desenvolvimento e testes, sem julgar jamais o profissional e pessoal de cada um dos seus desenvolvedores em questão.

 

Espero ter ajudado e me coloco a sua disposição!!!

 

Thiago S. Conceicão

Implementador MPS.BR, CFPS,CBTS

Enviado via iPhone

--

[Daniel Wildt]

Reflexão:

Se é para medir defeitos, não era melhor medir a quantidade de defeitos que o usuário final encontra, e trabalhar como um time em prevenção para evitar que as falhas cheguem até lá? 

Um testador deve ter um papel dentro da equipe de prevenção. Deve ser o profissional que vai apoiar analistas de negócio e desenvolvedores em validação (sim, validação), garantindo que o que está sendo feito é o que o cliente tem interesse. 

Que métricas vocês medem para buscar melhoria de processo? 

Se você perguntar ao time de desenvolvimento sobre quantidade de defeitos, qual a reação do time de desenvolvimento? Eles assumem que estão com problemas para automação e garantia de qualidade, ou eles acusam alguém sobre a causa dos defeitos? 

-- Daniel Wildt (+55 51 99989030) - @dwildt

2013/5/14 Lih <eliane.s...@gmail.com>

--
--

Você recebeu esta mensagem porque está inscrito para o Google
Grupos "Grupo de Usuarios de Teste de Software - SUCESU-RS" grupo.

Para postar neste grupo, envie um email para guts-rs...@googlegroups.com

Para cancelar a sua inscrição neste grupo, envie um e-mail para

guts-rs-suces...@googlegroups.com
Para mais opções, visite este grupo em
http://groups.google.com/group/guts-rs-sucesu?hl=pt?hl=en
---
Você está recebendo esta mensagem porque se inscreveu no grupo "GUTS - Grupo de Usuários de Testes de Software - SUCESU-RS" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para guts-rs-suces...@googlegroups.com.

[Alejandro Olchik]

Concordo com os pontos de reflexão e adiciono: a quem interessa a remoção dos defeitos? E quanto ao time to market? E a satisfação do time? E a lucratividade? Como o foco em eliminar os defeitos afeta os outros interesses? É possível gerenciar cada uma dessas partes de forma independente?

Uma prática que muitas vezes funciona é definir os indicadores a partir dos propósitos das diferentes partes interessadas no trabalho sendo realizado, evitando o foco em subotimizar o processo para atender apenas a um interessado. Não esquecer também que o indicador é apenas um sinalizador cujo objetivo deveria ser servir aos que querem melhorar o seu próprio trabalho.

Abs,
Alejandro

[Lih]

Exatamente Alejandro e Daniel.

Estamos tentando definir estas questões juntamente com a gestão da empresa para que a equipe de qualidade e os gestores estejam alinhados nos mesmos objetivos.

;)