Configuración de Jira orientada a flujos de pruebas y control de calidad

Objetivo de la configuración orientada a QA

Una configuración de Jira orientada a flujos de pruebas busca dos cosas: (1) que el equipo pueda ejecutar y registrar pruebas con el mínimo de fricción y (2) que el sistema fuerce la trazabilidad mínima (qué se probó, en qué entorno/build, con qué evidencia y con qué resultado). Para lograrlo, conviene separar claramente artefactos (casos/planes/ejecuciones/defectos) y estandarizar campos, workflows y reglas (validadores y post-functions) que eviten cierres “vacíos”.

Estructura recomendada del proyecto y tipos de issue

Opciones de estructura (elige una)

• Un solo proyecto (Scrum/Kanban) con tipos de issue de QA: útil si QA trabaja muy pegado al backlog y se quiere reporting unificado.
• Proyecto de QA separado: útil si hay múltiples equipos/productos y QA centralizado; requiere más disciplina de enlaces y permisos.

En ambos casos, define tipos de issue que representen el flujo real de pruebas. Un set típico:

• Test Case: especificación reutilizable (pasos, datos, criterio de aceptación de prueba).
• Test Plan: agrupación de casos para un objetivo (release, sprint, hotfix).
• Test Execution: instancia ejecutable del plan/casos para un build/entorno específico (donde vive el resultado).
• Bug: defecto encontrado (con enlace a la ejecución/caso).

Si tu instancia usa una app de gestión de pruebas (p. ej., Xray, Zephyr, TestRail integration), alinea estos tipos con los artefactos de la herramienta. Si no, puedes implementarlos con issue types nativos y convenciones de enlaces.

Campos necesarios para pruebas: definición y buenas prácticas

Los campos deben ser consistentes (mismos nombres y valores) para permitir filtros, tableros y reportes. A continuación, un set mínimo con recomendaciones de tipo de campo y ejemplos.

Campos de evidencia (mínimos para control de calidad)

• Evidencia (Attachment + campo de texto): capturas, logs, video, reporte de herramienta, o enlace a repositorio de evidencias.
• Resultado (Select): Pasó / Falló / Bloqueado (si no lo modelas como estado).
• Notas de ejecución (Text multi-line): pasos relevantes, datos usados, observaciones.
• Fecha/hora de ejecución (Date/Time): útil para auditoría y correlación con despliegues.

Recomendación: evita duplicar “Severidad” en ejecuciones; úsala en Bugs. En ejecuciones, prioriza campos del contexto (entorno/build/versión) y evidencia.

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

Guía práctica: crear campos y aplicarlos con contextos

Paso a paso (Jira Cloud/Server con conceptos equivalentes)

1. Crear campos personalizados: ve a administración de Jira > Issues > Custom fields y crea los campos (selects para listas controladas; Component/s y Fix Version/s si aplica).
2. Definir valores estándar: para Prioridad de prueba, Severidad y Riesgo, crea listas cerradas y documenta su significado en una página interna (p. ej., Confluence o LMS corporativo).
3. Configurar contextos por tipo de issue: limita campos a los issue types de QA (por ejemplo, “Entorno” y “Build” solo para Test Execution). Esto reduce ruido en otros tickets.
4. Asociar campos a pantallas: añade los campos a Create/Edit/View screens del issue type correspondiente (ver sección de pantallas).
5. Validar con un filtro de control: crea un JQL para detectar ejecuciones incompletas, por ejemplo: issuetype = "Test Execution" AND status in ("Pasó","Falló") AND (attachments is EMPTY OR "Entorno" is EMPTY OR "Build" is EMPTY).

Diseño de workflows de QA con estados claros

Un workflow de QA debe reflejar el ciclo real de una ejecución y facilitar métricas (lead time de validación, bloqueos, revalidaciones). Un ejemplo de estados:

• Por validar: pendiente de ejecución.
• En ejecución: QA está probando.
• Bloqueado: no se puede continuar (dependencia, ambiente caído, falta de build).
• Falló: se encontró un problema reproducible (idealmente con bug enlazado).
• Pasó: validación completada sin hallazgos.
• Revalidación: se re-ejecuta tras un fix o cambio de build.

Reglas de transición recomendadas

• Por validar → En ejecución: requiere que “Entorno” y “Build” estén informados (para evitar ejecuciones sin contexto).
• En ejecución → Bloqueado: requiere “Motivo de bloqueo” (campo texto o select) y, si aplica, enlace a ticket de infraestructura.
• En ejecución → Falló: requiere evidencia mínima y, preferiblemente, un bug enlazado o creado desde la transición.
• En ejecución → Pasó: requiere evidencia mínima (captura/log) y notas de ejecución.
• Falló → Revalidación: requiere que el bug asociado esté en estado “Listo para QA” o que se indique un nuevo build.
• Revalidación → Pasó/Falló: mismas reglas de evidencia que en ejecución.

Consejo: evita transiciones “directas” que salten control (p. ej., Por validar → Pasó) salvo para casos muy específicos y con permisos restringidos.

Pantallas (screens): qué mostrar y cuándo

Las pantallas son la primera línea para reducir fricción: muestran solo lo necesario en cada momento. Una práctica efectiva es separar pantallas por operación:

• Create screen (Test Execution): Resumen, Descripción/alcance, Entorno, Build, Versión, Componente, Prioridad de prueba, Riesgo.
• Edit screen: todo lo anterior + Notas de ejecución.
• View screen: incluye Evidencia (attachments), enlaces a Bugs, historial de transiciones.
• Transition screens: específicas para “Pasó”, “Falló” y “Bloqueado” con campos obligatorios.

Ejemplo de pantalla de transición “En ejecución → Falló”

• Campo obligatorio: Notas de ejecución (qué se intentó, datos, resultado observado).
• Campo obligatorio: Evidencia (al menos 1 adjunto o enlace).
• Campo recomendado: Bug asociado (Issue link) o acción “Crear bug”.
• Campo opcional: Severidad (si se captura en el bug, no aquí).

Validadores: impedir cierres sin evidencia mínima

Los validadores bloquean una transición si no se cumplen condiciones. Úsalos para asegurar calidad de datos sin depender de recordatorios.

Validaciones mínimas sugeridas

• Para pasar a “Pasó”: Entorno no vacío, Build no vacío, al menos 1 adjunto o un campo “Evidencia (URL)” no vacío, Notas de ejecución no vacías.
• Para pasar a “Falló”: evidencia mínima + descripción reproducible (Notas) + (opcional pero recomendado) existencia de bug enlazado.
• Para pasar a “Bloqueado”: Motivo de bloqueo no vacío + (si aplica) enlace a dependencia.

Si tu Jira no permite validar “attachments >= 1” de forma nativa, considera: (a) exigir un campo “Evidencia (URL)” obligatorio, (b) usar automatización que revierta/alerta, o (c) una app de workflow/validators si está permitida por tu organización.

Post-functions: automatizar trazabilidad y consistencia

Las post-functions ejecutan acciones al completar una transición. Úsalas para reducir trabajo manual y estandarizar datos.

Post-functions útiles en QA

• Al transicionar a “En ejecución”: setear “Fecha/hora de inicio de ejecución”.
• Al transicionar a “Pasó/Falló”: setear “Fecha/hora de fin de ejecución” y “Ejecutado por” (assignee o reporter según convención).
• Al transicionar a “Falló”: crear automáticamente un Bug con campos prellenados (Entorno, Build, Versión, Componente) y enlazarlo a la ejecución.
• Al transicionar a “Revalidación”: limpiar/actualizar campos que deban cambiar (por ejemplo, nuevo Build) y añadir comentario estándar solicitando re-evidencia.

Ejemplo de automatización (regla conceptual)

Trigger: Issue transitioned to "Falló" (issuetype = Test Execution) Actions: Create issue (Bug) with summary = "[QA] Falla en {Test Execution key}: {summary}" Copy fields: Entorno, Build, Fix Version/s, Component/s Link issues: "is caused by" Add comment to Test Execution with created Bug key

Permisos, esquemas y convenciones para evitar fricción

Permisos (permission scheme)

• Quién puede transicionar a “Pasó/Falló”: normalmente QA; evita que perfiles no QA cierren ejecuciones sin contexto.
• Quién puede editar campos críticos: restringe edición de Entorno/Build tras cierre (o usa un estado “Cerrado” con edición limitada) para mantener auditoría.
• Adjuntos: habilita a QA a adjuntar evidencias; limita borrado de adjuntos a administradores o leads para no perder trazabilidad.
• Linking issues: permite a QA enlazar Bugs y Ejecuciones; esto es clave para trazabilidad.

Esquemas (issue type scheme, field configuration, workflow scheme)

• Field configuration: marca como requeridos solo los campos que realmente deben ser obligatorios en creación; el resto, obligatorios en transiciones mediante pantallas/validadores.
• Workflow scheme: evita reutilizar el workflow de desarrollo para ejecuciones de QA; los estados y métricas son distintos.
• Component leads: asigna responsables por componente para acelerar triage de bugs.

Convenciones operativas

• Nombres consistentes: usa un prefijo para tipos de QA si convive con otros (p. ej., “Test Execution” en inglés o “Ejecución de Prueba” en español, pero no ambos).
• Definición de “evidencia mínima”: acuerda qué cuenta como evidencia (captura + log, video, reporte de pipeline) y refléjalo en validadores.
• Regla de enlace: todo “Falló” debe tener al menos un Bug enlazado o una justificación explícita (campo “Sin bug porque…” con lista controlada).
• Plantillas: usa plantillas en Descripción/Notas (p. ej., “Pasos”, “Datos”, “Resultado esperado/observado”) para mejorar reproducibilidad.

Implementación paso a paso: checklist de configuración

1. Define el modelo: decide si usarás tipos Test Case/Plan/Execution o solo Execution + Bug (mínimo viable).
2. Crea issue types y asócialos al proyecto (issue type scheme).
3. Crea campos (prioridad de prueba, entorno, build, versión, severidad, componente, riesgo) y limita contextos por issue type.
4. Configura pantallas: Create/Edit/View + pantallas de transición para Pasó/Falló/Bloqueado.
5. Diseña workflow con estados: Por validar, En ejecución, Bloqueado, Falló, Pasó, Revalidación.
6. Agrega validadores en transiciones críticas (Pasó/Falló) para exigir evidencia mínima y contexto.
7. Agrega post-functions/automatizaciones: timestamps, creación de bug, copiado de campos, enlaces.
8. Ajusta permisos: transiciones restringidas, control de adjuntos, edición post-cierre.
9. Prueba con casos reales: ejecuta 5–10 tickets de ejemplo y verifica que (a) no se puede cerrar sin evidencia, (b) los reportes salen con JQL, (c) el equipo no siente fricción innecesaria.