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

32

¿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.

Torre
fuente
2
Podía entender votar por cerrar a los programadores, pero ¿fuera del tema? ¿Informes de errores en el sitio de un programador?
Torre
1
¿Importa? Escribirán informes de errores malos de todos modos. Lo que normalmente debe hacer es comunicarse con los usuarios de alguna manera.
David Thornley
@DavidThornley: estamos en una especie de industria específica. Con la mayoría de los usuarios nunca me comunico ni recibo esos informes unos meses después. No preguntes
Torre
3
Cree el mecanismo de informes en su aplicación, de modo que el usuario pueda hacer clic en un botón, agregar un comentario y que la aplicación adjunte el estado apropiado. "Ahora, haga clic en la ubicación en la pantalla donde está mal" ...
3
Avísame si encuentras una respuesta. Tengo suficientes problemas para obtener informes de errores útiles de los probadores, no importa los usuarios.
Kristof Provost

Respuestas:

16

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? "
mosquito
fuente
27

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.

errores
fuente
2
Gran respuesta. Breve y comunicativo. Voy a robar esto en el futuro para explicar a la gente.
Erik Dietrich
Esta también debería ser la plantilla con la que comienzan las preguntas SO.
Cody Piersall
55
Hice pulse el botón azul , y esperaba que las cosas funcionen , pero nada sucedió en su lugar. : D
Songo
"Hice _____ y ​​esperaba que ______ sucediera, pero ______ sucedió en su lugar". Estaba usando el software ______ versión _____ en el entorno de producción / qa / prueba.
kubanczyk
10

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

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.

Brian Snow
fuente
10
Realmente no entiendo por qué esto obtuvo tantos votos. La pregunta no es "¿cómo escribir un informe de error decente?" pero "cómo hacer que los usuarios escriban un informe de error decente".
Tamás Szelei
8
Esos recursos están principalmente destinados a personas técnicas. También Mozilla es la organización que nos trajo Bugzilla. No estoy diciendo que Bugzilla es malo, pero ha sido hecho por los ingenieros para ingenieros: En realidad no es una herramienta para el usuario final en absoluto .
Joachim Sauer
3
Tengo que estar de acuerdo con @fish. Podemos dar a nuestros evaluadores todas las pautas en el mundo, no hace que realmente produzcan informes de errores útiles. Y estoy hablando de personas cuyo trabajo es informar de errores: si no podemos motivarlos con pautas, no tenemos ninguna esperanza con los usuarios reales. Lo único que encontramos efectivo fue cerrar activamente los informes de errores "inútiles" como "no hay suficiente información"; entonces recibieron el mensaje bastante rápido. Sin embargo, no lo aconsejo para usuarios externos :-)
HappyCat
3
No estoy discutiendo la utilidad de la publicación en absoluto (recursos bastante buenos allí, en realidad), pero esto no responde a la pregunta, y creo que la política de votación se basa en eso (podría estar equivocado).
Tamás Szelei
1
Soy el tipo de persona a la que estaba dirigido e incluso no podía sentarme a leer todo el asunto. ¿Qué te hace pensar que los usuarios van a ir?
Tacroy
4

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.

Wladimir Palant
fuente
4

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".

Mert Akcakaya
fuente
3

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.

Mattnz
fuente
1
No creo que el OP esté diciendo que no quieren tratar con los usuarios. Creo que el OP dice que realmente no pueden arreglar nada basado en el informe de error 'se estrelló'. El OP quiere una forma de aprovechar al máximo a los usuarios que se quejan, para que el OP pueda solucionar el problema.
Michael Kohne
1
Mi punto es que si "se estrelló" es lo que sucede desde la perspectiva del usuario. Cuando llevo mi automóvil a un mecánico, no espera que le dé un informe de diagnóstico detallado por expertos de lo que está mal; me hace preguntas para ayudarlo a usar su experiencia para diagnosticar el problema. Por ejemplo, en una visita, mi problema fue "Se detiene cuando hace frío, pero está bien cuando hace calor", algunas preguntas bien consideradas (con sí y sin respuestas) después estaba bastante seguro (y resultó ser correcto) que era un error termómetro. Nuestro trabajo es hacer las preguntas, enmarcadas para dar sí, no respuestas.
mattnz