Soy un desarrollador de software. Hay un equipo de evaluadores que siguen y ejecutan casos de prueba escritos por el analista, pero también realizan pruebas exploratorias. Parece que los evaluadores han estado compitiendo para ver quién abre más errores, y he notado que la calidad de los informes de errores ha disminuido. En lugar de probar la funcionalidad y reportar errores relacionados con la operación del software, los evaluadores han estado enviando errores sobre mejoras de pantalla, usabilidad o errores estúpidos.
¿Esto es bueno para el proyecto? Si no es así, ¿cómo puedo (como desarrollador de software) tratar de cambiar el pensamiento y las actitudes del equipo de evaluadores?
Otro problema es porque la fecha límite se estima y no puede cambiar, por lo que a medida que se acerca la fecha límite, los evaluadores se esforzarán por terminar sus casos de prueba, y esto hará que disminuya la calidad de las pruebas. Esto provocará errores legítimos en el producto final recibido por el cliente.
OBS: ¡Esta competencia no es una práctica de la compañía! Es una competencia entre solo los evaluadores organizados por ellos y sin ningún premio.
fuente
Respuestas:
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 la mayoría de los errores". Su objetivo no es encontrar más, 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 la más alta calidad.
Convertirlo en un juego les da un incentivo para concentrarse en encontrar muchos errores poco profundos, en lugar de encontrar los errores más críticos. Como mencionas en tu edición, esto es exactamente lo que está sucediendo en tu organización.
Se podría argumentar que cualquier error que encuentren es un juego justo, y que todos los errores deben ser descubiertos. Sin embargo, dado que su equipo probablemente tiene recursos limitados, ¿preferiría que un probador se concentre varias horas o días investigando profundamente su sistema tratando de encontrar errores realmente grandes, o pasar varias horas o días navegando por la aplicación buscando errores tipográficos y pequeños errores? errores en la alineación de objetos en una página?
Si la compañía realmente quiere hacer un juego con él, dé 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 mueve el incentivo de "encontrar más" a "ser el mejor en hacer su trabajo". Sin embargo , esto tampoco es recomendable, porque un programador y un analista de control de calidad podrían trabajar juntos para rellenar artificialmente sus números.
En pocas palabras: no hagas un juego de encontrar errores. Encuentre formas en su organización para recompensar el buen trabajo y dejarlo así. La gamificación recompensa 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 lo mismo.
fuente
Voy a estar un poco en desacuerdo con las otras respuestas. "Encontrar errores" para un probador es un poco como "escribir código" es para un desarrollador. La cantidad bruta no tiene sentido. El trabajo del probador es encontrar tantos errores que puedan, 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 probador 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 cantidad de líneas de código. Es demasiado fácil ingresar al juego para que el sistema sea útil.
Si desea que los probadores compitan, debe basarse más directamente en lo que tienen que hacer, que es validar que el software funciona como se describe. Entonces, quizás la gente compita para ver quién puede escribir los casos de prueba más aceptados, o incluso mejor, escribir el conjunto de casos de prueba que cubren la mayor cantidad de código.
La mejor medida de la productividad del desarrollador es el número de tareas completadas 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. Desea maximizar eso, no se encontraron errores.
fuente
Según mis experiencias personales, esto no es algo bueno. Casi siempre conduce a que los desarrolladores presenten errores que son duplicados, ridículos o completamente inválidos. Por lo general, verá que muchos de estos aparecen de repente al final de un mes / trimestre a medida que los evaluadores se apresuran a cumplir con las cuotas. Lo único peor que esto es cuando también penalizas 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.
Debe centrarse en el usuario aquí. Un usuario no tiene idea de cuántos errores se archivaron durante las pruebas, todo lo que ven es el que pasó. En última instancia, a los usuarios no les importa si presentas 20 informes de errores o 20,000, siempre que el software funcione cuando lo obtengan. Una mejor métrica para evaluar a los evaluadores sería la cantidad de errores reportados por los usuarios, pero que los evaluadores deberían haber detectado razonablemente.
Sin embargo, esto es mucho más difícil de seguir. Es bastante fácil ejecutar una consulta en la base de datos para ver cuántos informes de errores fueron archivados por una persona específica, lo cual sospecho es la razón principal por la cual tanta gente usa la métrica de "errores archivados".
fuente
No hay nada de malo en crear un juego para encontrar errores. Has encontrado una manera de motivar a las personas. Esto es bueno. También se reveló una falla para comunicar las 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 insecto?
En lugar de calificar el juego simplemente por la cantidad de errores, debe 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. Todo el mundo buscará encontrar el gran error que obtendrá una puntuación de alta prioridad. Haga que la calidad del informe de error sea parte de la puntuación. Haga que los desarrolladores brinden a los evaluadores comentarios sobre la calidad del informe de errores.
Ajustar el equilibrio del juego no es una tarea simple, así que prepárate para pasar un tiempo haciendo esto bien. Debe comunicar tus objetivos claramente y debe ser divertido. También será algo que puede ajustar a medida que cambien las necesidades comerciales.
fuente
Encontrar errores es su trabajo. Siempre y cuando no estén haciendo las cosas menos eficientes (por ejemplo, al abrir un error por cada 10 errores tipográficos en lugar de uno para cubrir varios de ellos), esto los alienta a hacer exactamente lo que se supone que deben hacer, así que No puedo ver muchos inconvenientes.
fuente
Esta es una expansión de la respuesta de @ CandiedOrange .
Para comenzar a cambiar la atención a objetivos más útiles, considere algo muy informal y no oficial. Por ejemplo, los desarrolladores podrían comprar algunas pequeñas fichas y trofeos.
Cada día que se informe de al menos un error importante, deje una ficha de "Error del día" en el escritorio del probador. Una vez a la semana, celebre una ceremonia con una procesión de desarrolladores entregando un token o trofeo "Bug of the Week" más grande y mejor. Haga que la entrega del trofeo "Error del mes" sea aún más dramática, tal vez 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 recoger la mayoría de los trofeos y fichas. Su mejor estrategia para hacerlo sería leer las citas y pensar en qué enfoques de las pruebas pueden generar errores que los desarrolladores considerarán importantes.
Simplemente ignore los informes de errores sin importancia. Como todo sería muy no oficial e informal, podría cerrarse o cambiarse en cualquier momento.
fuente
No se . Usted mismo ha señalado que ha observado que da como resultado 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 en realidad "supuestamente" "estar haciendo.
Plantee el problema con su gerente de proyecto. Deberían considerar este tipo de cosas como parte de su trabajo. Si su PM no está dispuesto o es incapaz de manejarlo, está atascado desarrollando sus propias estrategias de afrontamiento. (que sería una pregunta diferente)
fuente
Creo que será (o cómo es) si sigue así, no necesariamente obtendrás una calidad inferior. Aunque creo que disminuirá la proporción de cantidad a calidad. Depende de si esto es algo malo o no. Depende si
es algo que realmente no quieres. Si esto está claro con los probadores, simplemente les diría que no hagan las cosas que no quieren que se informen, pero que sean claros al respecto. Hágalo cuando uno de esos informes vuelva a aparecer.
La razón por la que tienen una competencia es probablemente para divertirse mientras trabajan, por lo que probablemente no tengan la intención de hacer un mal trabajo (si esto se considera malo).
fuente