Cómo Crear una Plantilla de Seguimiento de Errores en Jira
Una plantilla de seguimiento de errores es un formato predefinido para documentar e informar errores en el desarrollo de software. Contar con una plantilla garantiza que se capturen los detalles cruciales de manera consistente, lo que permite un seguimiento, priorización y comunicación más sencilla dentro del equipo.
Jira es una herramienta de seguimiento de incidencias de Atlassian, y probablemente una de las herramientas de seguimiento de errores más populares utilizadas para la gestión de proyectos de desarrollo (especialmente en entornos ágiles). La he utilizado en muchos proyectos en los últimos años, tanto con Scrum como con Kanban, y me parece muy versátil.
En este artículo, analizaré la versatilidad de Jira para el seguimiento de errores, la personalización y la gestión de flujos de trabajo, y cómo mejorar el reporte de errores con Jira.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Tanto si eres el encargado de configurar los flujos de trabajo en Jira como si reportas defectos utilizando la herramienta, no está de más saber cómo funciona. Jira es mucho más que una herramienta de reporte de errores, pero en este artículo nos centraremos más en el seguimiento de bugs que en la gestión de otros tipos de incidencias.
Configurando un nuevo proyecto con Jira Software
Si tu proyecto es nuevo, lo primero que necesitas hacer es configurar el proyecto en Jira. Esta tarea normalmente recae en el Scrum Master o el Project Manager, pero si tu rol de QA se solapa con uno de estos, la responsabilidad puede recaer en ti. ¡No es complicado, y en cualquier caso, debería ser una tarea única!
El registro es gratuito, y para proyectos pequeños con menos de diez usuarios puedes usar el plan gratuito. Si tienes un equipo más grande o necesitas funciones avanzadas, elige uno de los planes de pago. No entraré en detalles, pero puedes consultar la página de precios de Jira si te interesa.
Solo he creado nuevos proyectos para impartir clases, pero el proceso es bastante intuitivo. Tendrás la opción de elegir entre diferentes tipos de proyectos para desarrollo de software:
Tipos de proyecto
- Un proyecto Kanban te permite crear tableros Kanban. Puedes usar la plantilla clásica con las etapas clásicas: Por hacer, En progreso y Hecho.
- Scrum: Esta plantilla permite al equipo gestionar sus sprints y el backlog utilizando el marco de trabajo Scrum.
- Seguimiento de errores: Una plantilla sencilla que permite el seguimiento de incidencias sin utilizar ninguna metodología ágil.
Todos los proyectos se pueden personalizar para incluir las etapas, transiciones y estados que el proyecto necesite.
Para este tutorial, usaré la plantilla de proyecto Scrum para que puedas hacer seguimiento tanto de historias como de errores en el mismo proyecto, pero no te preocupes: ¡todo lo que muestro se puede aplicar también a otros tipos de proyectos!
Tipos de incidencia
Los tipos de incidencia predeterminados que ofrece Jira son:
- Épica: En ágil, una épica es un conjunto a gran escala de historias de usuario y tareas.
- Bug: El tipo de incidencia que usamos en Jira para hacer seguimiento de errores y defectos encontrados. Nos centraremos en este tipo el resto del artículo.
- Historia: Una historia de usuario ágil (la descripción de la funcionalidad o característica que se desarrollará y testeará).
- Tarea: Normalmente se utiliza para hacer el seguimiento de incidencias puntuales o tareas pendientes, por ejemplo, investigar una nueva herramienta de automatización de pruebas o actualizar la documentación.
- Subtarea: Es una tarea individual asignada a un miembro del equipo y es hija de la incidencia “Tarea” mencionada anteriormente.
Como mencioné antes, Jira es muy versátil, y si necesitas crear tu propio tipo de incidencia, puedes hacerlo en cualquier momento dentro del proyecto.
Por ejemplo, trabajé en un proyecto donde teníamos un tipo de incidencia separado para mejoras. Estas eran similares a las historias de usuario, pero estaban relacionadas principalmente con mejoras para funcionalidades ya existentes en la aplicación.
O puedes crear un tipo de incidencia para casos de prueba, pero llegaremos a eso un poco más adelante, cuando cubramos los plugins disponibles y las herramientas de integración de Jira.
Seguimiento de Errores con Jira
Pasando a lo que nos interesa como testers—el reporte y seguimiento de errores. Aunque Jira es una herramienta de gestión de proyectos, y no específicamente de seguimiento de errores, nosotros los QA probablemente la usaremos mucho para reportar errores 😁.
Flujo de Trabajo y Ciclo de Vida del Error
El flujo de trabajo por defecto para errores (y para todas las incidencias, en realidad) que ofrece Jira es el siguiente:
Cuando se abre una incidencia, se crea con el estado 'Por hacer'. Luego, la incidencia, o el error, puede moverse a cualquiera de los otros estados.
El equipo de gestión de pruebas, el scrum master o el gestor de proyecto suelen ser quienes diseñan los flujos de trabajo personalizados.
El flujo de trabajo refleja el ciclo de vida del error que quieres tener en el proyecto. Puedes mantener el predeterminado, que es sencillo, o hacerlo tan complejo como sea necesario. Honestamente, nunca he trabajado en un proyecto que no tuviera sus propios estados y transiciones personalizadas.
Para personalizar el ciclo de vida, debes ir a la configuración del proyecto, seleccionar el tipo de incidencia de error, y hacer clic en 'Editar flujo de trabajo'.
Aquí puedes añadir un nuevo estado y elegir una transición específica si lo deseas. Aquí tienes un ejemplo:
En este caso, cuando se crea una nueva incidencia, tendrá el estado 'Por hacer', desde donde solo puede moverse a 'En progreso'. Luego, antes de que el error pueda ser probado, el código debe ser revisado. El equipo de QA puede cerrarlo una vez que esté validado en el estado 'En QA'. Por supuesto, la revisión de código y los procesos de QA pueden fallar y, de ser así, el error se moverá de vuelta a 'En progreso'.
Creación del Flujo de Trabajo Paso a Paso
Voy a repasar cada paso que necesitas para pasar del primer flujo de trabajo al segundo (o cualquier flujo personalizado que consideres apropiado para tu proyecto):
1. Primero, haz clic en el botón de 'Editar flujo de trabajo'
2. Para añadir un nuevo estado, haz clic en uno de los estados: los estados están separados en tres categorías: 'Por hacer', 'En progreso' y 'Hecho', cada uno con un color distintivo. Puedes elegir dónde encaja mejor tu nuevo estado. Yo decidí que los estados 'En revisión de código' y 'En QA' significan que la incidencia todavía está en progreso:
También puedes tener otros estados de 'Por hacer'; por ejemplo, un estado de 'En revisión', para cuando se abre una nueva funcionalidad y el product owner o analista de negocio aún necesita añadir información sobre ella, o el equipo aún debe refinarla y decidir su complejidad o estimar sus story points.
3. Una vez que has añadido el nuevo estado, puedes agregarle una transición. Por defecto, se podrá actualizar el estado desde cualquier otro. Si no quieres reglas de transición específicas, está bien. Sin embargo, un buen flujo de trabajo permitiría que los errores y las incidencias pasen a estados concretos solo después de haber pasado por ciertos pasos del proceso.
En mi ejemplo anterior, el equipo de QA no puede empezar a verificar la corrección antes de que otro desarrollador revise el código. Para añadir esta transición, haz clic en el botón 'Transición' e introduce los detalles:
4. También puedes eliminar cualquier transición o estado existente si deseas que todo sea 100% personalizado.
5. Una función muy interesante es lo de los asignados automáticos. Esto también se hace desde el flujo de trabajo, donde puedes asignar un usuario por defecto cuando se realiza una transición concreta sobre la incidencia (esto también es una ventaja clave del software de seguimiento de incidencias).
Por ejemplo, después de que un bug es 'Revisado' y movido a 'En QA', se asigna automáticamente a un determinado tester o al responsable de pruebas, quien decidirá quién trabajará en él. Lo mismo ocurre con 'En progreso' y el equipo de desarrollo. Los nuevos issues pueden asignarse automáticamente a un project manager o al product owner, quien los priorizará en el backlog. Es altamente personalizable, así que puedes adaptarlo como mejor funcione para tu equipo.
Aunque no seas responsable de configurar los ciclos de vida de los issues, o si no tienes acceso a la configuración del proyecto, puedes ver el flujo de trabajo de cada incidencia de Jira expandiendo el desplegable de estados:
Visualización de incidencias en Jira
Si el proyecto no es uno de seguimiento de errores, puedes visualizar las incidencias actuales en los tableros Kanban o Scrum:
Esto es solo una demostración; dudo que alguna vez tengas la suerte de tener un sprint con solo una user story y un bug 😅.
Al hacer clic en cualquier incidencia verás sus detalles. Estos contienen, pero no se limitan a, un ID (que Jira crea automáticamente), un título, una descripción, el reportero, el asignado y cualquier adjunto o comentario añadido por los miembros del equipo.
Los campos también se pueden personalizar, y lo mostraré cuando hablemos de qué debemos incluir en un buen informe de bug.
Asignados
Todas las incidencias de Jira pueden asignarse a un miembro específico del equipo. Puedes etiquetar personas en los comentarios o en la descripción usando el carácter @ antes del nombre del usuario.
Recibirás notificaciones cuando alguien te etiquete y cuando se actualice una incidencia asignada o reportada por ti. También puedes “observar” incidencias. Serás notificado cuando haya actualizaciones en las incidencias observadas, independientemente de quién sea el reportero o el asignado.
Reporte de bugs en Jira
Una app con pocos bugs es lo que todos desean, pero seamos honestos: los testers siempre nos alegramos cuando encontramos un buen bug.
Pero un buen bug solo es tan bueno como el informe que hacemos de él—un buen reporte de error garantiza que será corregido con el menor ida y vuelta posible entre los equipos de testing y desarrollo. Jira es una excelente herramienta de seguimiento de bugs. ¿Ya lo mencioné? Ofrece mucha flexibilidad.
Para crear un nuevo issue, haz clic en el gran botón 'Crear', y se abrirá un cuadro de diálogo. Aquí, selecciona el tipo de incidencia 'Bug':
Un buen reporte de bug debe incluir una buena descripción (o 'Resumen' en Jira). Debe ser conciso, pero aportar los detalles necesarios para que quede claro de qué trata el problema.
Luego, en la descripción, agrega todos los detalles relevantes. Puedes estructurarlo de forma clásica:
- Pasos para reproducir
- Resultado esperado
- Resultado real
Después, añade cualquier detalle adicional relevante para el defecto. Las capturas de pantalla o grabaciones siempre son una buena idea, así como los logs o archivos específicos usados durante la ejecución.
Jira permite añadir campos personalizados a las incidencias. Me gusta separar la 'Severidad' de la 'Prioridad'. Así que aunque 'Prioridad' es un campo por defecto en Jira, puedes agregar uno personalizado para 'Severidad'.
Otros campos personalizados útiles pueden estar relacionados con el sistema operativo—un campo de texto o un desplegable con valores predefinidos, como la versión de Android o iOS usada en las pruebas, el navegador, el número de build o cualquier otra información relevante al registrar bugs.
Para añadir nuevos campos, puedes ir a la configuración del proyecto, seleccionar el tipo 'Bug' y elegir qué tipo de campo necesitas:
Casos de prueba en Jira
Lo último de lo que quiero hablar es sobre los casos de prueba. El software Jira se puede integrar con varias herramientas de gestión de pruebas, o puedes añadir extensiones y complementos de Atlassian, como Zephyr (que solía ser mi favorito) o Xray. Cuando creas un bug como resultado de un caso de prueba fallido, la prueba se puede vincular al bug, lo cual puede ser muy útil para gestionar bugs, pruebas y la ejecución de casos de prueba.
¿Quieres más?
Jira puede ser una excelente herramienta de seguimiento de defectos y puede mejorar el proceso de desarrollo porque permite mucha personalización. Cuando se trata de bugs, es realmente útil ya que puedes personalizar el flujo de trabajo para adaptarlo al ciclo de vida que desees tener en tu proyecto. Puedes vincular bugs a casos de prueba y agregar campos personalizados de la manera que tenga más sentido para tu proyecto específico.
Para más guías prácticas como esta, suscríbete al boletín The QA Lead.
