¿Por qué un buen informe de error?

Si su informe de error es eficaz, entonces sus posibilidades de ser arreglado son mayores. Así que arreglar un fallo depende de la eficacia con la que lo reportes. Informar de un error no es más que una habilidad y voy a explicar cómo lograr esta habilidad.

«El objetivo de escribir un informe de problemas (informe de errores) es conseguir que se arreglen los errores» – Por Cem Kaner. Si un probador no está reportando un error correctamente, lo más probable es que el programador rechace este error declarándolo como irreproducible.

Esto puede herir la moral de los probadores y a veces también el ego. (Sugiero no mantener ningún tipo de ego. El ego es como «He reportado el error correctamente», «Puedo reproducirlo», «¿Por qué él / ella ha rechazado el error?», «No es mi culpa», etc.).

¿Cuáles son las cualidades de un buen informe de error de software?

Cualquiera puede escribir un informe de error. Pero no todo el mundo puede escribir un informe de error eficaz.

Debería ser capaz de distinguir entre un informe de error medio y un buen informe de error. Cómo distinguir entre un buen y un mal informe de Bug? Es muy sencillo, aplique las siguientes características y técnicas para informar de un fallo.

Las características y técnicas incluyen

#1) Tener un número de fallo claramente especificado: Asigne siempre un número único a cada informe de error. Esto, a su vez, le ayudará a identificar el registro de errores. Si utiliza una herramienta de notificación de fallos automatizada, este número único se generará automáticamente cada vez que notifique el fallo.

Anote el número y una breve descripción de cada fallo que notifique.

#2) Reproducible: Si su fallo no es reproducible, nunca se arreglará.

Debe mencionar claramente los pasos para reproducir el fallo. No asuma ni omita ningún paso de reproducción. Un fallo que se describe paso a paso es fácil de reproducir y arreglar.

#3) Sea específico: No escriba un ensayo sobre el problema.

Sea específico y vaya al grano. Intente resumir el problema en un mínimo de palabras pero de forma efectiva. No combine varios problemas aunque parezcan similares. Escriba informes diferentes para cada problema.

Informe de errores eficaz

El informe de errores es un aspecto importante de las pruebas de software. Un informe de Bug eficaz se comunica bien con el equipo de desarrollo y evita la confusión o la mala comunicación.

Un buen informe de Bug debe ser claro y conciso sin que falten puntos clave. Cualquier falta de claridad conduce a malentendidos y ralentiza el proceso de desarrollo. La redacción y el informe de defectos es una de las áreas más importantes pero descuidadas en el ciclo de vida de las pruebas.

Una buena redacción es muy importante para presentar un error. El punto más importante que un probador debe tener en cuenta es no utilizar un tono de mando en el informe. Esto rompe la moral y crea una relación de trabajo poco saludable. Utiliza un tono sugerente.

No des por hecho que el desarrollador ha cometido un error y por eso puedes utilizar palabras duras. Antes de informar, es igualmente importante comprobar si se ha informado del mismo error o no.

Un error duplicado es una carga en el ciclo de pruebas. Compruebe la lista completa de errores conocidos. En ocasiones, los desarrolladores podrían haber conocido el problema y haberlo ignorado para una futura versión. También se pueden utilizar herramientas como Bugzilla, que busca automáticamente los errores duplicados. Sin embargo, es mejor buscar manualmente cualquier error duplicado.

La información importante que debe comunicar un informe de error es «¿Cómo?» y «¿Dónde?» El informe debe responder claramente cómo se realizó la prueba y dónde se produjo el defecto exactamente. El lector debe reproducir fácilmente el fallo y encontrar dónde está el fallo.

Tenga en cuenta que el objetivo de escribir el informe de fallos es permitir al desarrollador visualizar el problema. Él/ella debe entender claramente el defecto a partir del informe de Bug. Recuerde dar toda la información relevante que el desarrollador está buscando.

También, tenga en cuenta que un informe de error se conservará para su uso futuro y debe estar bien escrito con la información requerida. Utilice frases con sentido y palabras sencillas para describir sus fallos. No utilice frases confusas que hagan perder el tiempo al revisor.

Informe de cada fallo como una cuestión independiente. En caso de múltiples problemas en un solo informe de error, no puede cerrarlo a menos que todos los problemas se resuelvan.

Por lo tanto, es mejor dividir los problemas en errores separados. Esto asegura que cada error puede ser manejado por separado. Un informe de error bien escrito ayuda al desarrollador a reproducir el error en su terminal. Esto les ayuda a diagnosticar el problema también.

¿Cómo informar de un error?

Use la siguiente plantilla de informe de error simple:

Este es un formato de informe de error simple. Puede variar dependiendo de la herramienta de informe de errores que esté utilizando. Si usted está escribiendo un informe de error manualmente, entonces algunos campos deben ser mencionados específicamente como el número de error, que debe ser asignado manualmente.

Reportero: Su nombre y dirección de correo electrónico.

Producto: En qué producto ha encontrado este fallo.

Versión: La versión del producto si la hay.

Componente: Son los principales submódulos del producto.

Plataforma: Mencione la plataforma de hardware en la que ha encontrado este fallo. Las diversas plataformas como ‘PC’, ‘MAC’, ‘HP’, ‘Sun’, etc.

Sistema operativo: Mencione todos los sistemas operativos en los que ha encontrado el fallo. Sistemas operativos como Windows, Linux, Unix, SunOS, Mac OS. Mencione también las diferentes versiones del sistema operativo, como Windows NT, Windows 2000, Windows XP, etc., si procede.

Prioridad: ¿Cuándo debe corregirse un error? La prioridad se establece generalmente de P1 a P5. P1 como «arreglar el fallo con la mayor prioridad» y P5 como «arreglar cuando el tiempo lo permita».

Severidad: Describe el impacto del fallo.
Tipos de gravedad:

• Bloqueador: No se pueden realizar más trabajos de comprobación.
• Crítico: Caída de la aplicación, Pérdida de datos.
• Mayor: Pérdida de función mayor.
• Menor: Pérdida menor de la función.
• Trivial: Algunas mejoras de la interfaz de usuario.
• Mejora: Solicitud de una nueva función o alguna mejora en la existente.

Estado: Cuando se registra el error en cualquier sistema de seguimiento de errores, por defecto el estado del error será ‘Nuevo’.
Más tarde, el error pasa por varias etapas como Fijo, Verificado, Reabierto, No se va a arreglar, etc.

=> Haga clic aquí para leer más sobre el ciclo de vida del error detallado.

Asignar a: Si sabe qué desarrollador es responsable de ese módulo en particular en el que se produjo el error, entonces puede especificar la dirección de correo electrónico de ese desarrollador. Si no, déjalo en blanco ya que esto asignará el fallo al propietario del módulo, si no el Gestor asignará el fallo al desarrollador. Posiblemente añada la dirección de correo electrónico del gestor en la lista CC.

URL: La URL de la página en la que se produjo el error.

Resumen: Un breve resumen del error en su mayoría en 60 palabras o menos. Asegúrate de que tu resumen refleja cuál es el problema y dónde está.

Descripción: Una descripción detallada del fallo.

Utiliza los siguientes campos para el campo de descripción:

• Reproducir pasos: Mencione claramente los pasos para reproducir el fallo.
• Resultado esperado: Cómo debería comportarse la aplicación en los pasos mencionados.
• Resultado real: Cuál es el resultado real de ejecutar los pasos anteriores, es decir, el comportamiento del bug.

Estos son los pasos importantes en el informe de bug. También puede añadir el «Tipo de informe» como un campo más que describirá el tipo de bug.

Los tipos de informe incluyen:

1) Error de codificación
2) Error de diseño
3) Nueva sugerencia
4) Problema de documentación
5) Problema de hardware

Características importantes en su informe de error

A continuación se indican las características importantes en el informe de error:

#1) Número/id de bug

Un número de bug o un número de identificación (como swb001) hace que el informe de bug y la referencia a un bug sea mucho más fácil. El desarrollador puede comprobar fácilmente si un fallo concreto se ha solucionado o no. Hace que todo el proceso de prueba y reprueba sea más suave y fácil.

#2) Título del fallo

El título del fallo se lee más a menudo que cualquier otra parte del informe de fallo. Debería decir todo lo que viene en el bug.

El título del bug debería ser lo suficientemente sugerente como para que el lector pueda entenderlo. Un título de bug claro hace que sea fácil de entender y el lector puede saber si el bug ha sido reportado anteriormente o ha sido arreglado.

#3) Prioridad

Basado en la gravedad del bug, se puede establecer una prioridad para él. Un fallo puede ser un Bloqueo, Crítico, Mayor, Menor, Trivial o una sugerencia. Se puede dar una prioridad al fallo de P1 a P5 para que los importantes se vean primero.

#4) Plataforma/Entorno

La configuración del sistema operativo y del navegador es necesaria para un informe de fallo claro. Es la mejor manera de comunicar cómo se puede reproducir el fallo.

Sin la plataforma o el entorno exacto, la aplicación puede comportarse de manera diferente y el fallo en el extremo del probador puede no replicarse en el extremo del desarrollador. Así que es mejor mencionar claramente el entorno en el que se ha detectado el fallo.

#5) Descripción

La descripción del fallo ayuda al desarrollador a entenderlo. Describe el problema encontrado. Una mala descripción creará confusión y hará perder el tiempo a los desarrolladores y también a los probadores.

Es necesario comunicar claramente el efecto de la descripción. Siempre es útil utilizar frases completas. Es una buena práctica describir cada problema por separado en lugar de desmenuzarlos en conjunto. No utilice términos como «creo» o «creo».

#6) Pasos para reproducir

Un buen informe de Bug debe mencionar claramente los pasos para reproducir. Los pasos deben incluir las acciones que causan el bug. No haga afirmaciones genéricas. Sea específico en los pasos a seguir.

Un buen ejemplo de un procedimiento bien escrito se da a continuación

Pasos:

• Seleccione el producto Abc01.
• Haga clic en Añadir al carrito.
• Haga clic en Eliminar para quitar el producto del carrito.

#7) Resultado esperado y real

Una descripción de Bug está incompleta sin los resultados esperados y reales. Es necesario esbozar cuál es el resultado de la prueba y qué debe esperar el usuario. El lector debe saber cuál es el resultado correcto de la prueba. Mencione claramente lo que ocurrió durante la prueba y cuál fue el resultado.

#8) Captura de pantalla

Una imagen vale más que mil palabras. Tome una captura de pantalla de la instancia de fallo con un subtítulo adecuado para resaltar el defecto. Resalte los mensajes de error inesperados con un color rojo claro. Esto llama la atención sobre el área requerida.

Algunos consejos adicionales para escribir un buen informe de error

A continuación se presentan algunos consejos adicionales para escribir un buen informe de error:

#1) Informar del problema inmediatamente

Si usted encuentra cualquier error durante las pruebas, entonces no necesita esperar para escribir un informe de error detallado más tarde. En su lugar, escriba el informe de errores inmediatamente. Esto asegurará un informe de error bueno y reproducible. Si decide escribir el informe de fallo más tarde, hay muchas posibilidades de que se pierdan los pasos importantes en su informe.

#2) Reproduzca el fallo tres veces antes de escribir un informe de fallo

Su fallo debe ser reproducible. Asegúrate de que tus pasos son lo suficientemente robustos como para reproducir el bug sin ninguna ambigüedad. Si su error no es reproducible cada vez que usted todavía puede presentar un error mencionando la naturaleza periódica del error.

#3) Pruebe la misma ocurrencia de errores en otros módulos similares

A veces el desarrollador utiliza el mismo código para diferentes módulos similares. Así que hay más posibilidades de que el error en un módulo se produzca también en otros módulos similares. Incluso puedes intentar encontrar la versión más grave del fallo que has encontrado.

#4) Escribe un buen resumen del fallo

El resumen del fallo ayudará a los desarrolladores a analizar rápidamente la naturaleza del fallo. Un informe de mala calidad aumentará innecesariamente el tiempo de desarrollo y pruebas. Comunica bien el resumen de tu informe de fallos. Tenga en cuenta que el resumen del fallo se utiliza como referencia para buscar el fallo en el inventario de fallos.

#5) Lea el informe de fallo antes de pulsar el botón de envío

Lea todas las frases, formulaciones y pasos que se utilizan en el informe de fallo. Fíjese en si alguna frase crea una ambigüedad que pueda dar lugar a una interpretación errónea. Las palabras o frases engañosas deben evitarse para tener un informe de fallo claro.

#6) No utilice un lenguaje abusivo

Es bueno que haya hecho un buen trabajo y haya encontrado un fallo pero no utilice este crédito para criticar al desarrollador o para atacar a cualquier individuo.

Conclusión

No hay duda de que su informe de errores debe ser un documento de alta calidad.

Centrarse en escribir buenos informes de errores y dedicar algo de tiempo a esta tarea porque es el principal punto de comunicación entre el probador, el desarrollador y el gerente. Los gestores deben concienciar a su equipo de que escribir un buen informe de errores es la principal responsabilidad de cualquier probador.