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

Tableros, filtros y reportes en Jira para visibilidad de calidad

Capítulo 9

Tiempo estimado de lectura: 9 minutos

Qué aportan tableros, filtros y reportes a la visibilidad de calidad

En Jira, la visibilidad de calidad se construye combinando filtros (consultas guardadas), tableros (dashboards con gadgets) y reportes (tendencias y distribución). La idea es transformar datos operativos (issues de pruebas y defectos) en señales claras para decidir: qué ejecutar hoy, qué está bloqueando, dónde se concentra el riesgo y si la calidad mejora o empeora sprint a sprint.

Principios para que la visibilidad sea útil

Una pregunta por filtro: cada JQL debe responder una necesidad concreta (p. ej., “¿qué pruebas faltan por ejecutar en este sprint?”).
Segmentación consistente: usa campos estables para cortar la información: project, fixVersion, sprint, component, environment (o campo equivalente), priority/severity, labels.
Definiciones explícitas: documenta qué significa “pendiente”, “revalidación”, “bloqueado”, “defecto abierto” según tus estados y campos.
Accionable = con umbrales: define límites que disparen acciones (p. ej., “más de 10 bugs críticos abiertos” o “más de 5 bloqueados por entorno”).

JQLs clave para QA (con ejemplos prácticos)

Los ejemplos asumen que gestionas pruebas como issues (por ejemplo, tipo Test o Test Execution) y defectos como Bug. Ajusta nombres de tipos, estados y campos a tu instancia (Company-managed vs Team-managed) y a tu flujo.

1) Pendientes de ejecutar (backlog de ejecución)

Objetivo: listar pruebas planificadas para un sprint/versión que aún no se han ejecutado.

Ejemplo por sprint (si usas campo Sprint):

project = QA AND issuetype in (Test, "Test Execution") AND Sprint in openSprints() AND status in ("To Do", "Ready", "Not Run") ORDER BY priority DESC, updated DESC

Ejemplo por versión (si usas fixVersion en pruebas):

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

project = QA AND issuetype in (Test, "Test Execution") AND fixVersion = "1.8.0" AND status in ("To Do", "Ready", "Not Run")

Variación útil: pendientes asignadas a un tester o equipo.

project = QA AND issuetype in (Test, "Test Execution") AND Sprint in openSprints() AND status in ("To Do", "Ready", "Not Run") AND assignee = currentUser()

2) Fallos por componente (dónde se concentra el riesgo)

Objetivo: identificar componentes con más fallos para priorizar correcciones, refuerzo de pruebas o análisis de causa raíz.

JQL base (bugs abiertos o creados en un periodo):

project = APP AND issuetype = Bug AND statusCategory != Done AND component is not EMPTY

Acotado por versión:

project = APP AND issuetype = Bug AND fixVersion = "1.8.0" AND statusCategory != Done

En el tablero, este filtro se vuelve potente al usar gadgets de distribución (p. ej., “Two Dimensional Filter Statistics” con component).

3) Bloqueados por entorno (cuellos de botella operativos)

Objetivo: detectar bloqueos de ejecución o validación causados por entornos inestables/no disponibles.

Requisito recomendado: tener un campo Environment (o custom field como “Entorno afectado”) y un estado o flag de bloqueo (p. ej., Blocked o Flagged).

Ejemplo con estado “Blocked”:

project = QA AND issuetype in (Test, "Test Execution") AND status = Blocked AND "Environment" is not EMPTY

Ejemplo con bandera (si tu Jira usa “Flagged”):

project = QA AND issuetype in (Test, "Test Execution") AND Flagged is not EMPTY AND "Environment" is not EMPTY

Acotado a sprint abierto:

project = QA AND issuetype in (Test, "Test Execution") AND Sprint in openSprints() AND status = Blocked

4) Bugs por severidad (priorización de impacto)

Objetivo: visualizar el volumen de defectos por severidad para decidir foco de corrección y criterios de salida.

Si tienes campo “Severity”:

project = APP AND issuetype = Bug AND statusCategory != Done AND Severity in (Blocker, Critical, Major, Minor)

Si no hay severidad y usas Priority:

project = APP AND issuetype = Bug AND statusCategory != Done AND priority in (Highest, High, Medium, Low)

Consejo práctico: evita mezclar severidad e impacto sin definición; documenta un mapeo (p. ej., “Critical = caída del flujo principal sin workaround”).

5) Revalidaciones pendientes (regresión focalizada)

Objetivo: asegurar que los defectos corregidos se revalidan y no quedan “en limbo”.

Patrón típico: estado del bug “Ready for QA” / “To Verify” / “In Verification”.

project = APP AND issuetype = Bug AND status in ("Ready for QA", "To Verify", "In Verification") ORDER BY updated ASC

Acotado a versión objetivo:

project = APP AND issuetype = Bug AND fixVersion = "1.8.0" AND status in ("Ready for QA", "To Verify")

Variación por responsable de revalidación:

project = APP AND issuetype = Bug AND status in ("Ready for QA", "To Verify") AND assignee in membersOf("qa-team")

Guía paso a paso: construir filtros JQL reutilizables

Paso 1: define el “contrato” del filtro

Pregunta: ¿qué decisión habilita? (p. ej., “¿qué ejecutar hoy?”).
Alcance: proyecto(s), sprint/versión, equipo.
Campos: estados, severidad, componente, entorno.

Paso 2: crea la consulta en Issue Navigator

Ve a Filters → Advanced issue search.
Empieza por lo más estable: project, issuetype, status.
Agrega segmentación: Sprint o fixVersion, component, Severity/priority, Environment.
Ordena para facilitar la acción: ORDER BY priority DESC, updated ASC.

Paso 3: valida con casos reales

Comprueba que el filtro devuelve issues “esperadas” (al menos 10–30 para validar patrones).
Revisa falsos positivos: estados mal incluidos, issues sin versión, componentes vacíos.
Si hay inconsistencias de datos, crea un filtro de “higiene” (p. ej., bugs sin componente o sin severidad).

Paso 4: guarda y estandariza el nombre

Paso 5: comparte con permisos correctos

Comparte con el rol adecuado (QA, Dev, PO) para evitar tableros “rotos”.
Si el filtro alimenta gadgets, asegúrate de que el público del dashboard tenga acceso al filtro y a los proyectos.

Dashboards orientados a calidad: diseño y gadgets recomendados

Un dashboard de calidad efectivo suele tener tres zonas: ejecución (qué se está probando), defectos (qué está abierto y su riesgo), y tendencias (si mejoramos o empeoramos). A continuación, una propuesta práctica con gadgets típicos de Jira (los nombres pueden variar según edición/marketplace).

Zona 1: Estado de ejecuciones (operación diaria)

Filter Results: lista “Pendientes de ejecutar” (máx. 10–20) ordenada por prioridad/edad.
Pie Chart o Filter Statistics: distribución de pruebas por status (Not Run / In Progress / Passed / Failed / Blocked).
Two Dimensional Filter Statistics: assignee vs status para ver carga y bloqueos por persona/equipo.

Filtro sugerido (ejecuciones del sprint):

project = QA AND issuetype in (Test, "Test Execution") AND Sprint in openSprints()

Zona 2: Defectos abiertos por edad (riesgo y deuda)

La “edad” ayuda a detectar deuda y atascos. Puedes aproximarla con created o, si tu flujo lo permite, con el tiempo desde que entró en “Open/To Do”.

Created vs Resolved Chart: tendencia de creación vs resolución de bugs (ideal por sprint o por release).
Average Age Chart (si está disponible) o Filter Results ordenado por created ASC para ver los más antiguos.
Pie Chart: bugs abiertos por severidad.

Filtro sugerido (bugs abiertos en release):

project = APP AND issuetype = Bug AND fixVersion = "1.8.0" AND statusCategory != Done

Lista de “más antiguos”:

project = APP AND issuetype = Bug AND statusCategory != Done ORDER BY created ASC

Zona 3: Tendencias y distribución por componentes (foco de mejora)

Two Dimensional Filter Statistics: component vs Severity para ver hotspots (componente con críticos).
Pie Chart: bugs por componente (si hay muchos, limita a Top N con un filtro por periodo o release).
Created vs Resolved Chart: por componente (duplicando gadget con filtros distintos) para comparar áreas.

Filtro sugerido (bugs recientes para evitar ruido histórico):

project = APP AND issuetype = Bug AND created >= -30d

Zona 4: Bloqueos y revalidaciones (flujo de salida)

Filter Results: “Bloqueados por entorno” para escalar a DevOps/Infra.
Filter Results: “Revalidaciones pendientes” para asegurar cierre real.
Pie Chart: bloqueados por Environment (si el campo existe).

Guía paso a paso: crear un dashboard de calidad

Paso 1: define audiencia y cadencia

Daily QA: foco en ejecución, bloqueos, revalidaciones.
Sync QA-Dev: foco en severidad, componentes, edad de bugs.
Review de sprint/release: foco en tendencias (creados vs resueltos) y distribución.

Paso 2: crea el dashboard y estructura en columnas

Ve a Dashboards → Create dashboard.
Usa 2 o 3 columnas: izquierda “acción inmediata”, centro “riesgo”, derecha “tendencias”.

Paso 3: añade gadgets y conéctalos a filtros guardados

Empieza por 4–6 gadgets máximo (evita tableros saturados).
Para cada gadget, selecciona un filtro guardado (JQL) y configura el campo de agrupación (status, severity, component, environment).
Configura el refresco automático si el equipo lo usa en daily.

Paso 4: valida permisos y consistencia

Abre el dashboard con un usuario “tipo” (QA/Dev/PO) para verificar acceso.
Si un gadget aparece vacío, revisa: permisos del filtro, permisos del proyecto, y si el filtro está demasiado acotado (sprint cerrado, versión incorrecta).

Criterios para que los reportes sean accionables

1) Umbrales (triggers) que disparan acciones

Señal	Umbral ejemplo	Acción recomendada
Bugs críticos abiertos	> 0 en release candidate	Bloquear promoción; war-room de corrección
Bugs abiertos totales	> 20 en sprint final	Repriorizar alcance; enfocar en top severidades
Bloqueados por entorno	> 5 por > 24h	Escalar a Infra/DevOps; plan alterno de pruebas
Revalidaciones pendientes	> 10 o > 2 días en “To Verify”	Asignar capacidad QA; definir ventana de verificación
Pruebas pendientes de ejecutar	> 30% del plan a mitad de sprint	Rebalancear asignaciones; recortar o automatizar

2) Segmentación por versión/sprint (evitar decisiones con datos mezclados)

Para operación diaria: filtra por Sprint in openSprints().
Para salida a producción: filtra por fixVersion = "X.Y.Z" y define qué significa “incluido en release”.
Para análisis de tendencia: usa ventanas temporales (created >= -30d) o compara sprints con gadgets de “Created vs Resolved”.

3) Lectura orientada a decisiones (no solo métricas)

Si suben los bugs creados y no suben los resueltos: riesgo de acumulación; negociar alcance o aumentar capacidad de corrección.
Si un componente concentra críticos: priorizar refactor/estabilización y reforzar pruebas en esa área.
Si crecen los bloqueos por entorno: el problema no es “calidad del código” sino “capacidad de probar”; activar plan de estabilización del entorno.
Si hay muchas revalidaciones pendientes: cuello de botella en QA; ajustar WIP, asignación o automatización de smoke/regresión.

4) Filtros de higiene de datos (para que el dashboard no mienta)

Incluye 1–2 gadgets de “calidad del dato” para corregir la fuente:

Bugs sin componente:

project = APP AND issuetype = Bug AND statusCategory != Done AND component is EMPTY

Bugs sin severidad (si existe el campo):

project = APP AND issuetype = Bug AND statusCategory != Done AND Severity is EMPTY

Estos filtros ayudan a que la distribución por componentes/severidad sea confiable y que las decisiones basadas en el dashboard sean consistentes.

Ahora responde el ejercicio sobre el contenido:

Para que un dashboard de calidad en Jira no “mienta” por datos incompletos, ¿qué práctica ayuda directamente a mejorar la confiabilidad de las distribuciones por componente y severidad?

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

¡Tú error! Inténtalo de nuevo.

Los filtros de higiene detectan issues con campos clave vacíos (como componente o severidad). Al corregir esos datos, las estadísticas y gráficos del dashboard reflejan distribuciones más confiables para tomar decisiones.