É bom que os testadores estejam competindo para ver quem abre mais bugs?

Eu não acho que seja bom que eles decidam encontrar o maior número de bugs. Embora seja verdade que o trabalho deles seja encontrar bugs, o trabalho deles não é "encontrar os bugs mais ". Seu objetivo não é encontrar o máximo, seu objetivo é ajudar a melhorar a qualidade do software. Premiá-los por encontrar mais bugs é o mesmo que recompensar um programador por escrever a maioria das linhas de código, em vez do código de maior qualidade.

Transformar isso em um jogo lhes dá um incentivo para se concentrar em encontrar muitos bugs superficiais, em vez de encontrar os bugs mais críticos. Como você mencionou na sua edição, isso é exatamente o que está acontecendo na sua organização.

Alguém poderia argumentar que qualquer bug que encontrar é um jogo justo, e que todos os bugs precisam ser descobertos. No entanto, como sua equipe provavelmente tem recursos limitados, você prefere que o testador se concentre em várias horas ou dias investigando profundamente seu sistema, tentando encontrar bugs realmente grandes ou passando várias horas ou dias ignorando o aplicativo, procurando erros tipográficos e pequenos erros. erros no alinhamento de objetos em uma página?

Se a empresa realmente quiser fazer um jogo, dê aos desenvolvedores o poder de adicionar pontos a um bug. "bugs estúpidos" obter pontos negativos, difícil encontrar erros com relatórios bem escritos obter vários pontos. Isso então move o incentivo de "encontrar o máximo" para "ser o melhor em fazer o seu trabalho". No entanto , isso também não é recomendado, porque um programador e um analista de controle de qualidade podem trabalhar juntos para preencher artificialmente seus números.

Resumindo: não faça um jogo para descobrir bugs. Encontre maneiras em sua organização para recompensar o bom trabalho e deixar por isso mesmo. A gamificação recompensa as pessoas por atingir um objetivo. Você não quer que um analista de QA tenha o objetivo de "encontrar o máximo de bugs", você quer que seu objetivo seja "melhorar a qualidade do software". Esses dois objetivos não são os mesmos.

Vou discordar um pouco com as outras respostas. "Encontrar bugs" para um testador é um pouco como "escrever código" é para um desenvolvedor. A quantidade bruta é sem sentido. O trabalho do testador é encontrar tantos bugs existentes que eles possam, não encontrar o maior número de bugs. Se o testador A encontrar 5 dos 10 erros em um componente de alta qualidade e o testador B encontrar 58 dos 263 erros em um componente de baixa qualidade, então o testador A é o melhor testador.

Você deseja que os desenvolvedores gravem a quantidade mínima de código para resolver um problema específico e deseje que um testador registre o número mínimo de relatórios que descrevem corretamente o comportamento interrompido. Competir para encontrar o maior número de defeitos é como competir para escrever a maioria das linhas de código. É muito fácil entrar no jogo para ser útil.

Se você quer que os testadores compitam, deve ser mais diretamente baseado no que eles estão lá para fazer, que é validar se o software funciona conforme descrito. Portanto, talvez as pessoas compitam para ver quem pode escrever os casos de teste mais aceitos ou, melhor ainda, escreva o conjunto de casos de teste que cobrem o maior número de códigos.

A melhor medida da produtividade do desenvolvedor é o número de tarefas completas vezes complexidade da tarefa. A melhor medida da produtividade do testador é o número de casos de teste executados vezes a complexidade do caso de teste. Você quer maximizar isso, não erros encontrados.

Com base em minhas experiências pessoais, isso não é bom. Quase sempre leva os desenvolvedores a arquivar bugs que são duplicados, ridículos ou completamente inválidos. Normalmente, você verá muitos deles aparecendo de repente no final de um mês / trimestre, à medida que os testadores se apressam em cumprir as cotas. A única coisa pior que isso é quando você também penaliza os desenvolvedores com base no número de bugs encontrados no código deles. Suas equipes de teste e desenvolvimento estão trabalhando umas contra as outras nesse ponto, e uma não pode ter sucesso sem fazer a outra parecer ruim.

Você precisa manter seu foco no usuário aqui. Um usuário não tem ideia de quantos bugs foram arquivados durante o teste, tudo o que eles veem é o que conseguiu. Os usuários não se importam se você arquivar 20 relatórios de bugs ou 20.000, contanto que o software funcione quando eles o receberem. Uma métrica melhor para avaliar os testadores seria o número de erros que foram relatados pelos usuários, mas que deveriam ter sido razoavelmente capturados pelos testadores.

Isso é muito mais difícil de acompanhar, no entanto. É bastante fácil executar uma consulta de banco de dados para ver quantos relatórios de bug foram arquivados por uma pessoa específica, que eu suspeito que seja a principal razão pela qual a métrica "bugs arquivados" é usada por tantas pessoas.

Não há nada de errado em fazer um jogo para encontrar bugs. Você encontrou uma maneira de motivar as pessoas. Isso é bom. Também é revelado um fracasso em comunicar prioridades. Acabar com o concurso seria um desperdício. Você precisa corrigir as prioridades.

Poucos jogos reais têm um sistema de pontuação simples. Por que o bug deve caçar?

Em vez de pontuar o jogo simplesmente pelo número de bugs, você precisa fornecer uma medida da qualidade do relatório de bugs. Então o concurso é menos sobre o número de bugs. Vai ser mais como um concurso de pesca. Todos procurarão encontrar o grande bug que receberá uma pontuação de alta prioridade. Torne a qualidade do relatório de erros parte da pontuação. Peça aos desenvolvedores que forneçam aos testadores feedback sobre a qualidade do relatório de erros.

Ajustar o equilíbrio do jogo não é uma tarefa simples, então esteja preparado para gastar algum tempo fazendo isso direito. Deve comunicar claramente seus objetivos e deve ser divertido. Também será algo que você poderá ajustar à medida que as necessidades de negócios mudarem.

Encontrar bugs é o trabalho deles. Contanto que eles não estejam tornando as coisas menos eficientes (por exemplo, abrindo um bug para 10 erros de digitação em vez de um para cobrir vários deles), isso os encoraja a fazer exatamente o que eles deveriam estar fazendo, então Eu não vejo muita desvantagem.

Esta é uma expansão da resposta do @ CandiedOrange.

Para começar a desviar a atenção para objetivos mais úteis, considere algo muito informal e não oficial. Por exemplo, os desenvolvedores poderiam comprar alguns pequenos tokens e troféus.

A cada dia que pelo menos um bug significativo foi relatado, deixe um token "Bug of the Day" na mesa do testador. Uma vez por semana, realize uma cerimônia com uma procissão de desenvolvedores entregando um token ou troféu "Bug of the Week" maior e melhor. Faça a entrega do troféu "Bug do Mês" ainda mais dramática, talvez com bolo. Cada token ou troféu deve ser acompanhado por uma citação dizendo por que os desenvolvedores acharam que era uma boa coisa que o bug foi encontrado nos testes. Cópias das citações devem ser colocadas em algum lugar onde os testadores possam lê-las.

A esperança é que os testadores mudem sua atenção de encontrar o maior número de insetos para coletar o maior número de troféus e fichas. Sua melhor estratégia para fazer isso seria ler as citações e pensar em quais abordagens para os testes provavelmente trarão bugs que os desenvolvedores considerarão importantes.

Simplesmente ignore relatórios de bug sem importância. Como tudo seria muito informal e informal, poderia ser desligado ou alterado a qualquer momento.

Is this good for the project?

Não . Você mesmo apontou que observou que isso resulta em relatórios de baixa qualidade que não são direcionados para a funcionalidade exigida, e que os testadores acabam, para agravar o problema, lutando para concluir o trabalho que eles realmente "supostamente" "estar fazendo.

If not, how can I (as a software developer), try to change the thinking and attitudes of the team of testers?

Aumente o problema com o seu gerente de projetos. Eles devem considerar esse tipo de coisa como parte de seu trabalho. Se o seu primeiro-ministro não está disposto ou é incapaz de lidar com isso, você está meio que desenvolvendo suas próprias estratégias de enfrentamento. (o que seria uma questão diferente)

Eu penso como será (ou como já é) se continuar assim, você não necessariamente terá uma qualidade inferior. Embora eu ache que vai diminuir a relação quantidade para qualidade. Depende se isso é uma coisa ruim ou não. Depende se

reporting bugs about screen enhancements, usability, or stupid bugs.

é algo que você realmente não quer. Se isso for claro com os testadores, eu apenas diria a eles para não fazerem as coisas que você não quer que seja relatado, mas seja claro sobre isso. Faça isso quando um desses relatórios aparecer novamente.

A razão pela qual eles têm uma competição é provavelmente se divertir enquanto trabalham, então eles provavelmente não estão pretendendo fazer um trabalho ruim (se isso for considerado ruim).