¡Gran viernes a todos, amigos! A finales de junio, estamos lanzando un nuevo grupo en el curso de
Especialista en
Control de Calidad , que será el foco de la publicación de hoy.
Hay muchos indicadores por los cuales puede medir la efectividad del equipo de evaluadores. Uno de ellos es el índice de defectos rechazados, o el número de informes de error rechazados dividido por el número total de informes recibidos. Debe pensar que si el número de informes rechazados es cero, entonces eso es bueno, pero no es tan simple. Veamos los tipos de errores rechazados, veamos cómo afectan la tasa de errores rechazados y calculemos la proporción correcta para su equipo.
Hay tres categorías de errores rechazados:
- Errores irreproducibles;
- Errores incorrectos
- Errores duplicados
Comencemos con los propios errores.
Errores irreproducibles
Hay dos tipos de errores irreproducibles. El primero es un error que es realmente difícil de reproducir. Esto puede ser un error resultante de la interacción de varios parámetros, algunos de los cuales ni siquiera conoce.
Suponga que realizó varias pruebas seguidas, y una de las pruebas cambió el parámetro de configuración del valor predeterminado A a otro valor B. El error ocurre solo cuando el parámetro de configuración contiene el valor B y el valor de entrada es C. Cuando Al intentar reproducir el error, lo más probable es que desee comenzar con un estado conocido para inicializar el sistema (o, posiblemente, realizar una instalación limpia). No se producirá ningún error porque el parámetro de configuración ahora nuevamente contiene el valor predeterminado A.
Otra variante de este tipo de error irreproducible es cuando la prueba realmente encontró un defecto, pero no hay datos en la información de reproducción: un paso, un valor de entrada específico o la comprensión de que el error ocurre solo con un determinado procedimiento. Como resultado, los intentos de reproducir el error no conducen a nada.
Sin embargo, en los dos casos anteriores, hay un defecto en el producto en sí.
El segundo tipo de error irreproducible es cuando el error no puede repetirse porque no existe. Es posible que el probador haya notado algo, pero lo haya malinterpretado, o que el sistema utilizado para las pruebas tenga algún tipo de problema, como un componente de hardware defectuoso, un controlador incompatible o una configuración de acceso incorrecta. Los intentos de reproducir el error en un sistema configurado correctamente fallan.
Estos dos tipos de errores generalmente se marcan en los sistemas de informe de errores como "rechazados, no se pueden reproducir".
Errores incorrectos
Este tipo de error ocurre si el probador decide que el producto debe comportarse de cierta manera e informa un error cuando el comportamiento no cumplió con sus expectativas. Sin embargo, un estudio más detallado de los requisitos muestra que las expectativas del probador eran erróneas y que el producto realmente funcionaba correctamente. Es decir, el producto probado funcionó correctamente y el probador, que no estaba suficientemente familiarizado con los requisitos, cometió un error.
Dichos errores generalmente se marcan en los sistemas de informe de errores como "rechazado - no error" o "rechazado - por la arquitectura" (es decir, el comportamiento es coherente con la arquitectura).
Errores duplicados
Los errores repetidos son aquellos errores que uno ya ha informado, y el siguiente informa después. Un error es repetitivo solo si los "síntomas" de su apariencia son los mismos. Y si la causa raíz del error es la misma, pero los "síntomas" resultaron ser diferentes, ¡esto no es una repetición del error!
Estos errores generalmente se marcan en los sistemas de informe de errores como "rechazados - duplicados / repetidos".
Cómo los errores rechazados afectan a un equipo
Obviamente, un error incorrecto es una especie de pérdida de tiempo que el evaluador dedicó a reproducir el error e informarlo, el tiempo que los que clasifican los errores pasan leyéndolos y entendiéndolos, y el tiempo que los desarrolladores pasan tratando de reproducir un error irreproducible o para arreglar (y mal funcionamiento) algo que no necesitaba esta solución.
Además del hecho de que el índice de error rechazado o RDR es una medida de la ineficiencia del equipo de evaluadores, también habla sobre la profesionalidad de los evaluadores en general. Un error que no se puede reproducir debido a la falta de información necesaria en el informe indica que los evaluadores no fueron meticulosos y no trabajaron lo suficiente para reproducir este error siguiendo los pasos descritos anteriormente. Además, para los errores que se reproducen con poca frecuencia, los evaluadores generalmente no notaron la baja frecuencia de reproducción en el informe.
La aparición de un error incorrecto indica que los evaluadores no entienden completamente los requisitos del producto. Los errores repetidos indican que los evaluadores no realizaron una búsqueda mínima en la base de datos de errores local para verificar si ocurrió antes. O significa que el especialista que informó este error no fue el primero en incluir las palabras clave correctas en el nombre para facilitar la búsqueda de sus otros colegas.
A su vez, si resulta que el error que encontré es rechazado, estoy resentido porque me consideraron un laico. Por un lado, esto significa que defenderé los errores encontrados. Cuando mi informe es rechazado, procedo de la siguiente manera:
- Compruebo nuevamente si el error se está reproduciendo en mi sistema y agrego los pasos de reproducción si me perdí algo;
- Si mi malentendido de los requisitos fue causado por un requisito ambiguo o documentación incorrecta, insistiré en que el error se marque como un error de documentación y se cierre solo cuando la documentación se corrija;
- Si creo que el comportamiento del producto cuando se cumple el requisito es incorrecto, hablaré sobre los requisitos con arquitectos y desarrolladores, trataré de convencerlos de que los requisitos deben actualizarse (al final, ¡represento la opinión del cliente!);
- Si el error se rechaza como un duplicado, me aseguraré de que no esté marcado de la misma manera o que no aparezca "de acuerdo con el mismo escenario".
Por otro lado, una cierta probabilidad de rechazo de error me hace cauteloso. Si no estoy completamente seguro de haber encontrado un error, pasaré un poco más de tiempo antes de informar. A menudo le pregunto a un colega si interpreto los requisitos correctamente, o verifico si el error se reproduce en el sistema de otra persona.
Opinión en contra de la ausencia total de errores rechazados
El equipo de prueba debe monitorear y esforzarse por reducir el nivel de RDR. La única pregunta es, ¿qué RDR debe considerarse bueno?
A primera vista, parece que 0% es el resultado óptimo, pero estoy totalmente en desacuerdo con esto. Creo que cuando la RDR se mantiene en un nivel saludable, esto es normal, porque si está cerca de cero, el equipo de prueba obviamente sufre problemas no menos graves que, por ejemplo, una RDR excesivamente alta.
El equipo de prueba debe hacer grandes esfuerzos para lograr una RDR extremadamente baja. Cada error rechazado se analizará para comprender qué salió mal, y cada evaluador que informó un error rechazado tendrá que explicar qué sucedió realmente y cómo se puede evitar tal situación en el futuro. Como resultado, los evaluadores informarán errores en los que estén absolutamente seguros.
Si notan un comportamiento que creen que dañará la usabilidad del producto, preferirán darlo por sentado, en lugar de justificar que han encontrado un error que, de hecho, no es un error basado en los requisitos. Si tienen evidencia de que ha ocurrido un error, pero no hay un buen escenario para reproducirlo, preferirán no informarlo; Realmente no quieren molestarse. Si encuentran un error frívolo, pueden decidir no informarlo en absoluto, porque los errores menores no siempre lo solucionan, entonces, ¿por qué arriesgarse y tener miedo de que el error que encontró sea rechazado?
En resumen, luchar por una RDR muy baja causa estrés y un comportamiento poco saludable en el equipo de prueba, y también aumenta la probabilidad de que algunos errores pasen desapercibidos.
Necesitamos probadores que no solo reporten errores obvios, sino que también adviertan cualquier comportamiento sospechoso en el proyecto. Creemos que los probadores que otorgan gran importancia a garantizar que el error no se escape, incluso a costa de los informes duplicados, son mejores que los probadores que pasan horas comprobando si un error ya se ha informado en los informes o no, por temor a que hacer un duplicado Queremos que los evaluadores se sientan cómodos al cuestionar la palabra del arquitecto del sistema o la especificación de requisitos, incluso si eso significa que algunos de sus errores se marcarán como rechazados.
Necesitamos probadores que no tengan miedo de cometer errores de vez en cuando. Esto significa que se necesita equilibrio, por lo que se considera aceptable una pequeña RDR.
Encontrar el coeficiente de defecto óptimo rechazado
Mi regla general es que la RDR debe ser del 15 por ciento. Este valor se basa en mi experiencia con el equipo probador, que, según todas las cuentas, fue un equipo bueno y efectivo. Fue nuestro RDR durante varios proyectos que se sucedieron uno tras otro, mientras que el otro equipo, que trabajó en los mismos proyectos y en paralelo con nosotros, aunque era menos consciente del producto y se consideraba menos efectivo, tenía un 30% de RDR .
No creo que haya otra justificación para este significado que no sea mi sentimiento interior. Esto definitivamente no es científico. No discutiré con un equipo que esté dirigido al 10 o 20 por ciento, pero creo que soportar un 30 por ciento o establecer una meta del 5 por ciento ya es un problema.
Al final, esta es una decisión que debe tomar el equipo probador, en función de las características del producto, el nivel de experiencia del equipo, el modelo de desarrollo, la experiencia del equipo de desarrollo y mucho más. Le recomiendo que vigile RDR y piense si necesita hacer algo con él. Y si es demasiado alto o bajo, se deben tomar las medidas apropiadas.
Por tradición, esperamos sus comentarios y lo invitamos a un
seminario web gratuito , que se realizará el 14 de junio. Hasta pronto!