Consejos para mejorar informes de bugs en Jira.

Una de las claves principales en la gestión de errores en el mundo del software es cómo se reportan los errores, qué información debe contener y explicitar para una idónea trazabilidad y gestión y la parte quizás más importante: cómo se comunican.

Vamos a recorrer esta información y cómo se puede mejorar todo el ciclo de software con ellos. Aunque la forma de escribir estos informes es agnóstica a la plataforma donde se registren, en este tutorial vamos a utilizar como base una de las herramientas más usadas en el mundo del software: Jira.

Aunque no lo parezca, antes incluso de la creación del bug hay que plantearse si realmente existe tal circunstancia y no se debe a otro tipo de casuísticas que se pueden dar a la par, haciendo parecer algo que no es. En esta investigación previa tenemos que descartar posibles incidencias que pudieran intervenir haciéndonos las siguientes preguntas:

• ¿Es un problema de los entornos de ejecución, ajeno a nuestra aplicación?
• ¿Ha habido cambios recientes en la aplicación?
• ¿En qué versión de la aplicación estamos trabajando? ¿Es la correcta?
• ¿Los datos de test son los correctos? ¿Necesitan ser actualizados?
• ¿Sigue teniendo sentido tener esta prueba en nuestra suite? ¿Está obsoleta? ¿Necesitamos actualizarla?

Si con las respuestas a estas preguntas llegamos a la conclusión de que estamos conformes y hemos descubierto un bug, el siguiente paso es redactarlo. Pero, ¿qué aspectos imprescindibles debe tener un buen informe?

• Título. Tiene que ser descriptivo del problema que nos hemos encontrado. No está del todo bien poner “No funciona X”.
• Proyecto. El nombre del proyecto asociado que tenemos. Este campo suele ser obviado pero, si se trabaja en diferentes proyectos, al final es importante para una buena trazabilidad. Podemos poner el nombre del programa, el área donde está inscrito… Aquí ya hay más libertad de elección.
• Entorno. Aquí describimos en qué entorno se está produciendo el bug. En Jira, normalmente se suele configurar para que sea campo único, por lo que también se recomienda poner en la descripción si este bug se encuentra en más de un sitio.
• Nivel de criticidad. Estos niveles indican el impacto que pueda tener el bug descubierto en la funcionalidad y experiencia de usuario. La determinación del nivel puede depender de varios factores como la frecuencia del error, el impacto en el usuario final, si hay una solución alternativa disponible y la importancia de la funcionalidad afectada en el contexto general del producto o servicio. Es esencial que cada organización defina claramente estos niveles y los criterios asociados para garantizar una gestión eficaz de los errores.
  Suelen definirse como bajo, alto y bloqueante:
  • Bajo. Indica que el bug tiene un impacto mínimo en la funcionalidad del sistema y no afecta significativamente la experiencia del usuario. Es más una molestia que una interrupción.
  • Alto. Se refiere a un bug que afecta seriamente la funcionalidad del sistema y tiene un impacto significativo en la operación normal y la productividad. Puede requerir una solución rápida, pero el sistema sigue siendo operable.
  • Bloqueante. Este es el nivel más crítico. Un bug bloqueante impide que una funcionalidad clave del sistema opere por completo, lo que resulta en una paralización de las operaciones. Estos bugs requieren atención inmediata y deben ser corregidos antes de que el producto pueda ser utilizado o lanzado.
• Prioridad. La prioridad de un bug se refiere al orden en el que un bug debe ser resuelto por el equipo de desarrollo. Puede cambiar con el tiempo, dependiendo del calendario de desarrollo y de otros bugs que puedan surgir. Por ejemplo, un bug que inicialmente no es prioritario puede convertirse en uno de alta prioridad si impide el lanzamiento de una nueva característica importante o si afecta negativamente la experiencia del usuario de manera significativa.
  Mientras que la severidad de un bug se relaciona con el nivel técnico de impacto en el sistema, la prioridad está más relacionada con la planificación estratégica y la toma de decisiones dentro del negocio.
  Se suelen clasificar en:
  • Baja: solo cuando no queden tareas disponibles en el ciclo de desarrollo podemos empezar a resolver este bug.
  • Media: cuando los objetivos del ciclo de desarrollo puedan verse afectados por él.
  • Alta: es muy importante que se solucione y se aborde cuando no queden tareas vitales.
  • Bloqueante: es de vital importancia que se solucione lo antes posible.
• Versiones afectadas. Tenemos que tener en cuenta si el error que hemos encontrado existe en versiones anteriores del producto, en versiones nuevas de desarrollo…
• Descripción. En este apartado nos explayaremos todo lo posible para contar las características propias del bug que se está reportando, como pueden ser:
• Pasos para reproducirlo: tenemos que dar los máximos detalles posibles para, desde un punto de la aplicación (normalmente será el de inicio), poder llegar hasta él.
• Reproducibilidad: si se consigue reproducir siguiendo los pasos anteriores o es variable.
• Resultados obtenidos: si, una vez realizados los pasos obtenemos un resultado que difiere del que esperábamos, lo anotamos aquí.
• Resultados esperados: es el resultado lógico que debería ocurrir cuando seguimos el flujo descrito anteriormente.
• Pruebas: este apartado es más libre y podemos adjuntar toda prueba que consideremos que aporta valor, por ejemplo: pruebas visuales, vídeos, capturas de pantalla, pruebas de rendimiento, logs…
• Datos: aquí compartiremos cualquier dato que sea necesario para poder reproducir el bug, como pueden ser configuraciones, lenguaje del navegador/dispositivo, sistema operativo…

A continuación os muestro dos ejemplos: el primer ejemplo muestra cuándo NO sería un informe válido, al no aportar la información suficiente y claramente ordenada y el segundo muestra cuándo SÍ sería un informe válido.

1. Ejemplo de cuándo NO es un informe válido:

• Título: No carga la web.
• Descripción: Intento entrar en la web pero no puedo, se me queda la pantalla en blanco.
• Entorno: N/A.
• Prioridad: Baja (viene seleccionado por defecto).
• Nivel de criticidad: Bajo (viene seleccionado por defecto).

2. Ejemplo de cuándo SÍ sería un informe válido:

• Título: Tras realizar el login, no redirecciona al área de gestión de usuarios.
• Proyecto: E-Commerce Revolution.
• Entorno: Pre-producción.
• Nivel de criticidad: Alto.
• Prioridad: Alta.
• Versión afectada: 10.3902.390 - SNAPSHOT.
• Descripción: Se descubre que, tras el inicio de sesión correcto con el usuario de pruebas número 1, se queda en un bucle infinito la redirección al área de gestión de usuarios. Se comprueba que otras partes de la aplicación se pueden navegar sin problemas.
  • Pasos:
    Entrar en la web Revolution.
    Iniciar sesión con el usuario de pruebas número 1.
  • Reproducibilidad: Siempre.
  • Resultados obtenidos: Pantalla en blanco y peticiones de redirecciones constantes por la consola.
  • Resultados esperados: Redirección única hacia el área de gestión y su visualización correcta.
  • Pruebas: Se adjunta el fichero .har y vídeos de la parte visual.
  • Datos:
    Usuario pruebas 1: “test-pre-1”.
    Navegador: Chrome 124.0.
    Sistema operativo: Windows 11.

Con el informe del bug ya creado, el siguiente paso es la comunicación. Esta fase es probablemente la más delicada del proceso, ya que puede ser sensible para quienes estuvieron involucrados en el desarrollo. Los errores pueden percibirse como una crítica directa al trabajo realizado y sentirse como una lanza directa al corazoń de quien hizo el desarrollo, lo que puede ser difícil de aceptar.

Aunque es normal que surjan bugs, es crucial mantener una comunicación asertiva y constructiva. Es importante recordar que las personas que desarrollan están interesadas en mejorar su software, y tu informe puede ser una herramienta valiosa para lograrlo. Esta etapa involucra habilidades interpersonales y mantener una buena relación con el equipo es clave para el éxito colectivo. Después de reportar el bug, asegúrate de estar disponible para cualquier actualización o solicitud de información adicional por parte de los equipos de desarrollo.

¿Te ha servido esta introducción al mundo de la gestión de errores? Dímelo en los comentarios.