A veces, mi equipo de control de calidad informa de errores, pero ni yo ni ellos tenemos idea de cómo reproducirlos. Esto lleva a sesiones de depuración muy largas y frustrantes que a veces ni siquiera producen resultados.

Mi software está fuertemente vinculado con hardware propietario, por lo que los errores pueden venir de muchas direcciones a la vez.

¿Debería esperar más de ellos que "su software se bloqueó cuando presioné un botón" o debería imaginarme qué sucedió?

EDITAR:

Uno de mis compañeros de trabajo señaló que probablemente todos somos desarrolladores aquí, por lo que los resultados podrían sufrir un pequeño sesgo

El control de calidad siempre debe intentar que los errores sean tan fáciles de reproducir como sea posible y la descripción del error debe contener los pasos tomados.

Sin embargo, si no pueden reproducir fácilmente los errores, aún así deberían ingresar a la base de datos de errores con títulos / títulos adecuados y una descripción completa de lo que hicieron para causar el error. La descripción del error debe indicar claramente que no pueden reproducir el error (tal vez con algún comentario en la línea de "lo intenté cinco veces, sucedió una vez"). De esta manera, si alguien más ve el mismo error, puede agregar a la base de datos de errores con sus hallazgos y también obtener la mayor cantidad de información posible, lo que más adelante podría ser vital para ahorrar tiempo en rastrear el problema.

Además, puede filtrar la información: puede haber muchos errores en diferentes sistemas que sabe que están vinculados (por ejemplo) a un área del código, si el control de calidad no informa nada (ya que no pueden reproducirlos) ) entonces esta información no te llega.

Parece que su departamento de control de calidad está haciendo demasiadas pruebas exploratorias (es decir, no tienen un buen plan de prueba).

Las pruebas exploratorias son buenas e identifican áreas problemáticas, pero a partir de ahí deberían definir casos de prueba reproducibles (es decir, un plan de prueba) para realizar que revelarán errores específicos.

Hay una serie de razones por las cuales es necesaria una reproducción correcta (no solo buena, sino necesaria):

1. Debe reprobar para poder depurar / localizar la causa.
2. El control de calidad deberá poder verificar la solución una vez que haya terminado.
3. Otros pases de prueba deberán hacer regresiones sobre errores anteriores.
4. Los errores conocidos se pueden descartar si la exposición es demasiado pequeña o la reproducción es muy poco probable.

Entonces, como señala SteveCzetty: Ciérrelo sin reproches y vuelva a trabajar.

Si el error no se puede reproducir de forma coherente, ¿cómo sabrá QA si se solucionó?

Sí, deberías esperar más de ellos. Deberían poder decir:

1. Comenzó una nueva instancia del programa
2. Presioné el botón A
3. Ingresó "texto de prueba" en el campo NOMBRE DE PRUEBA en el Formulario # 1
4. Botón presionado B
5. Observó que el programa se bloqueó con este mensaje (ver captura de pantalla adjunta).

Si todo lo que dicen es "se estrelló", no son muy buenos. Incluso si los pasos anteriores no son 100% reproducibles, una muestra suficientemente grande de estos accidentes podría ayudar a reducir la causa, una vez que se detecta un patrón.

Mi consejo es leer esos errores y darles una buena idea. Si no puede descubrir una causa potencial, olvídese de ellos por ahora.

El control de calidad debe documentar cada problema que encuentren, incluso si no tienen idea de cómo sucedió. El trabajo de QA es tratar de reproducir problemas, pero de manera realista, esto no siempre será posible. A veces no tiene nada que ver con lo que hicieron en los últimos 10 minutos. Algo entró en un estado inválido hace un día, y se hizo evidente debido a uno de los últimos 10 pasos.

Con estos errores "1 en 1000", QA debería intentar reproducirlos por un momento. Si no tienen éxito, deben documentar el error y luego intentar un poco más.

La razón por la que deberían ingresar el error bastante pronto es que el programador conoce el código mucho mejor que el control de calidad, y puede saber el problema de inmediato. Podría ser el código que refactorizaron. Podría ser esa función que implementaron a medias y luego olvidaron. Puede que no tengan idea, pero no tiene sentido que el probador pierda algunas horas tratando de reproducir un problema que es obvio para la persona que lo codificó. El probador siempre puede agregar más detalles al error más adelante.

El error debe incluir tanta información como sea posible. Cualquier cosa que el probador pueda recordar sobre el período previo al problema debe escribirse con doloroso detalle. También se deben adjuntar todos los registros de bloqueo, instantáneas de la base de datos o capturas de pantalla relevantes.

Si el error nunca se reproduce, ¡genial! No hace daño tenerlo en la base de datos. Si se lanza el programa y un usuario informa un error similar más tarde, puede comparar su experiencia con lo que está en el informe y buscar cualquier similitud.

En mi experiencia, los errores más jugosos no se encuentran en los siguientes planes de prueba. A veces hay que dejar que las cosas se cuezan durante algunas semanas para que la luna y las estrellas se alineen y causen un error desagradable. Si QA puede hacer un trabajo de detective y encontrar algunas causas posibles, dele una palmada en la espalda. Pero a veces, ¿quién sabe lo que pasó?

Muchos errores no son reproducibles hasta que sepa cómo solucionarlos. Eso no significa que no necesitan ser reparados. Arreglé un error el año pasado que todavía no sé cómo reproducir. Requiere una combinación extraña de un error de transmisión sincronizado con precisión junto con datos basura muy específicos en una determinada ubicación de memoria en la pila. Desafortunadamente, uno de nuestros clientes tiene la "suerte" de tener esa condición todo el tiempo.

Por lo tanto, de todos modos, aliente el control de calidad para que incluya pasos de reproducibilidad siempre que sea posible, pero no los culpe si no pueden. A veces le ayudará a saber dónde agregar el registro. A veces, todo lo que hace es decirle qué no causa el error, pero un informe de error siempre es útil.

Si quiere decir que el control de calidad debe incluir los pasos para reproducir el error si pueden, entonces la respuesta es sí. Si quiere decir que si solo graban errores que son capaces de reproducir, entonces absolutamente no. Los errores son errores, ya sea que solo sucedan a la medianoche en luna llena o cada vez que lo miras. Algunos errores no son deterministas (el ejemplo clásico es una variable no inicializada, donde el valor recogido es semialeatorio), eso no significa que no deben registrarse, investigarse y, si es posible, repararse.

Los errores no reproducibles generalmente deben tener una prioridad baja, pero definitivamente deben registrarse.

OMI, deberías. El control de calidad no está haciendo su trabajo si no pueden darle ningún paso de reproducción. No pierda su tiempo tratando de reproducir algo que no puede, simplemente ciérrelo como "No se puede reproducir" y continúe.

Tu tiempo es mucho más valioso que eso.

Un informe de error debe contener:

• pasos para reproducir
• Comportamiento real
• Comportamiento esperado

P.ej:

• Eliminé todos los proveedores de la base de datos (usando DELETE * FROM tSuppliers), abrí el cuadro de diálogo de proveedores e hice clic en la lista desplegable Proveedor.
• La lista contenía el siguiente mensaje: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Cuando hice clic en el mensaje, la aplicación desapareció de la pantalla y del Administrador de tareas.
• Esperaba ver una lista vacía o (preferiblemente) un mensaje como "No se encontraron proveedores". Al hacer clic en la lista vacía o el mensaje no debería tener efecto. La aplicación obviamente no debería desaparecer sin previo aviso bajo ninguna circunstancia.

Entonces, sí, debe contener los pasos para reproducirse. El hecho de que no sientan la necesidad de incluir esto parece indicar que piensan que su trabajo es "romper el software", en lugar de identificar fallas.

El control de calidad debería poder reproducir los errores en función de los pasos introducidos. Si se esforzaron, aún no pudieron reproducirse, aún deberían ingresar los errores con todos los detalles que tienen con la marca de tiempo para que los desarrolladores puedan echar un vistazo a la aplicación y depurar los registros para obtener más detalles.

El dinero está en juego aquí. ¿Por qué cualquier miembro del equipo debería ser capaz de crear una tarea mal definida y con pocas posibilidades de éxito que agobia a un desarrollador (con suerte) altamente pagado?

No se trata de jerarquizar el orden, la jerarquía, la arrogancia, nosotros contra ellos, ni nada de eso. Esto se trata de invertir en actividades que agregan valor al producto.

Cuando se puede demostrar que un problema afecta de manera negativa y medible el valor del producto, entonces debe investigarse, reproducirse y repararse. Arregle la tubería de defectos de su producto para filtrar el ruido.

su equipo de control de calidad es una mierda

Acérquese a ellos y dígales que lean un documento que cualquier evaluador profesional debe haber impreso directamente dentro de sus cerebros (una vez fui evaluador y todavía lo tengo allí mismo, en mi cerebro): Cómo informar errores de manera efectiva .

En particular, apúntelos a la sección "Muéstrame cómo mostrarme" :

Esta es la era de Internet. Esta es la era de la comunicación mundial. Esta es la era en la que puedo enviar mi software a alguien en Rusia con solo tocar un botón, y él puede enviarme comentarios al respecto con la misma facilidad. Pero si tiene un problema con mi programa, no puede tenerme parado frente a él mientras falla. "Muéstrame" es bueno cuando puedes, pero a menudo no puedes.

Si tiene que informar un error a un programador que no puede estar presente en persona, el objetivo del ejercicio es permitirle reproducir el problema. Desea que el programador ejecute su propia copia del programa, le haga lo mismo y haga que falle de la misma manera. Cuando pueden ver el problema frente a sus ojos, pueden lidiar con él ...

Si comienzan a gritarle quejándose de que "los insectos pueden venir de muchas direcciones a la vez" , dígales que apestan aún más de lo que pensaba antes. Dígales que la capacidad de prueba es una característica que deberían evaluar entre otras características del proyecto y que deberían invertir esfuerzos para hacer que esta característica sea correcta.

• Las mejoras de testabilidad que uno podría obtener cuando hay un probador profesional enfocado en eso podría ser muy mágico. Lo aprendí yo mismo hace unos meses. Un ingeniero de control de calidad que trabaja con nuestro equipo me dio un puñado de solicitudes de prueba para desarrollar algunos componentes en nuestra aplicación. Las cosas que me preguntó no tenían mucho sentido para mí, pero se las di asumiendo que él sabe mejor como profesional. Poco después de que terminé, se le ocurrió una herramienta que redujo los esfuerzos de prueba por orden de magnitud . Dijo que la mayor parte se basó en estas solicitudes crípticas que implementé, imagínense.