¿Es bueno que los evaluadores compitan para ver quién abre más errores?

No creo que sea bueno que hagan un concurso para encontrar la mayoría de los errores. Si bien es cierto que su trabajo es encontrar errores, su trabajo no es "encontrar los más errores". Su objetivo no es encontrar el máximo, su objetivo es ayudar a mejorar la calidad del software. Recompensarlos por encontrar más errores es casi lo mismo que recompensar a un programador por escribir la mayoría de las líneas de código, en lugar del código de mayor calidad.

Convertirlo en un juego les da un incentivo para centrarse en encontrar muchos errores poco profundos, en lugar de encontrar los errores más críticos. Como mencionó en su edición, esto es exactamente lo que está sucediendo en su organización.

Uno podría argumentar que cualquier error que encuentren es un juego justo, y que todos los errores deben ser descubiertos. Sin embargo, dado que es probable que su equipo tenga recursos limitados, ¿preferiría que un evaluador se centre varias horas o días investigando su sistema tratando de encontrar errores realmente grandes, o pasara varias horas o días saltándose la aplicación en busca de errores tipográficos y pequeños ¿Errores en la alineación de objetos en una página?

Si la compañía realmente quiere hacer un juego fuera de él, otorgue a los desarrolladores el poder de agregar puntos a un error. los "errores estúpidos" obtienen puntos negativos, los errores difíciles de encontrar con informes bien escritos obtienen múltiples puntos Esto luego mueve el incentivo de "encontrar lo más" a "ser el mejor haciendo tu trabajo". Sin embargo, esto tampoco se recomienda, ya que un programador y un analista de control de calidad podrían trabajar juntos para rellenar sus números de forma artificial.

En pocas palabras: no hagas un juego de encontrar errores. Encuentre formas en su organización para recompensar el buen trabajo y déjelo así. La gamificación premia a las personas por alcanzar una meta. No desea que un analista de control de calidad tenga el objetivo de "encontrar la mayoría de los errores", desea que su objetivo sea "mejorar la calidad del software". Esos dos objetivos no son los mismos.

Voy a estar en desacuerdo un poco con las otras respuestas. "Encontrar errores" para un probador es un poco como "escribir código" es para un desarrollador. La cantidad en bruto no tiene sentido. El trabajo del probador es encontrar la mayor cantidad de errores que puedan existir, no encontrar la mayoría de los errores. Si el probador A encuentra 5 de los 10 errores en un componente de alta calidad y el probador B encuentra 58 de los 263 errores en un componente de baja calidad, entonces el probador A es el mejor probador.

Desea que los desarrolladores escriban la cantidad mínima de código para resolver un problema en particular, y desea que un evaluador escriba la cantidad mínima de informes que describen correctamente el comportamiento roto. Competir para encontrar la mayoría de los defectos es como competir para escribir la mayoría de las líneas de código. Es demasiado fácil deslizarse en el juego para que el sistema sea útil.

Si desea que los evaluadores compitan, debería basarse más directamente en lo que deben hacer, que es validar que el software funciona como se describe. Así que quizás la gente compita para ver quién puede escribir los casos de prueba más aceptados, o mejor aún, el conjunto de casos de prueba que cubren la mayor parte del código.

La mejor medida de la productividad del desarrollador es la cantidad de tareas que se completan por la complejidad de la tarea. La mejor medida de la productividad del probador es el número de casos de prueba ejecutados por la complejidad del caso de prueba. Quieres maximizar eso, no los errores encontrados.

Basado en mis experiencias personales, esto no es algo bueno. Casi siempre lleva a los desarrolladores a archivar errores que son duplicados, ridículos o completamente inválidos. Por lo general, verá que muchos de estos aparecen repentinamente al final de un mes / trimestre a medida que los evaluadores se apresuran a cumplir con las cuotas. Lo único peor es que también penaliza a los desarrolladores en función de la cantidad de errores encontrados en su código. Sus equipos de prueba y desarrollo están trabajando uno contra el otro en ese momento, y uno no puede tener éxito sin hacer que el otro se vea mal.

Necesitas mantener tu enfoque en el usuario aquí. Un usuario no tiene idea de cuántos errores se archivaron durante la prueba, todo lo que ven es el que logró pasar. En última instancia, a los usuarios no les importa si presenta 20 informes de errores o 20,000, siempre y cuando el software funcione cuando lo obtengan. Una mejor métrica para evaluar a los evaluadores sería la cantidad de errores informados por los usuarios, pero que deberían haber sido detectados por los probadores.

Sin embargo, esto es mucho más difícil de rastrear. Es bastante fácil ejecutar una consulta en la base de datos para ver cuántos informes de errores fueron presentados por una persona específica, lo cual sospecho que es la razón principal por la que la gente usa la métrica "errores archivados".

No hay nada de malo en hacer un juego para encontrar errores. Has encontrado una manera de motivar a la gente. Esto es bueno. También se reveló un fallo en la comunicación de prioridades. Terminar el concurso sería un desperdicio. Necesitas corregir las prioridades.

Pocos juegos reales tienen un sistema de puntuación simple. ¿Por qué debería cazar el error?

En lugar de calificar el juego simplemente por la cantidad de errores que necesitas para proporcionar una medida de la calidad del informe de errores. Entonces el concurso es menos sobre el número de errores. Será más como un concurso de pesca. Todos estarán buscando el gran error que obtendrá una puntuación de alta prioridad. Hacer que la calidad del informe de error sea parte de la puntuación. Haga que los desarrolladores proporcionen a los evaluadores comentarios sobre la calidad del informe de errores.

El equilibrio del juego de ajuste fino no es una tarea simple, así que prepárate para dedicar algo de tiempo a hacerlo bien. Debe comunicar sus metas claramente y debe ser divertido. También será algo que puede ajustar a medida que cambien las necesidades del negocio.

Encontrar errores es su trabajo. Mientras no hagan que las cosas sean menos eficientes (por ejemplo, al abrir un error para ech de 10 errores tipográficos en lugar de uno para cubrir varios de ellos), esto les anima a hacer exactamente lo que se supone que deben hacer, así que No puedo ver mucho de un inconveniente.

Esta es una expansión en la respuesta de @ CandiedOrange.

Para comenzar a cambiar la atención hacia objetivos más útiles, considere algo muy informal y no oficial. Por ejemplo, los desarrolladores podrían comprar algunos tokens y trofeos pequeños.

Cada día que se reportó al menos un error significativo, deje una ficha "Error del día" en el escritorio del probador. Una vez a la semana, realice una ceremonia con una procesión de desarrolladores que entreguen un token o trofeo "Bug of the Week" más grande y mejor. Haz que la entrega de trofeos "Bug of the Month" sea aún más dramática, quizás con pastel. Cada ficha o trofeo debe ir acompañado de una cita que indique por qué los desarrolladores pensaron que era bueno que se encontrara un error en las pruebas. Se deben colocar copias de las citas en algún lugar donde todos los evaluadores puedan leerlas.

La esperanza es que los evaluadores cambien su atención de encontrar la mayoría de los errores a recolectar la mayoría de los trofeos y fichas. Su mejor estrategia para hacerlo sería leer las citas y pensar acerca de qué enfoques de prueba pueden sacar a la luz los errores que los desarrolladores considerarán importantes.

Simplemente ignore los informes de errores no importantes. Dado que todo sería muy no oficial e informal, podría cerrarse o cambiarse en cualquier momento.

  

¿Esto es bueno para el proyecto?

No . Usted mismo ha señalado que ha observado que resulta en informes de baja calidad que no están dirigidos a la funcionalidad requerida, y que los evaluadores terminan, para agravar el problema, luchando para completar el trabajo que realmente son "supuestos". "estar haciendo.

  

Si no, ¿cómo puedo (como desarrollador de software), intentar cambiar el   ¿Pensamiento y actitudes del equipo de testers?

Plantea el problema con tu Project Manager. Deben considerar este tipo de cosas como parte de su trabajo. Si su PM no está dispuesto o es incapaz de lidiar con él, está estancado desarrollando sus propias estrategias de afrontamiento. (que sería una pregunta diferente)

Pienso cómo será (o cómo ya es) si sigue así, no necesariamente obtendrás una calidad inferior. Aunque creo que disminuirá la relación cantidad a calidad. Depende de si esto es algo malo o no. Depende si

  

informar de errores sobre mejoras en la pantalla, facilidad de uso o errores estúpidos.

es algo que realmente no quieres. Si esto queda claro con los evaluadores, les diría que no hagan las cosas que no quieren que se informen, pero que lo tengan claro. Hágalo cuando aparezca nuevamente uno de esos informes.

La razón por la que tienen una competencia es para divertirse mientras trabaja, por lo que probablemente no tengan la intención de hacer un mal trabajo (si esto se considera malo).