Jira fue una de las herramientas que más usé en mi formación como QA. Y reportar bugs correctamente en Jira es una de esas habilidades que parece sencilla pero que marca una diferencia enorme en cómo te percibe el equipo de desarrollo.
Un bug mal reportado genera confusión, retrasos y fricciones innecesarias. Uno bien reportado se entiende a la primera y se corrige más rápido. En este artículo te explico cómo hacerlo bien desde el principio.
Qué es Jira y para qué se usa en QA
Jira es una herramienta de gestión de proyectos desarrollada por Atlassian. En equipos de desarrollo de software se usa para gestionar el trabajo del equipo, organizar sprints, documentar historias de usuario y, muy especialmente, reportar y hacer seguimiento de bugs.
Para un QA Engineer, Jira es el lugar donde vive toda la información sobre los defectos encontrados: qué se encontró, cómo reproducirlo, quién lo está corrigiendo y cuál es su estado en cada momento.
Los campos principales de un bug en Jira
Cuando creas un nuevo issue de tipo Bug en Jira, verás varios campos que hay que rellenar. Estos son los más importantes:
Resumen (título)
Es lo primero que ve todo el mundo. Tiene que ser descriptivo y específico. No vale «el login no funciona». Vale «el botón de login no responde al hacer clic con credenciales válidas en Chrome 120 en Windows 11».
Un buen título responde a tres preguntas: qué falla, dónde falla y en qué condiciones.
Descripción
Aquí va todo el detalle. Una buena descripción incluye los pasos para reproducir el bug, el resultado obtenido y el resultado esperado. Cuanto más claro y detallado, menos preguntas tendrá que hacer el desarrollador.
Pasos para reproducir
Numerados y en orden. Desde el estado inicial hasta el momento exacto en que aparece el error. Por ejemplo:
- Abrir Chrome 120 en Windows 11
- Ir a https://miweb.com/login
- Introducir email válido y contraseña correcta
- Hacer clic en el botón «Iniciar sesión»
- Observar que el botón no responde
Resultado obtenido
Lo que ocurre realmente. «El botón no responde y no hay ningún mensaje de error.»
Resultado esperado
Lo que debería ocurrir. «El usuario debería ser redirigido al dashboard tras introducir credenciales válidas.»
Severidad
El impacto técnico del bug: crítica, alta, media o baja. Si quieres saber más sobre cómo clasificar bugs puedes leer qué es un bug y cómo clasificarlo.
Prioridad
La urgencia con la que hay que corregirlo desde el punto de vista del negocio.
Entorno
Navegador, sistema operativo, versión de la aplicación y dispositivo donde se reproduce el bug. Sin esta información, el desarrollador puede no ser capaz de reproducirlo.
Evidencias
Capturas de pantalla, vídeos o logs. Es el campo que más acelera la resolución del bug. Una captura que muestra exactamente el error vale más que dos párrafos describiéndolo.
Paso a paso: cómo crear un bug en Jira
Paso 1: En tu proyecto de Jira, haz clic en «Crear» o «+ Create».
Paso 2: En el campo «Tipo de issue» selecciona «Bug».
Paso 3: Rellena el Resumen con un título descriptivo y específico.
Paso 4: En la Descripción añade los pasos para reproducirlo, el resultado obtenido y el resultado esperado. Puedes usar este formato:
**Pasos para reproducir:**
1.
2.
3.
**Resultado obtenido:**
**Resultado esperado:**Paso 5: Selecciona la Severidad y la Prioridad.
Paso 6: Rellena el campo de Entorno con el navegador, SO y versión de la app.
Paso 7: Adjunta las evidencias — captura de pantalla o vídeo del error.
Paso 8: Asigna el bug al desarrollador correspondiente si lo sabes, o déjalo sin asignar para que el equipo lo gestione.
Paso 9: Haz clic en «Crear».
El ciclo de vida de un bug en Jira
Una vez creado el bug, pasa por varios estados hasta que se cierra. Los más habituales son:
Abierto (Open): el bug ha sido reportado pero aún no se ha asignado a nadie.
En progreso (In Progress): un desarrollador está trabajando en la corrección.
En revisión (In Review): la corrección está lista y está siendo revisada.
Pendiente de verificación (Ready for QA): el desarrollador dice que está corregido y el QA tiene que verificarlo.
Verificado (Verified): el QA ha comprobado que el bug está corregido correctamente.
Cerrado (Closed): el bug está resuelto y cerrado.
Reabierto (Reopened): el QA ha verificado que la corrección no funciona o que el bug sigue apareciendo.
Errores comunes al reportar bugs en Jira
Títulos vagos. «No funciona» o «error en la web» no le dicen nada a nadie. Sé específica.
Pasos incompletos. Si faltan pasos, el desarrollador no puede reproducir el bug y el ticket vuelve a ti con preguntas.
Sin evidencias. Adjuntar siempre una captura o vídeo acelera enormemente la resolución.
Mezclar varios bugs en un ticket. Un ticket, un bug. Si encuentras dos problemas distintos, crea dos tickets separados.
No actualizar el estado. Jira solo es útil si los estados están al día. Si verificas que un bug está corregido, ciérralo. Si sigue fallando, reábrelo.
Buenas prácticas que marcan la diferencia
Antes de reportar un bug, comprueba que no existe ya un ticket abierto para ese mismo problema. Los duplicados generan confusión.
Reproduce el bug al menos dos veces antes de reportarlo para asegurarte de que no es un problema puntual.
Usa un lenguaje neutro y profesional. El objetivo del reporte es describir el problema, no señalar culpables.
Si el bug está bloqueando el trabajo del equipo, márcalo como blocker y avisa directamente al desarrollador o al Scrum Master además de crear el ticket.
Si quieres saber más sobre cómo encaja el reporte de bugs en el ciclo de trabajo ágil, puedes leer cómo funciona el QA en Scrum o visitar fatimaqa.com para ver mis servicios de QA freelance.