¿Cómo redactar un buen informe de error? Buenas prácticas

El seguimiento, la notificación y la corrección de errores son procesos integrales en el desarrollo de software. Entre todas estas tareas, informar puede parecer la menos importante, pero no es así. Cuanto mejor sea el informe, antes se solucionará el fallo. A su vez, si el informe no proporciona todos los detalles esenciales o lo hace de forma incorrecta, arreglar el fallo llevará más tiempo, esfuerzo y dinero.

Hemos recopilado las prácticas más eficientes sobre informes de fallos que serán útiles para los probadores de control de calidad principiantes.

¿Cómo redactar un informe de error? Ejemplos y prácticas recomendadas

Has detectado un fallo, así que tu siguiente paso es informar de él. Estas son las recomendaciones para crear un informe de error eficaz.

Facilite todos los datos esenciales

Un buen informe de error tiene que contener:

Número de error

Cada informe debe tener un identificador de fallo único: se utiliza para hacer referencia a un problema específico cuando se discute, se prioriza y se soluciona. Si utiliza una herramienta automatizada de notificación de errores (o algo más universal como Jira), el número se creará automáticamente y se añadirá a su informe.

Título

El título debe explicar brevemente qué es lo que falla. Por ejemplo, “El botón Contactar no funciona”. Echando un vistazo al título, su equipo se hará una idea básica del problema y comprenderá si se ha producido antes.

Medio ambiente

Si no especificas el entorno, puede que sea imposible reproducir el fallo. Por ejemplo, has detectado un error en la versión iOS de la aplicación. Después, un desarrollador intentó reproducirlo en la versión de Android, pero no pasó nada: todo funcionaba bien. Este tipo de situaciones son posibles, así que facilite siempre detalles sobre el entorno. Pueden incluir lo siguiente:

• – Dispositivo (especifique el modelo exacto)
• – Sistema operativo y su versión
• – Cuenta utilizada
• – Versión de la aplicación
• – Navegador y su versión
• – Tipo de conexión

Pasos para reproducir

Cualquier fallo debe ser reproducible, de lo contrario, no se solucionará. Por lo tanto, al crear tu informe, describe paso a paso qué acciones conducen a la aparición del fallo. No te olvides de nada, ni siquiera de los detalles más obvios, como iniciar sesión en el sistema. También sería útil intentar reproducir el fallo por tu cuenta varias veces, y luego especificar cuántos intentos tuvieron éxito en términos de activación del fallo.

Resultado esperado

Explique lo que debería ocurrir si sigue los pasos de reproducción cuando todo funciona correctamente. Si retomamos el ejemplo de “El botón Contactar no funciona” una vez más, el resultado esperado puede ser el siguiente: “Aparece el formulario de contacto”.

Resultado real

Aquí debes describir el fallo en sí. ¿Qué ocurre después de seguir todos los pasos de reproducción? ¿Qué falla? He aquí un ejemplo: “El formulario de contacto no aparece”.

Prueba

Adjunte imágenes y vídeos: esto acelerará el proceso de reproducción de errores.

Gravedad

¿En qué medida es crítico el fallo? ¿Qué impacto tiene en la funcionalidad del sistema? Esta información ayudará a los responsables a priorizar sus tareas, lo que es especialmente importante cuando hay numerosos fallos que corregir. Por ejemplo, un fallo que bloquea el uso de una aplicación debe marcarse como crítico, pero si hay algo como una errata en la copia, puede marcarse como trivial.

Su nombre

Especifique su nombre y datos de contacto para que los desarrolladores puedan ponerse en contacto con usted fácilmente. Esto puede ser necesario en caso de que no utilices ningún software de pruebas especial para la notificación de errores.

 

Antes de pasar a la siguiente recomendación, echa un vistazo a este ejemplo de un buen informe de errores en Jira. Incluye el número de fallo (generado automáticamente), el título, el entorno, los pasos de reproducción (junto con una condición previa), los resultados esperados y reales, el vídeo, la prioridad y el nombre del informador:

Sea específico

Evita escribir un ensayo entero: debes ceñirte al punto y ser específico. Basta con proporcionar todos los detalles esenciales (los hemos descrito en el párrafo anterior), explicar claramente qué es exactamente lo que falla y cómo reproducir el fallo, y ya está.

No vacile

Cuando detectes un fallo, no pospongas la creación del informe. Hazlo de inmediato; de lo contrario, puedes olvidar algunos pasos esenciales para su reproducción o simplemente olvidarte de escribir un informe. Esto es especialmente importante en el caso de errores críticos que deben solucionarse lo antes posible.

Vuelva a comprobar el informe

Cuando hayas terminado de redactar el informe, léelo una vez más. ¿Pueden malinterpretarse algunas frases? ¿Hay algo que no quede claro? Si es así, soluciona estos problemas antes de enviar el informe. Si no lo haces, arreglar el fallo te llevará más tiempo.

Evitar las críticas

Obviamente, los fallos son irritantes, pero criticar a los desarrolladores no hará que tu informe sea mejor y más eficaz. Sé discreto (aunque el fallo sea muy molesto o se produzca una vez más después de haber sido corregido), y limítate a describir claramente el problema. Recuerda, un buen informe es un informe escrito en un lenguaje sencillo y seco, sin abusos.

Utilizar herramientas y servicios

Estas son algunas de las herramientas y servicios más:

Reflexiones finales

Para crear un buen informe de fallo, tienes que ser específico y proporcionar todos los detalles, como el número de fallo, el título, el entorno, los pasos de reproducción, el resultado esperado y el real, capturas de pantalla y/o vídeos, la gravedad y tu nombre junto con los datos de contacto. Redacta tus informes en un lenguaje claro, no critiques a los desarrolladores y comprueba dos veces los informes antes de enviarlos. Y, obviamente, no dudes en escribir y enviar tus informes: hazlo justo después de detectar un fallo.

En cuanto a herramientas y servicios, Jira es una de las opciones más populares y cómodas, y es posible que tu equipo ya la esté utilizando. Si es así, no descuides sus funciones. En cualquier caso, todo el equipo debería utilizar una única plataforma para la gestión de proyectos, ya que así se garantiza una colaboración adecuada y una finalización eficaz de las tareas. Sin embargo, algunas herramientas (como Bird Eats Bug) pueden utilizarse de forma independiente gracias a sus funciones de integración.