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

Sou desenvolvedor de software. Há uma equipe de testadores que acompanha e executa casos de teste escritos pelo analista, mas também realiza testes exploratórios. Parece que os testadores estão competindo para ver quem abre mais bugs, e notei que a qualidade dos relatórios de bugs diminuiu. Em vez de testar a funcionalidade e relatar bugs relacionados à operação do software, os testadores enviaram bugs sobre aprimoramentos de tela, usabilidade ou bugs estúpidos.

Isso é bom para o projeto? Caso contrário, como posso (como desenvolvedor de software) tentar mudar o pensamento e as atitudes da equipe de testadores?

Outro problema é que o prazo é estimado e não pode ser alterado. Assim, à medida que o prazo se aproxima, os testadores estarão se esforçando para concluir seus casos de teste, o que fará com que a qualidade dos testes diminua. Isso fará com que erros legítimos estejam no produto final recebido pelo cliente.

OBS: Esta competição não é uma prática da empresa! É uma competição entre apenas os testadores organizados por eles e sem prêmios.

Eu não acho que seja bom que eles façam um concurso para encontrar o maior número de bugs. Embora seja verdade que o trabalho deles seja encontrar bugs, o trabalho deles não é "encontrar mais bugs". O objetivo deles não é encontrar o máximo, o objetivo é ajudar a melhorar a qualidade do software. Recompensá-los por encontrar mais bugs é o mesmo que recompensar um programador por escrever a maior parte das linhas de código, em vez do código da mais alta qualidade.

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

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

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

Bottom line: não faça um jogo de encontrar bugs. Encontre maneiras em sua organização para recompensar um bom trabalho e deixe por isso mesmo. Gamification recompensa as pessoas por atingirem uma meta. Você não quer que um analista de controle de qualidade tenha o objetivo de "encontrar o máximo de bugs"; o objetivo é "melhorar a qualidade do software". Esses dois objetivos não são os mesmos.

Vou discordar um pouco das outras respostas. "Encontrar bugs" para um testador é um pouco como "escrever código" é para um desenvolvedor. A quantidade bruta não tem sentido. O trabalho do testador é encontrar o maior número possível de bugs, não o maior número possível. 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, o testador A é o melhor testador.

Você deseja que os desenvolvedores escrevam a quantidade mínima de código para resolver um problema específico e que um testador escreva o número mínimo de relatórios que descrevam corretamente o comportamento incorreto. Competir para encontrar o maior número de defeitos é como competir para escrever o maior número de linhas de código. É muito fácil entrar no sistema de jogos para ser útil.

Se você quiser ter testadores para competir, deve ser mais diretamente baseado no que eles devem fazer, para validar se o software funciona conforme descrito. Portanto, talvez as pessoas concorram para ver quem pode escrever os casos de teste mais aceitos ou, melhor ainda, escrever o conjunto de casos de teste que cobrem mais códigos.

A melhor medida da produtividade do desenvolvedor é o número de tarefas concluídas vezes a 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 é uma coisa boa. Quase sempre leva os desenvolvedores a registrar bugs duplicados, ridículos ou completamente inválidos. Normalmente, você verá muitos deles aparecerem repentinamente no final de um mês / trimestre, enquanto os testadores correm para cumprir as cotas. A única coisa pior do que isso é quando você também penaliza os desenvolvedores com base no número de bugs encontrados em seu código. Suas equipes de teste e desenvolvimento estão trabalhando uma contra a outra naquele momento, e uma não pode ter sucesso sem fazer a outra parecer ruim.

Você precisa manter o foco no usuário aqui. Um usuário não tem idéia de quantos bugs foram arquivados durante o teste, tudo o que vêem é o que foi solucionado. Em última análise, os usuários não se importam se você arquivar 20 relatórios de erros ou 20.000, desde que o software funcione quando o receberem. Uma métrica melhor para avaliar os testadores seria o número de bugs que foram relatados pelos usuários, mas que deveriam ter sido capturados pelos testadores.

É muito mais difícil acompanhar isso. É bastante fácil executar uma consulta ao banco de dados para ver quantos relatórios de bugs foram arquivados por uma pessoa específica, o que suspeito ser o principal motivo pelo qual a métrica "bugs arquivados" é usada por tantas pessoas.

Não há nada de errado em criar um jogo para encontrar bugs. Você encontrou uma maneira de motivar as pessoas. Isso é bom. Também revelou uma falha na comunicação de prioridades. Terminar 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. Será mais como um concurso de pesca. Todos procurarão encontrar o grande erro que obterá 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.

O equilíbrio do jogo de ajuste fino não é uma tarefa simples; portanto, esteja preparado para passar algum tempo acertando isso. Deve comunicar claramente seus objetivos e deve ser divertido. Também será algo que você poderá ajustar conforme as necessidades da empresa mudarem.

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

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

Para começar a mudar 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.

Todos os dias em que pelo menos um bug significativo foi relatado, deixe um token de "Bug do Dia" na mesa do testador. Uma vez por semana, realize uma cerimônia com uma procissão de desenvolvedores que entregam um token ou troféu "Bug of the Week" maior e melhor. Torne 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 bom que o bug fosse encontrado nos testes. Cópias das citações devem ser colocadas em algum lugar onde todos os testadores possam lê-las.

A esperança é que os testadores voltem sua atenção de encontrar mais bugs para coletar mais troféus e fichas. Sua melhor estratégia para fazer isso seria ler as citações e pensar em quais abordagens de teste provavelmente causam erros que os desenvolvedores consideram importantes.

Simplesmente ignore relatórios de bugs sem importância. Como tudo seria muito não oficial e informal, poderia ser desativado ou alterado a qualquer momento.

Isso é bom para o projeto?

Não . Você indicou que observou que isso resulta em relatórios de baixa qualidade que não são direcionados às funcionalidades necessárias e que os testadores acabam, para agravar o problema, lutando para concluir o trabalho que realmente são "supostos" "estar fazendo.

Caso contrário, como posso (como desenvolvedor de software) tentar mudar o pensamento e as atitudes da equipe de testadores?

Levante o problema com seu gerente de projeto. Eles devem considerar esse tipo de coisa como parte de seu trabalho. Se o seu gerente não está disposto ou é incapaz de lidar com isso, você está meio que preso ao desenvolver suas próprias estratégias de enfrentamento. (o que seria uma pergunta diferente)

Penso como será (ou como já é) se continuar assim, você não terá necessariamente uma qualidade inferior. Embora eu ache que isso diminuirá a quantidade / qualidade. Depende se isso é ruim ou não. Depende se

relatar erros sobre aprimoramentos de tela, usabilidade ou erros estúpidos.

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

A razão pela qual eles competem é provavelmente se divertir enquanto trabalham, portanto, provavelmente não pretendem fazer um trabalho ruim (se isso for considerado ruim).