Todos los cursos > Informática ( TI ) > Testes de software ::

Gestión de defectos en Jira: severidad, prioridad, triage y ciclo de vida

Capítulo 7

Tiempo estimado de lectura: 9 minutos

Qué es un defecto (bug) en Jira y por qué importa su calidad

En Jira, un defecto es un ítem de trabajo que describe un comportamiento del producto que no cumple lo esperado (según requisitos, criterios de aceptación o estándares acordados). La calidad del registro determina si el equipo puede reproducir, diagnosticar, corregir y verificar el problema sin ciclos innecesarios de preguntas. Un bug “bien escrito” reduce el tiempo de triage, evita falsos duplicados y mejora la priorización.

Cómo registrar bugs con calidad: plantilla práctica

Un buen bug responde, como mínimo, a: qué falla, dónde, cómo reproducir, qué se esperaba, qué ocurrió, con qué evidencia y en qué entorno/versión. A continuación tienes una guía paso a paso y un ejemplo listo para copiar.

Paso a paso para crear un bug reproducible

1) Título informativo: resume el síntoma + área + condición. Evita “No funciona”. Incluye el punto exacto de fallo.
2) Contexto: qué estaba intentando lograr el usuario y por qué importa (impacto funcional). Si aplica, referencia el requisito/historia relacionada (sin reexplicar su contenido).
3) Pasos para reproducir: numerados, atómicos, sin ambigüedad. Incluye datos de prueba (usuario, rol, valores) y precondiciones.
4) Resultado esperado: comportamiento correcto observable.
5) Resultado actual: comportamiento observado, mensajes de error, códigos, pantallas.
6) Evidencia: adjuntos o enlaces (captura, video, log, HAR, traza). Indica qué mirar (timestamp, request, stacktrace).
7) Entorno: ambiente (QA/UAT/Prod), navegador/app, SO, dispositivo, configuración relevante (feature flags), conectividad si aplica.
8) Versión/build: número de versión, commit, build, release candidate. Si es backend, API version.
9) Alcance: frecuencia (siempre/intermitente), usuarios afectados, módulos impactados, workaround conocido, regresión (sí/no) y desde qué versión.

Plantilla sugerida (campos/descrición del bug)

Título: [Módulo] [Síntoma] al [condición/acción] (vX.Y.Z)  Descripción/Contexto: - Objetivo del usuario: ... - Impacto: ... - Relacionado con: PROJ-123 (si aplica)  Precondiciones: 1) Usuario: ... (rol/permisos) 2) Datos: ... (ej. carrito con 2 ítems)  Pasos para reproducir: 1. ... 2. ... 3. ...  Resultado esperado: ...  Resultado actual: ...  Evidencia: - Video: adjunto (00:12 se observa el error) - Log: adjunto (timestamp ...)  Entorno: - Ambiente: QA - Navegador/App: Chrome 121 / Android 14 - SO/Dispositivo: ... - Config: featureFlagX=ON  Versión/Build: - Front: 2.8.0 (build 4512) - API: 1.14.3  Alcance: - Frecuencia: 3/5 intentos - Afectados: usuarios con rol “Supervisor” - Workaround: refrescar página (parcial) - Regresión: sí, desde 2.7.1

Ejemplo práctico de bug bien registrado

Título: [Checkout] Error 500 al aplicar cupón con caracteres “-” en el código (v2.8.0)

Contexto: usuario intenta aplicar un cupón promocional en checkout; bloquea la finalización de compra para campañas activas.

Precondiciones: usuario autenticado; carrito con 1 producto; cupón válido VERANO-10.

Continúa en nuestra aplicación.

Escuche el audio con la pantalla apagada.
Obtenga un certificado al finalizar.
¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Pasos:

1. Ir a /checkout.
2. En “Cupón”, ingresar VERANO-10.
3. Hacer clic en “Aplicar”.

Esperado: el cupón se aplica, se recalcula el total y se muestra confirmación “Cupón aplicado”.

Actual: aparece mensaje genérico “Ocurrió un error” y el total no cambia; en consola se observa respuesta HTTP 500.

Evidencia: video adjunto; log de red adjunto con request POST /api/coupons/apply y response 500; stacktrace en log backend adjunto.

Entorno: QA; Chrome 121; Windows 11; featureFlag newCheckout=true.

Versión: Front 2.8.0 build 4512; API 1.14.3.

Alcance: siempre; afecta cupones con guion; workaround: usar cupón sin guion (si existe); regresión: no confirmada.

Severidad vs prioridad: diferencias y cómo acordarlas con el equipo

En Jira es común manejar Severidad (impacto técnico/funcional del defecto) y Prioridad (urgencia de atención según valor de negocio, riesgo y planificación). Mezclarlas provoca discusiones improductivas: un bug puede ser muy severo pero no urgente (si está en una funcionalidad deshabilitada), o poco severo pero muy prioritario (si afecta una demo o un flujo crítico de conversión).

Definiciones operativas

Severidad: qué tan grave es el defecto en términos de impacto sobre el usuario/sistema (bloqueo, pérdida de datos, seguridad, degradación). Suele ser responsabilidad primaria de QA con input técnico.
Prioridad: cuándo debe resolverse (ahora, próximo sprint, backlog) considerando negocio, fechas, riesgo, dependencias. Suele decidirla Product Owner/PM con input de QA y desarrollo.

Matriz rápida para alinear criterios

Nivel	Severidad (impacto)	Ejemplo	Prioridad (urgencia)
Crítica	Bloquea flujo principal, caída, pérdida de datos, seguridad	No se puede pagar / datos se borran	P0/P1 según release y exposición
Alta	Función clave falla sin workaround razonable	No se puede crear pedido en ciertos casos	P1/P2
Media	Falla con workaround o impacto parcial	Validación incorrecta pero permite continuar	P2/P3
Baja	Cosmético o impacto mínimo	Alineación de UI, typo	P3/P4

Cómo acordarlas con el equipo (práctica recomendada)

Define reglas por escrito: una tabla como la anterior en Confluence o en la descripción del tipo de issue “Bug”.
Separa campos: usa un campo para Severidad y otro para Prioridad (o usa Priority de Jira para prioridad y un custom field para severidad).
Incluye “riesgo” y “exposición”: si está en producción, si afecta a todos o a un segmento, si hay fecha de release/demos.
Acuerdo de desempate: QA propone severidad; PO decide prioridad; Tech Lead valida esfuerzo/impacto técnico.

Triage de defectos: objetivo, participantes y decisiones típicas

El triage es el proceso de clasificar y decidir acciones sobre los bugs entrantes: confirmar reproducibilidad, evitar duplicados, asignar severidad/prioridad, definir dueño y determinar si se corrige, se pospone o se descarta. En equipos ágiles, puede ocurrir diariamente o varias veces por semana, con una cadencia corta.

Checklist de triage (orden sugerido)

1) ¿Es reproducible? Ejecutar pasos en el entorno indicado y confirmar evidencia.
2) ¿Es duplicado? Buscar por palabras clave del título, componente, mensajes de error, endpoint, stacktrace. Si es duplicado, enlazar al bug “master”.
3) ¿Es “esperado”? Validar contra criterios de aceptación, reglas de negocio y comportamiento acordado. Si es esperado, documentar la razón y cerrar como “No es un bug/By design”.
4) ¿Falta información? Si no hay pasos claros, entorno o versión, devolver para completar.
5) ¿Está bloqueado por dependencia? Identificar si depende de otro equipo/servicio/feature flag. Registrar dependencia y ajustar plan.
6) Clasificar severidad/prioridad y asignar responsable (dev/área).

Estados/decisiones comunes en triage y cómo documentarlas

Duplicado: comentar “Duplicado de BUG-123” y enlazar con relación duplicates/is duplicated by. Mantener un solo bug como fuente.
No reproducible: indicar intentos realizados (entorno, versión, datos), pedir información específica (usuario, datos, hora, logs). Evitar cerrar sin pedir lo mínimo.
Esperado / By design: citar la regla o decisión (enlace a historia/criterio/decisión de producto) y cerrar con resolución adecuada.
Bloqueado por dependencia: enlazar issue dependiente (por ejemplo, un bug en API o una tarea de infraestructura) y marcar el estado como bloqueado/“En análisis” con nota clara.

Workflow de bug alineado a QA y criterios de transición

Un flujo claro evita “ping-pong” entre desarrollo y QA. El siguiente workflow propuesto se centra en asegurar que cada transición tenga criterios verificables y que el bug llegue a QA con evidencia de fix y contexto suficiente para re-test.

Estados propuestos

Abierto: bug registrado, pendiente de revisión inicial/triage.
En análisis: se confirma reproducibilidad, se investiga causa/alcance, se define severidad/prioridad y plan de corrección.
En progreso: desarrollo trabajando en la corrección.
Listo para QA: fix implementado y desplegado en ambiente de prueba; listo para re-test.
Reabierto: QA valida que el problema persiste o hay regresión relacionada.
Cerrado: QA verifica fix y no hay regresiones relevantes; se documenta evidencia del re-test.

Criterios de transición (Definition of Done por estado)

Transición	Criterios mínimos	Evidencia/artefactos esperados
Abierto → En análisis	Revisión inicial completada; se intentó reproducir; se identificó componente/área	Comentario con resultado de reproducción y notas de alcance
En análisis → En progreso	Causa probable o hipótesis; decisión de corregir; asignación a responsable; prioridad definida	Campos actualizados (severidad/prioridad), asignatario, links a dependencias
En progreso → Listo para QA	Fix mergeado; build disponible en ambiente acordado; se actualizó versión/build; se describió qué cambió	Enlace a PR/commit, número de build, notas de fix, evidencia técnica (log/resultado unitario si aplica)
Listo para QA → Cerrado	QA ejecutó re-test con pasos del bug; validó esperado; verificó escenarios de riesgo acordados	Comentario con pasos ejecutados, resultado, evidencia del re-test (captura/video/log) y versión verificada
Listo para QA → Reabierto	Falla persiste o aparece regresión; se detallan diferencias vs intento anterior	Evidencia nueva, actualización de “Resultado actual”, notas de entorno/datos
Reabierto → En progreso	Dev confirma y retoma; se ajusta hipótesis/alcance	Comentario de análisis adicional y plan de corrección

Buenas prácticas específicas para “Listo para QA”

Adjuntar evidencia del fix: por ejemplo, captura del endpoint respondiendo correctamente, log sin error, o nota técnica de qué validación se agregó.
Indicar exactamente dónde probar: URL, feature flag, usuario/rol, datos de prueba. Si cambió el flujo, actualizar pasos sugeridos para re-test.
Controlar el alcance del re-test: listar 2–5 escenarios de riesgo (por ejemplo, “cupón con guion”, “cupón sin guion”, “cupón inválido”, “usuario invitado”).

Guía práctica: triage y ciclo de vida en una sesión real

1) Preparación (antes del triage)

Filtra bugs en Abierto sin asignatario.
Agrupa por componente (Frontend, API, Mobile) o por módulo (Checkout, Login).
Ten a mano versión actual de QA/UAT y calendario de release.

2) Durante el triage: decisiones rápidas con registro claro

Si es duplicado: enlaza al bug master y mueve el duplicado a Cerrado con resolución “Duplicado”.
Si no es reproducible: deja el bug en En análisis y solicita datos concretos (usuario, hora, request id, dataset). Evita “no se reproduce” sin detalle.
Si es esperado: cierra con resolución “No es un bug/By design” y referencia la decisión/regla.
Si está bloqueado: enlaza la dependencia y registra el bloqueo (por ejemplo, “Bloqueado por API-77”). Mantén el bug en En análisis hasta que la dependencia se resuelva.
Si se corrige: define severidad y prioridad, asigna y pasa a En progreso.

3) Re-test en “Listo para QA”: checklist de verificación

Confirmar versión/build indicada en el bug.
Ejecutar pasos originales y validar esperado.
Probar variantes de riesgo acordadas (mínimas y relevantes).
Registrar evidencia del re-test y resultado en el bug.
Si falla: mover a Reabierto y actualizar “Resultado actual” con evidencia nueva.

Ahora responde el ejercicio sobre el contenido:

Durante el triage de defectos en Jira, ¿qué acción es la más adecuada cuando se detecta que un bug es duplicado de otro ya registrado?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

En triage, si un bug es duplicado se debe enlazar al bug “master” usando la relación de duplicidad y mantener una sola fuente de seguimiento. El duplicado se cierra dejando un comentario con la referencia.