¿Cómo se aplica o mantiene la calidad de los informes de errores en su rastreador de errores?

Question

Los informes de fallas de alta calidad son esenciales para el seguimiento eficaz de errores: en un mundo ideal, todos los informes de errores contendrían información esencial, como la versión del software afectada y una descripción paso a paso de cómo reproducir el error.

En realidad, sin embargo, los errores reportados pueden variar mucho en calidad. Pueden estar en línea ("la característica X no funciona, ¡arréglenlo!"), Solicitudes de funciones, PEBKAC o ininteligibles.

¿Cómo se aplica o se mantiene la calidad de los informes de errores en su rastreador de errores para que siga siendo efectivo?

Answer 1

Estoy de acuerdo con Jon Limjap: su personal de control de calidad debe ser lo suficientemente competente como para publicar los informes de errores adecuados, teniendo en cuenta la formación básica y las directrices adecuadas. Sin embargo, hay maneras de hacer cumplir y fomentar una mejor notificación de errores:

• La mayoría del software de seguimiento de errores tienen una forma de marcar algunos campos del informe de error como obligatorios, por lo que el reportero tiene que elegir realmente el valor apropiado con el fin para crear con éxito el fallo
• por lo general hay una posibilidad de incluir una plantilla básica para el informe de error, algo en las líneas de

Escenario:

Resultados esperados:

resultados reales:

Observación:

• Usted puede (y debe) proporcionar una herramienta de errores de reporte que se ejecuta en la máquina problemática, recopilar la información relevante y empaquételo en un archivo de almacenamiento (y tal vez colóquelo en el escritorio). A continuación, instruya a su personal para que lo ejecute siempre que encuentren un error que deseen informar y adjunte el archivo al error. Esta herramienta debe ser fácil de usar (solo ejecutar un ejecutable) para que puedan adjuntar la información de diagnóstico a cualquier error sin tener que pensar si es relevante o no. Esta herramienta también suele ser muy útil con los clientes.
• Por último, pero no menos importante: "educación, educación, educación". La gente aprende mejor de la experiencia: solo asegúrate de que cada vez que alguien abre un error sin la información adecuada incluida, la persona que maneja el error vaya y hable con quien abrió el error y explique qué es lo que falta y por qué es importante.

Estas son prácticas que hemos estado utilizando con bastante éxito en mi lugar de trabajo actual y creo que son bastante universales para adaptarse a la mayoría de los entornos de trabajo.

Answer 2

Esto depende de si usted está hablando de una revisión de control de calidad cerrado y una versión beta pública.

Si se trata de una versión beta pública, no es aconsejable permitir a los usuarios editar directamente la lista de errores. Alguien debe ser asignado para agregar comentarios e informes de los usuarios y discernir cuáles son errores reales y cuáles son duplicados y cuáles dan alguna pista sobre cómo replicarlos.

Si esto, sin embargo, es un elemento de error publicado por su personal de control de calidad legítimo, tiene un problema de competencia con respecto a sus empleados. Deben establecerse pautas apropiadas sobre cómo informar errores, especialmente al obtener pasos de replicación correctos.

Answer 3

Pregunta difícil. Intentaré ver si el sistema tiene alguna forma de exigir que se ingresen ciertos campos que usted requiera, intente y tenga los errores críticos cruzando sus ojos de alguna manera (correo electrónico, rss) para que pueda atacar rápidamente, pero principalmente eso su equipo conoce el estándar de calidad y lo mantiene, las pautas se publican y son públicas, ese tipo de cosas.

Suponiendo que sea su equipo: Si puede tener una cierta estructura que se usa siempre en un campo de comentarios, de lo que se espera cuando se ingresa, eso también sería bueno, incluso mejor si su software tiene una las notas predeterminadas describen dónde puede definir esa estructura en un formulario en blanco.

Hasta cierto punto, depende del individuo, tienen que ser conscientes de que es parte de los estándares de comunicación, se espera como un requisito de trabajo, y que son responsables ante todos los demás miembros del equipo, porque otras personas no deberían estar en condiciones de buscarlos para averiguar más detalles si pudieran evitarse.

Especialmente porque el tiempo de respuesta para corregir errores en elementos de prioridad más baja podría ser algo de tiempo y la gente se olvidará de los detalles.

Asumiendo que sean sus usuarios: No se puede en un alto grado, pero trataría, si es posible, de hacer preguntas en cualquier forma de manera que la gente pueda entender.

No del todo sobre este tema, pero en una especie de "cómo hacer las preguntas" de manera, es este post en 37 Señales de blog - link text

Incluso si usted tiene que tener otra forma de hacer las preguntas visible para Sus usuarios, que solo alimentan principalmente los datos al programa de errores, lo harían solo para hacer las preguntas correctas.

¿Qué producto? ¿Qué versión (imágenes que muestran cómo encontrarla)? Sería útil incluir un volcado de pantalla, si pudieran abrir el programa y presionar un botón para enviarlo a través de un archivo de registro automáticamente, ya sea que les impidió seguir trabajando, si perdió sus cambios, etc.

Para los usuarios, probablemente sea más acerca de cómo hacer las preguntas y decirles que necesita que se respondan algunas, o cuáles serían más útiles, entonces probablemente obtendría mejores respuestas.

Answer 4

Escriba un tutorial bueno pero no demasiado extenso sobre el uso del rastreador y qué se requiere para cada campo. Haga un ejemplo de referencia de propósito general que otros puedan usar si se estancan.

Tengo una copia de referencia para editar las páginas del manual de Docbook y al usar esto repetidamente ya sé la mayoría de la sintaxis de memoria.

Answer 5

Solía ​​pensar que la calidad del informe de errores era equivalente. Sigo pensando que sí ... los errores que informe tienen mucha más información útil que los ingresados ​​por QA o por Operations. Sin embargo, he llegado a admirar el modelo de FogBugz. Es extremadamente simple ingresar un error. Solo saber que hay una condición de error es útil, incluso si no hay mucha información de respaldo. Además, los usuarios sienten que algo se está haciendo.

Answer 6

Use algo como UserVoice para que los usuarios finales informen errores y solicitudes de funciones. Las entradas del rastreador de errores realmente deberían ser internas: son demasiado técnicas para los usuarios finales y también, en mi humilde opinión, exponen un poco de trabajo interno.