bug-tracking - tools - jira

¿Alguna buena estrategia para lidiar con errores ''no reproducibles''? (16)

Muy a menudo obtendrá o enviará informes de errores por defectos que no son reproducibles. Pueden ser reproducibles en su computadora o proyecto de software, pero no en el sistema de un proveedor. O el usuario proporciona pasos para reproducir, pero no puede ver el defecto localmente. Muchas variaciones en este escenario, por supuesto, para simplificar, supongo que lo que estoy tratando de aprender es:

¿Cuál es la política de su compañía hacia los errores ''no reproducibles''? Cállate, cierra, ignora? De vez en cuando veo errores intermitentes, no reproducibles en marcos de terceros, y estos son casi siempre cerrados al instante por el proveedor ... pero son errores reales.

¿Has encontrado alguna técnica que ayude a solucionar este tipo de errores? Por lo general, lo que hago es obtener un informe de información del sistema del usuario y los pasos para reproducir, luego buscar palabras clave y tratar de ver cualquier tipo de patrón.

A veces, el error no es reproducible incluso en un entorno de preproducción que es el duplicado exacto del entorno de producción. Los problemas de concurrencia son conocidos por esto.

La razón puede ser simplemente por el efecto Heisenberg, es decir, la observación cambia el comportamiento. Otra razón puede ser porque las posibilidades son muy pequeñas de alcanzar la combinación de eventos que desencadenan el error.

A veces tienes suerte y tienes registros de auditoría que puedes reproducir, lo que aumenta enormemente las posibilidades de recrear el problema. También puede estresar el ambiente con altos volúmenes de transacciones. Esto comprime el tiempo de manera efectiva, de modo que si ocurre el error, por ejemplo, una vez a la semana, es posible que pueda reproducirlo de manera confiable en 1 día si hace hincapié en el sistema a 7 X la carga de producción.

El último recurso es la prueba de caja blanca en la que se pasan las pruebas unitarias de escritura de línea por línea a medida que avanza.

Agrego el registro al código de manejo de excepciones en todo el programa. Necesita un método para recopilar los registros (los usuarios pueden enviarlo por correo electrónico, etc.)

Las verificaciones preventivas para versiones de código y entornos sanos también son una buena cosa. Con la facilidad de las actualizaciones de software en estos días, es casi seguro que el código y el entorno que el usuario está ejecutando no ha sido probado. No existía cuando lanzaste tu código.

Algunas de las nuevas características en Visual Studio 2010 ayudarán. Ver:

Bueno, hace todo lo posible por reproducirlo y, si no puede, piensa mucho y considera cómo podría surgir ese problema. Si aún no tienes idea, no hay mucho que puedas hacer al respecto.

Con un proyecto web que estoy desarrollando en este momento estoy haciendo algo muy similar a tu técnica. Estoy creando una página a la que puedo dirigir a los usuarios para recopilar información, como la versión de su navegador y el sistema operativo. También voy a recopilar la información del registro de aplicaciones para que pueda echar un vistazo a lo que han estado haciendo.

Este es un problema muy real. Solo puedo hablar para el desarrollo web, pero los usuarios rara vez me pueden dar la información básica que necesitaría para analizar el problema. Sospecho que es completamente posible hacer algo similar con otros tipos de desarrollo. Mi plan es seguir trabajando en este sistema para hacerlo más útil.

Pero mi política nunca es cerrar un error simplemente porque no puedo reproducirlo, no importa cuán molesto pueda ser. Y luego están los casos en que no es un error, pero el usuario simplemente se ha confundido. Que es un tipo diferente de error, supongo, pero igual de importante.

Es importante categorizar tales errores (raramente reproducibles) y actuar sobre ellos de manera diferente a los errores que con frecuencia son reproducibles en función de las acciones específicas del usuario.

Descripción clara del problema junto con los pasos para reproducir y observar el comportamiento : los informes no ambiguos ayudan a comprender el problema al eliminar todo el equipo las conclusiones incorrectas. Por ejemplo, la pantalla en blanco que informa al usuario es diferente a la congelación de HMI en la acción del usuario. La secuencia de pasos y el tiempo aproximado de acción del usuario también son importantes. ¿Seleccionó el usuario la opción inmediatamente después de la transición de pantalla o esperó unos minutos? Un error interesante con respecto a la sincronización es un automóvil alérgico al helado de vainilla que desconcertó a los ingenieros automotrices.
Configuración del sistema y parámetros de inicio : A veces, incluso la configuración del hardware y la versión del software de la aplicación (incluidos los controladores y la versión del firmware) pueden hacer un truco o dos. La falta de coincidencia de la versión o la configuración puede dar lugar a problemas que son difíciles de reproducir en otras configuraciones. Por lo tanto estos son detalles esenciales para ser capturados. La mayoría de las herramientas de informe de errores tienen estos detalles como parámetros obligatorios para informar al registrar un problema.
Registro extenso : esto depende de las instalaciones de registro seguidas en los proyectos en cuestión. Mientras trabajamos con sistemas Linux integrados, no solo proporcionamos registros de diagnóstico generales, sino también registros a nivel de sistema como dmesg o registros de comandos principales. Quizás nunca sepa que la parte incorrecta no es el flujo de código sino el uso anormal de memoria / uso de CPU. Identifique el tipo de problema e informe los registros relevantes para la investigación.
Revisiones de código y recorrido : los equipos de desarrollo no pueden esperar eternamente para reproducir estos problemas al final y luego actuar. El informe de errores y los registros disponibles deben investigarse y varias posibilidades deben identificarse sobre esta base a partir del diseño y el código. Si es necesario, deben preparar el hotfix sobre las posibles causas raíz y hacer circular el hotfix entre los equipos, incluido el probador que lo identificó para ver si el error es reproducible con él.
No cierre estos problemas basándose en la observación de un único evaluador / equipo después de identificar y corregir una solución : Quizás la parte más importante es el enfoque seguido para cerrar estos problemas. Una vez que se haya revisado la solución de estos problemas, se debe informar a todos los equipos de prueba / validación en diferentes ubicaciones para que realicen pruebas intensivas e identifiquen los errores de regresión, si los hay. Solo todos (prácticamente la mayoría de ellos) de los informes no reproducibles, una evaluación de cierre debe ser realizada por la alta gerencia.

Hay una nueva característica en Windows 7 que le permite al usuario grabar lo que está haciendo y luego enviar un informe: se presenta como un documento con capturas de pantalla de cada etapa. Esperemos que sea de ayuda en los casos en los que el usuario interactúe con la aplicación en un orden que el desarrollador no piense. He visto muchos errores en los que es solo un caso que la forma lógica en que el desarrollador utiliza la aplicación no encaja con la forma en que los usuarios finales realmente lo hacen ... lo que resulta en muchos errores sutiles.

Informes de errores, archivos de registro y demandas severas de "Comuníquese conmigo de inmediato si esto sucede nuevamente".

La respuesta aceptada es el mejor enfoque general. A un alto nivel, vale la pena sopesar la importancia de corregir el error con lo que podría agregar como una característica o mejora que beneficiaría al usuario. ¿Podría un error ''no reproducible'' tardar dos días en solucionarse? ¿Se podría agregar una característica en ese tiempo que ofrezca a los usuarios más beneficios que esa corrección de errores? Tal vez los usuarios preferirían la característica. A veces me he fijado como desarrollador en las imperfecciones que puedo ver, y luego a los usuarios se les pide comentarios y ninguno de ellos menciona los errores que puedo ver, pero al software le falta una característica que realmente quieren. !

A veces, la persistencia simple en el intento de reproducir el error mientras que la depuración puede ser el enfoque más efectivo. Para que esta estrategia funcione, el error debe ser "intermitente" en lugar de completamente "no reproducible". Si puede repetir un error incluso una vez en 10, y tiene ideas sobre el lugar más probable en el que se está produciendo, puede colocar puntos de interrupción en esos puntos y luego tratar de repetir el error y ver exactamente qué está sucediendo. He experimentado que esto es más efectivo que el registro en uno o dos casos (aunque el registro sería mi primer intento en general).

Si no se pueden reproducir registros de reproducción, se pueden reproducir capturas de pantalla de los pasos exactos.

Si sucede en un contexto, y no en otro, tratamos de enumerar la diferencia entre ambos y eliminarlos.

A veces esto funciona (por ejemplo, otro hardware, dual core vs. hyperthreading, disco de computadora portátil vs. disco de estación de trabajo, ...).

A veces no es así. Si es posible, podemos iniciar la depuración remota. Si eso no ayuda, podemos intentar tener en nuestras manos el sistema del cliente.

Pero, por supuesto, no escribimos demasiados errores en primer lugar :)

Usted habla de problemas que son reproducibles pero solo en algunos sistemas. Estos son fáciles de manejar:

Primer paso: al utilizar algún tipo de software remoto, deja que el cliente le diga qué hacer para reproducir el problema en el sistema que lo tiene. Si esto falla, entonces ciérralo.

Segundo paso: Intenta reproducir el problema en otro sistema. Si esto falla, haga una copia exacta del sistema de clientes.

Tercer paso: si aún falla, no tiene otra opción que intentar depurarlo en el sistema del cliente.

Una vez que puedas reproducirlo, puedes arreglarlo. No importa en qué sistema.

Los problemas delicados son problemas realmente no reproducibles, es decir, cosas que suceden solo de manera intermitente. Para eso tendré que intervenir con los informes, los registros y la actitud de las severas exigencias. :)

El registro es tu amigo!

En general, lo que sucede cuando descubrimos un error que no podemos reproducir es que le pedimos al cliente que active más registros (si está disponible), o lanzamos una versión con registros adicionales agregados alrededor del área en la que estamos interesados. El registro que tenemos es excelente y tiene la capacidad de ser muy detallado, por lo que no es frecuente lanzar versiones con registro adicional.

También debe considerar el uso de volcados de memoria (que IMO también cae bajo el paraguas del registro). Producir un minidump es tan rápido que generalmente se puede hacer en servidores de producción, incluso bajo carga (siempre que el número de volcados producidos sea bajo).

La forma en que lo veo: poder reproducir un problema es agradable porque le brinda un entorno en el que puede depurar, experimentar y jugar de forma más libre, pero reproducir un error no es de ninguna manera esencial para solucionarlo . Si el error solo está ocurriendo en el sistema de otra persona, entonces todavía debe diagnosticar y depurar el problema de la misma manera, es solo que esta vez debe ser más inteligente sobre cómo hacerlo.

Respuesta corta: realice una revisión detallada del código sobre el código sospechoso defectuoso, con el objetivo de corregir cualquier error teórico y agregar código para monitorear y registrar cualquier falla futura.

Respuesta larga: para dar un ejemplo del mundo de sistemas integrados en el mundo real: fabricamos equipos industriales, que contienen componentes electrónicos personalizados y software integrado que se ejecuta en ellos.

Un cliente informó que varios dispositivos en un solo sitio experimentaban la misma falla a intervalos aleatorios. Sus síntomas eran los mismos en cada caso, pero no pudieron identificar una causa obvia.

Obviamente, nuestro primer paso fue tratar de reproducir la falla en el mismo dispositivo en nuestro laboratorio, pero no pudimos hacerlo.

Entonces, en cambio, distribuimos el código sospechoso dentro del departamento para intentar obtener la mayor cantidad de ideas y sugerencias posibles. Luego, celebramos una serie de reuniones de revisión de códigos para discutir estas ideas y determinar una teoría que: (a) explicó la causa más probable de las fallas observadas en el campo; (b) explicó por qué no pudimos reproducirlo; y (c) condujo a mejoras que podríamos hacer al código para evitar que la falla ocurra en el futuro.

Además de las correcciones de errores (teóricas), también agregamos monitoreo y código de registro, por lo que si la falla volviera a ocurrir, podríamos extraer datos útiles del dispositivo en cuestión.

Por lo que yo sé, este software mejorado se implementó posteriormente en el sitio y parece haber tenido éxito.

resuelto "estéril" y "espeluznante"

Tenemos dos categorías de errores cerrados para esta situación.

estéril - no se puede reproducir.

espeluznante : se reconoce que hay un problema, pero solo aparece de forma intermitente, no es del todo comprensible y le da a todos un caso débil de escalofríos.

Verifique los pasos utilizados para producir el error.

A menudo, las personas que informan del error, o las personas que reproducen el error, harán algo mal y no terminarán en el mismo estado, incluso si creen que lo están. Trate de explicarlo con la parte que reporta. He tenido un usuario INSIST que los privilegios de administrador no aparecían correctamente. Intenté reproducir el error y no pude. Cuando lo recorrimos juntos, resultó que estaba ingresando como un usuario regular en ese caso.

Verifique el sistema / entorno utilizado para producir el error.

He encontrado muchos errores ''irreproducibles'' y solo más tarde descubrí que se pueden reproducir en Mac OS (10.4) con la versión X de Safari. Y esto no se aplica solo a los navegadores y al renderizado, se puede aplicar a cualquier cosa; las otras aplicaciones que se están ejecutando actualmente, ya sea que el usuario sea RDP o local, administrador o usuario, etc ... Asegúrese de que su entorno esté lo más cerca posible de ellos antes de llamar irreproducible.

Reúne capturas de pantalla y registros

Una vez que haya verificado que el usuario está haciendo todo correctamente y sigue recibiendo un error, y que está haciendo exactamente lo que está haciendo, y que NO está recibiendo el error, entonces es hora de ver qué puede hacer realmente al respecto. Capturas de pantalla y registros son críticos. Quiere saber exactamente qué aspecto tiene, y exactamente qué estaba sucediendo en ese momento.

Es posible que los registros contengan cierta información que pueda reproducir en su sistema, y una vez que pueda reproducir el escenario exacto, podría ser capaz de persuadir al error de que no lo oculte.

Las capturas de pantalla también ayudan con esto, porque podrías descubrir que "la pieza X se ha cargado correctamente, pero no debería haberlo hecho porque depende de Y" y eso podría darte una pista. Incluso si el usuario puede describir lo que estaba haciendo, una captura de pantalla podría ayudar aún más.

Reúna paso a paso la descripción del usuario

Es muy común culpar a los usuarios, y no confiar en nada de lo que dicen (porque llaman a ''usercontrol'' a ''thingy''), pero aunque no sepan los nombres de lo que están viendo, aún podrán hacerlo. Describe algunos de los comportamientos que están viendo. Esto incluye algunos errores menores que pueden haber ocurrido unos minutos ANTES de que se haya producido el error real, o posiblemente una lentitud en ciertas cosas que generalmente son rápidas. Todas estas cosas pueden ser pistas para ayudarlo a reducir qué aspecto está causando el error en su máquina y no en la suya.

Intente enfoques alternativos para producir el error

Si todo lo demás falla, intente buscar en la sección de código que está causando problemas y posiblemente refactorice o use una solución alternativa. Si es posible crear un escenario en el que comience con la mitad de la información que ya existe (con suerte en UAT), pida al usuario que intente ese enfoque y vea si el error continúa. ¿Es mejor crear enfoques alternativos pero similares que lleven el error a una luz diferente para que pueda examinarlo mejor?