¿Qué información se solicita en la resolución de un problema en la caja de un cliente mediante una aplicación de escritorio?

Question

escribir una aplicación de escritorio de Windows que se instala en unos pocos miles de ordenadores que no tenemos acceso a. Cuando uno de estos usuarios informa de un error, incluso si la descripción es bastante completo, hay otra información que pueda ser útil.

Actualmente estamos trabajando en un agente de voto automatizado, lo que significa que tendremos acceso a información muy detallada. Pero como un niño en una tienda de dulces, no estamos seguros de por dónde empezar. ¿Qué información incluir en su paquete de retroalimentación en el mismo caso? ¿Qué es útil para ayudar a reproducir existe error?

Lo que tenemos hasta ahora es:

• El número de versión de nuestra aplicación,
• sistema operativo y versión del sistema operativo número
• información del proxy
• versión .NET y número de actualización
• Información específica para nuestra aplicación (por ejemplo. versiones de datos)
• Acceso y registros de errores

Nota sin embargo, que esto es similar a esta pregunta , no son tan interesado en obtener información cuando el programa se bloquea como estamos como cuando el usuario experimenta un error.

Editar: Aclaración: no pedir la información que el usuario debe dar en el caso de un error, sino más bien lo que la información debe reunir programmaticaly

Answer 1

Incluso si usted tiene toda esa información, que reproduce el problema puede ser difícil. Cuando los usuarios describen cómo crearon el error que a menudo están equivocados acerca de los pasos clave - es difícil para ellos saber qué áreas son fundamentales cuando no conocen el funcionamiento interno de la aplicación. Es posible que desee poner en práctica una forma de seguimiento de las acciones del usuario, tales como el manejo de eventos de nivel raíz o algún otro medio - si usted tiene la funcionalidad de deshacer / rehacer entonces estoy seguro de que esto sería suficiente. A continuación, podría incluir los últimos pasos (x) de la cadena de acción en el informe de errores.

Answer 2

Editar: Creo que leí mal su pregunta. Pensé que estamos hablando acerca de qué información obtener de un cliente informar de un error, en vez de pensando ya en lo que describo aquí. Lo dejo para referencia de todos modos.

En una situación similar, a pesar de un menor número de usuarios, nuestra aplicación tiene un "registro del paquete de apoyo" botón que va a crear un archivo zip con todos los archivos de registro y el archivo de proyecto abierto actualmente, en su caso. Toda otra información que ha descrito ya forma parte de uno de los archivos de registro. De esta manera, un cliente puede enviar convenientemente el archivo ZIP en nosotros, lo que se puede hacer desde la ventana principal de la aplicación sin necesidad de abrir un archivo de proyecto o la conexión a una interfaz de red, que son los dos puntos principales donde algo puede salir mal. Esto hace que sea mucho más fácil que confiar en que el usuario proporcionar retroalimentación "a mano".

Aparte de eso, los pasos exactos para reproducir el problema deben estar disponibles. La mayor parte de esto es por lo general en el propio archivo de proyecto (que se encuentra en el archivo ZIP que obtenemos), con sólo unos pocos pasos que faltan.

Las cosas que parecían ser importantes para esto, aparte de lo que ya se enumeran a continuación:

• Usuario / información de la cuenta. Esto puede ayudar con problemas de permisos. Es posible que desee incluir cosas como zona horaria, la configuración regional, tema de Windows.
• configuración de aplicaciones, incluyendo, cuando está instalado.
• Como se ha dicho ya, el archivo actual, el usuario está trabajando, porque esto puede ser la causa del problema.
• Configuración de usuario, es decir, los datos de la aplicación almacena por usuario. Visto cosas extrañas con estos. lista MRU también puede ser útil.

Answer 3

Aparte del estado básico de la aplicación (versión, configuración, etc.), la información más importante a conseguir es:

• El paso (s) requerida para reproducir el error o fallo de funcionamiento, incluyendo las entradas utilizadas si es posible
• El resultado esperado
• La salida real
• Información de contacto en caso de que necesite seguimiento (si su software es consumido de manera anónima)

Eso será suficiente información para resolver el 99,9% de los problemas. Por lo demás, el seguimiento y obtener toda la información detallada crees que va a ayudar a resolver el problema (que, con suerte, será mucho mejor entendida en este punto).