Ejecución de pruebas en Jira con control de estados y resultados

Planificación de ejecuciones por iteración (sin entrar en planificación de estudio)

En un proyecto ágil, la ejecución de pruebas suele organizarse por iteración (sprint) para asegurar que lo entregado se valida dentro del mismo ciclo. En Jira, esto se traduce en preparar una ejecución (o conjunto de ejecuciones) con un alcance claro: qué casos se van a correr, en qué entorno, con qué datos y qué parte de la regresión se incluye. El objetivo es que el equipo pueda responder con evidencia a preguntas como: ¿qué se probó?, ¿dónde?, ¿con qué resultado?, ¿qué quedó bloqueado y por qué?

1) Selección de casos para la iteración

Selecciona los casos de prueba que correspondan al incremento del sprint y a la regresión mínima necesaria. Evita “meter todo” por defecto: define un criterio repetible para que el alcance sea defendible y comparable entre iteraciones.

• Casos del sprint: casos vinculados a historias/tareas del sprint actual (por ejemplo, historias en estado “Listo para QA”).
• Regresión por riesgo: casos críticos por impacto (pagos, login, permisos, integraciones) o por historial de defectos.
• Regresión por cambio: casos que cubren áreas tocadas por el desarrollo (módulos afectados, endpoints, reglas de negocio).

Ejemplo práctico: en el Sprint 12 se entregan cambios en “Carrito” y “Cupones”. Seleccionas (a) todos los casos asociados a esas historias y (b) una regresión mínima: login, búsqueda, checkout, cálculo de impuestos y validación de stock.

2) Definición de entornos para ejecutar

Antes de ejecutar, define explícitamente el/los entornos permitidos y sus condiciones. Esto evita resultados ambiguos (por ejemplo, fallos por configuración) y facilita revalidaciones.

• Entorno: QA, Staging, UAT, Preproducción, etc.
• Versión/build: número de build, tag, commit o versión desplegada.
• Dependencias: servicios externos, colas, integraciones, feature flags.
• Disponibilidad: ventanas de mantenimiento, restricciones de acceso.

En Jira, registra estas condiciones como campos de la ejecución o como información estructurada en un comentario/plantilla (según tu implementación). Lo importante es que quede auditable y consistente entre ejecuciones.

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

3) Datos de prueba y precondiciones

Define qué datos se usarán y cómo se repondrán si se consumen (por ejemplo, cupones de un solo uso). Si no se controla, aparecen falsos fallos y re-ejecuciones innecesarias.

• Usuarios: roles, credenciales, MFA, permisos.
• Catálogo: productos con stock, sin stock, con impuestos especiales.
• Transacciones: tarjetas de prueba, cuentas sandbox, respuestas simuladas.
• Reset: scripts o pasos para limpiar datos entre corridas.

Ejemplo: “Usuario QA_ADMIN_03 (rol admin), cupón CUPON10 (10 usos), producto SKU-123 con stock=50, pasarela en modo sandbox”.

4) Alcance de regresión

Define el alcance de regresión como un subconjunto estable y repetible. Una forma práctica es clasificar casos por etiqueta o componente (por ejemplo, regresion-minima, regresion-completa, critico) y seleccionar según el objetivo del sprint.

Registro de resultados en Jira: pasó / falló / bloqueado

Registrar resultados no es solo marcar un estado; es capturar evidencia mínima para que el equipo pueda actuar: reproducir fallos, desbloquear impedimentos y decidir re-ejecuciones. Los tres resultados más comunes son:

• Pasó (Pass): el comportamiento observado coincide con el esperado bajo las condiciones registradas.
• Falló (Fail): el comportamiento observado no coincide con el esperado; debe quedar evidencia y, normalmente, un defecto asociado.
• Bloqueado (Blocked): no se pudo ejecutar por una dependencia externa al caso (entorno caído, datos no disponibles, bug previo que impide avanzar, permisos).

Qué evidencia registrar en cada resultado

Usa un estándar de evidencia para que los resultados sean comparables. Un patrón útil es: Qué se hizo, qué se esperaba, qué ocurrió, dónde (entorno/build), y prueba (capturas/logs).

• Para “Pasó”: referencia breve a la evidencia (captura clave o log) y confirmación de entorno/build.
• Para “Falló”: pasos mínimos para reproducir, resultado esperado vs actual, evidencia (captura/video/log), severidad/impacto y enlace al issue de bug.
• Para “Bloqueado”: causa concreta del bloqueo, dependencia responsable (servicio, equipo, permiso), y qué condición debe cumplirse para reintentar.

Ejemplo de comentario estructurado (falló):

Entorno: Staging | Build: 2.18.0-rc3 | Feature flag: COUPONS=true Paso: Aplicar cupón CUPON10 en carrito con SKU-123 Esperado: descuento 10% y total recalculado Actual: error 500 al confirmar Evidencia: screenshot_2026-02-04.png + log requestId=ab12-34 Bug: PROJ-456

Guía práctica paso a paso: ejecutar y controlar estados en Jira

Paso 1: Crear/seleccionar la ejecución de la iteración

• Crea una ejecución para el sprint (o reutiliza una plantilla) y nómbrala de forma consistente: Sprint 12 - Staging - Regresión mínima.
• Completa campos clave: entorno, build/versión, fecha, responsable, componente.
• Define el alcance: añade los casos seleccionados (del sprint + regresión definida).

Paso 2: Registrar condiciones del entorno antes de correr

Antes del primer resultado, registra el “estado inicial” del entorno. Esto reduce discusiones posteriores sobre si el fallo era del producto o del contexto.

• Versión desplegada y hora.
• Integraciones activas (sandbox/prod, mocks).
• Feature flags relevantes.
• Datos preparados (usuarios, cupones, SKUs).

Si tu flujo lo permite, usa un campo tipo “Condiciones de ejecución” o una checklist. Si no, utiliza un comentario fijado (pinned) o el primer comentario de la ejecución con formato estándar.

Paso 3: Ejecutar caso por caso y marcar resultado

• Abre el caso, sigue los pasos y valida el resultado esperado.
• Marca Pasó/Falló/Bloqueado inmediatamente (evita “lo marco después”).
• Adjunta evidencia mínima: captura, log o referencia a herramienta externa (por ejemplo, enlace a reporte de CI o a un artefacto).

Paso 4: Si falla, crear/relacionar el bug y mantener trazabilidad

Cuando un caso falla, el resultado debe quedar conectado a una acción correctiva. La práctica recomendada es crear un issue de bug y vincularlo al resultado de ejecución.

• Crea el bug desde la ejecución (si tu integración lo permite) o manualmente.
• Incluye: entorno/build, pasos, esperado vs actual, evidencia, impacto.
• Vincula el bug al caso y/o a la ejecución para que el reporte muestre “fallos con defecto asociado”.

Paso 5: Si está bloqueado, reflejar impedimentos

“Bloqueado” debe disparar visibilidad de impedimento. No lo uses como “no tuve tiempo”. Registra el motivo y crea el elemento de seguimiento correspondiente (según tu forma de trabajo): impedimento, tarea de soporte, incidente o bug bloqueante.

• Marca el caso como Bloqueado.
• Indica causa y dependencia: “Staging sin acceso VPN”, “Servicio de pagos sandbox caído”, “Bug PROJ-450 impide avanzar”.
• Vincula el issue que representa el impedimento.

Ejemplo (bloqueado):

Bloqueo: No se puede autenticar usuario QA_ADMIN_03 Causa: proveedor de identidad devuelve 503 Dependencia: Incidente OPS-77 Condición para reintentar: IdP estable + confirmación de OPS

Re-ejecuciones y revalidación tras correcciones

En Jira, re-ejecutar no significa “editar el resultado anterior” sin más. La idea es conservar el historial: qué falló, cuándo se corrigió y cuándo se validó. Esto mejora la trazabilidad y evita confusiones en auditorías o revisiones de sprint.

Cuándo re-ejecutar

• Se desplegó una corrección del bug asociado.
• Cambió el entorno o la configuración (por ejemplo, feature flag).
• Se repusieron datos o se resolvió el impedimento.

Cómo manejar la re-ejecución sin perder consistencia

• Regla 1: registra la nueva ejecución con el build corregido y condiciones actualizadas.
• Regla 2: si tu herramienta soporta múltiples corridas por caso, crea un nuevo “run” o “iteration” del resultado; si no, añade un nuevo registro/comentario con timestamp y evidencia.
• Regla 3: vincula la revalidación al bug (por ejemplo, “Verificado en build 2.18.0-rc4”).

Ejemplo de revalidación:

Re-ejecución: 2026-02-04 16:20 Entorno: Staging | Build: 2.18.0-rc4 Resultado: PASÓ Evidencia: video_retest_rc4.mp4 Bug PROJ-456: verificado y listo para cierre

Re-ejecución parcial vs completa

No siempre hace falta correr toda la suite. Define un criterio:

• Parcial: re-ejecuta el caso fallido + casos colaterales (mismo componente, mismo flujo).
• Completa: si la corrección afecta componentes transversales (autenticación, pagos, permisos) o si hubo cambios amplios.

Consistencia del flujo: transiciones y campos obligatorios durante la ejecución

Para que los reportes sean confiables, el flujo de ejecución debe forzar disciplina mínima: no permitir resultados sin contexto, ni cierres sin evidencia. Sin entrar en configuración detallada, aplica estas prácticas operativas al usar transiciones y campos obligatorios:

Campos mínimos recomendados al marcar resultados

Uso disciplinado de transiciones

• No muevas una ejecución a “Completada” si hay casos “Bloqueados” sin impedimento registrado o “Falló” sin bug asociado.
• Si el flujo incluye estados intermedios (por ejemplo, “En ejecución”, “En revalidación”), úsalos para reflejar el momento real del trabajo y evitar que el tablero muestre una imagen falsa del avance.
• Cuando cambie el build o el entorno, registra el cambio antes de continuar ejecutando para que los resultados posteriores queden bajo las nuevas condiciones.

Plantilla práctica para condiciones de ejecución (copiar/pegar)

Condiciones de ejecución Entorno: [QA/Staging/UAT] URL/Acceso: [si aplica] Build/Versión: [x.y.z / tag / commit] Configuración: [feature flags, mocks, integraciones] Datos: [usuarios, SKUs, cupones, cuentas sandbox] Observaciones: [incidencias conocidas del entorno]