Hacer que los usuarios escriban informes de errores útiles y decentes

¿Alguien sabe una buena manera de hacer que los usuarios escriban un informe de error semi-decente (léase: útil ) ?

Queríamos poner algo que tuviera sentido para la mayoría de los usuarios (ser fácil de leer y comprender), pero también brindar información útil a los desarrolladores.

¡No funciona cuando hago clic en el botón azul! Ahhh, acabo de perder el trabajo de una semana ... haz que funcione.

no es muy útil, como lo es.

Empecé a arreglar una lista, pero pensé en consultar con ustedes, si ya existe un método similar.

La forma más efectiva de lograr que los usuarios escriban informes de errores útiles y decentes es

1. para que puedan ver sus informes en línea ...
   ^{[Sistema] Gracias por informar, puede encontrar el estado de su solicitud aquí: ...}
2. ... junto con la evaluación y los comentarios del ingeniero asignado ...
   ^{[Ingeniero] Solicitud rechazada, porque faltan los siguientes detalles: ...}
3. ... con una opción para editar / mejorar su informe.
   ^{[Usuario] Se agregan los detalles solicitados, vuelva a evaluar: ...}

Iría tan lejos como para afirmar que es la única forma efectiva.

Seamos realistas, la habilidad para escribir informes de errores efectivamente solo viene con experiencia. Uno necesita aprender a ganar experiencia. Aprender implica practicar, obtener retroalimentación y mejorar.

Los informes de errores en línea editables por el usuario son la forma más eficiente de enseñar a los usuarios a mejorar .

• ^{Las opciones alternativas a las anteriores son 1) para organizar sesiones de aprendizaje cara a cara con los usuarios (sí, claro, especialmente cuando hay miles de ellos repartidos por todo el mundo). O 2) explíqueles las cosas por teléfono ("mire, si solo pudiera ver la basura que escribió en la línea 225 ..."). ¿Qué más? Oh 3) por correo electrónico, seguro "en el correo que nos enviaste hace dos meses, mencionaste ... no, no ese correo electrónico, nos enviaste cinco correos electrónicos este día, tres de ellos con el asunto Re: clic en el botón azul , mira la segunda, la que tiene una captura de pantalla de 10Mb adjunta ... ¿qué? ¿no puedes encontrarla? "}

En mi opinión, lo más importante es usar el error para establecer un contacto significativo con el usuario. Escribir y comprender los informes de errores es una habilidad, y mi consejo sería que sea lo más fácil posible para el usuario hacer el primer contacto, y luego hacer progresivamente sus comentarios de mayor valor según sea necesario.

Por ejemplo, solo obtenga el correo electrónico del usuario y dele un campo de texto sin formato con el siguiente texto para completar:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Después de recibir el correo electrónico, responda automáticamente para obtener una doble opción para confirmar que enviaron el error, que lo recibió y que el seguimiento del error está bien.

Puede considerar tomar algunas ideas de Mozilla y Sun sobre este tema:

• Pautas para escribir errores - Artículo de Mozilla MDN
• Cómo escribir un error adecuado - Artículo de Mozilla QMO
• Cómo escribir un informe de error útil - Artículo de Sun SDN

Particularmente (de la página de Mozilla "Cómo escribir un error apropiado"):

Esquema general de un informe de error

Resumen : ¿Cómo describirías el error en menos de 60 caracteres? Debe identificar rápida y exclusivamente un informe de error, así como explicar el problema, no su solución sugerida.

Bien : "La cancelación de un cuadro de diálogo Copia de archivo bloquea el Administrador de archivos"

Malo : "El software falla"

Malo : "El navegador debería funcionar con mi sitio web"

Componente : ¿En qué subparte del software existe? Este campo es un requisito para enviar cualquier informe de error. Haga clic en la palabra "Componente" para ver una descripción de cada componente. Si ninguno parece apropiado, resalte el componente "General".

OS : ¿En qué sistema operativo (OS) lo encontraste? (p. ej., Linux, Windows XP, Mac OS X.) Ejemplo: "Si sabe que el error ocurre en más de un tipo de sistema operativo, elija" Todos ". Si su sistema operativo no está en la lista, elija Otro ".

Descripción : los detalles de su informe de problemas, que incluyen:

- Descripción general : Esta es una reexpresión detallada más grande del resumen. Un ejemplo sería: "Arrastrar al seleccionar cualquier página bloquea las compilaciones de Mac en la función NSGetFactory".

- ID de compilación : para encontrar esto, vaya a la página "acerca de" a través de la barra de ubicación o, si tiene la extensión de MozQA's Nightly Tester Tools, vaya a Herramientas | Herramientas del probador nocturno y seleccione la opción que contiene el resultado de la Id. Debería verse más o menos así: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3".

- Compilaciones y plataformas adicionales : si el error se produce o no en otras plataformas (o navegadores, si corresponde). Debería verse así: “No ocurre en Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Pasos para reproducir : pasos minimizados y fáciles de seguir que activarán el error. Si es necesario, asegúrese de incluir pasos especiales de configuración. Un buen ejemplo de esto sería el siguiente: 1) Ver cualquier página web. (Utilicé la página de muestra predeterminada, http://www.google.com/ ). 2) Arrastra y selecciona la página. Específicamente, mientras mantiene presionado el botón del mouse, arrastre el puntero del mouse hacia abajo desde cualquier punto en la región de contenido del navegador hasta la parte inferior de la región de contenido del navegador.

Resultados reales : lo que hizo la aplicación después de realizar los pasos anteriores. Un ejemplo sería: la aplicación se bloqueó.

Resultados esperados : lo que la aplicación debería haber hecho, si el error no estuviera presente. Un ejemplo sería: la ventana debería desplazarse hacia abajo. Se debe seleccionar el contenido desplazado. O, al menos, la aplicación no debería bloquearse.

Hay cómo informar errores de manera efectiva por Simon Tatham. Explica bien las cosas, para que sea fácil de entender para los usuarios menos experimentados. Sin embargo, la desventaja es que es bastante texto. Cuando un usuario intenta informar un problema pero no lo explica, por lo general no podrá convencerlo de que lea todo esto.

Puede hacer preguntas fáciles de entender y responder a los usuarios para esperar informes útiles.

Por ejemplo, "¿Cuál fue su última acción antes de este error?", "¿Intentó ... justo antes de este error?".

Ningún usuario le escribiría un informe de error como: "Mi controlador de video no está actualizado. Es posible que su biblioteca de gráficos no sea compatible con controladores gráficos antiguos".

Asumiendo que la base de usuarios son usuarios finales que han tenido un problema con el software que escribió ...

No es tarea de los usuarios convertirse en un ingeniero de software competente o un profesional de pruebas, y no debe esperar que lo hagan. Sus usuarios son personas promedio que con razón esperan que el software "simplemente funcione". Cuando no sea así, informarán lo que crean que prestan atención para llamar su atención. No puede cambiar eso, y no debe intentarlo. Cualquier intento de insistir en el tipo de informes que se espera que haga un profesional dará como resultado la pérdida del informe de error, y el cliente: "Tuve un problema con ese software, pero en lugar de ayudarme, se completaron todos tipos de formas inútiles que no significan nada y no tienen ningún valor para mí. Iré a buscar algún software que realmente funcione ".

es decir, no es su trabajo .....

Si desea buenos informes de errores, contrate a profesionales para encontrarlos. Si usted, como desarrollador de software, no puede molestarse en tratar con los clientes, contrate a alguien que pueda hacerlo.