Un bug marcado como "Fixed" que va directamente a "Closed" sin pasar por "Verified" es como las regresiones llegan a producción. Un bug que lleva tres sprints en "Assigned" es un ticket que nadie está mirando, no una corrección en progreso. Este artículo mapea cada estado del ciclo de vida del bug, quién es dueño de cada entrega, y qué hacer cuando los bugs se estancan, se marcan como Won't Fix o vuelven después de haberlos verificado.

Los estados estándar y quién es responsable de cada uno

Cada sistema de seguimiento de bugs tiene sus propias etiquetas, pero los estados subyacentes son universales. Saber quién tiene la responsabilidad en cada etapa te dice cuándo actuar y cuándo esperar.

New es el momento en que creas el ticket. Todavía no pasó nada. El bug existe en papel pero nadie se comprometió a corregirlo. Tu trabajo acá es dejar el reporte impecable: título claro, pasos de reproducción exactos, resultado esperado vs resultado actual, severidad, adjuntos. Un bug "New" mal escrito quedará dando vueltas en el triage porque quien lo tome no puede reproducirlo. Assigned significa que alguien del equipo de desarrollo es dueño del ticket. No significa que lo hayan revisado. No significa que estén de acuerdo en que es un bug. Significa que hay un nombre asignado. Este estado es donde los bugs envejecen. Más sobre eso después. In Progress significa que hay trabajo activo. Un desarrollador está reproduciendo, investigando o escribiendo una corrección. Como QA, tu trabajo acá es estar disponible: si el desarrollador tiene preguntas sobre el entorno de reproducción o los casos extremos, responde rápido. Los retrasos acá agregan peso al sprint. In Review significa que la corrección está escrita y esperando una revisión de código o aprobación de un par. Algunos equipos combinan esto con un estado "Ready for QA" que indica que el build está disponible para verificación. Conoce qué flujo usa tu equipo, porque la distinción importa para la planificación del sprint. Fixed (o "Ready for Testing") es la entrega de vuelta a ti. El desarrollador cree que el problema está resuelto. Ahora es tu turno. Verifica con los pasos de reproducción originales exactamente. No improvises un camino de test nuevo. Confirma que el escenario específico que se reportó está resuelto primero, luego expándete a los casos relacionados. Verified significa que confirmaste que la corrección funciona como se describió. El defecto original desapareció. Verificaste los caminos de regresión obvios. Este estado es tu visto bueno. Closed significa que el bug verificado está aceptado y terminado. En la mayoría de los equipos, lo hace el QA lead, el scrum master, o sucede automáticamente cuando el sprint cierra. Un bug nunca debería ir de Fixed a Closed sin pasar por Verified. Saltarse ese paso es como las regresiones llegan a producción.

El estado Rejected significa que el equipo decidió que el comportamiento reportado es en realidad correcto. O el resultado esperado en el reporte del bug era incorrecto, o el comportamiento es intencional por diseño, o quien reportó malentendió el requisito. Rejected no significa que fuiste descuidado. Es un resultado legítimo. Documenta por qué se rechazó para que los testers futuros no vuelvan a crear el mismo ticket.

Deferred significa que el bug es real y reconocido, pero no se va a corregir en este sprint o release. Va al backlog. Si alguna vez se corrige depende de qué tan bien argumentes su importancia. Won't Fix es Deferred permanente. El equipo decidió que este defecto no vale el esfuerzo de resolverlo. A veces es la decisión correcta. A veces no lo es. Cómo respondas determina si se convierte en un problema después.

Won't Fix y Deferred: cómo argumentar sin perder

Acá va un escenario real. Reportas un bug: "En la página de checkout, aplicar un código de descuento después de seleccionar un método de envío resetea la selección de envío a la opción por defecto." El PM lo triage y lo marca como Deferred. El comentario: "Bajo impacto, caso extremo, pocos usuarios se ven afectados."

Acá es donde la mayoría de los ingenieros QA aceptan en silencio o argumentan de forma emocional. Ninguno de los dos es efectivo.

El mejor enfoque es replantear la conversación alrededor de datos y flujos del usuario, no de tu opinión personal. Pregunta: ¿cuántas sesiones de checkout por semana incluyen un código de descuento? ¿Tu analytics muestra picos de abandono en ese paso? ¿El reset del envío está causando que los pedidos lleguen a la dirección incorrecta?

Si no tienes esos datos, dilo y pregunta quién puede obtenerlos. "Quiero entender la frecuencia real antes de cerrar esto. ¿Podemos revisar los datos del embudo de checkout de los últimos 30 días?" Eso es una solicitud razonable, no una pelea.

Si el PM igual quiere diferir después de ver los datos, documenta el riesgo explícitamente en el ticket. Escribe: "Riesgo aceptado: los usuarios que aplican códigos de descuento pueden seleccionar sin saberlo el método de envío incorrecto. Impacto: posibles errores en el despacho." Luego ciérralo. Hiciste tu trabajo. Si el problema escala después del release, hay un registro claro de que el riesgo fue planteado y documentado.

Para los bugs Won't Fix que involucran integridad de datos o seguridad del usuario, siempre agrega el enunciado de riesgo antes de cerrar. Una nota de riesgo de una línea te protege tanto a ti como al equipo de producto si el problema resurge después de un release.

Reabrir bugs sin crear drama

Un bug vuelve. Lo verificaste hace dos semanas, está en Closed, y ahora el mismo síntoma aparece en producción. Necesitas reabrirlo, pero el desarrollador que lo corrigió lo va a notar, y a nadie le gusta ver su trabajo cuestionado.

La regla es simple: reabre solo cuando puedes demostrar que el escenario original está fallando de nuevo. No "algo similar", no "podría estar relacionado". Los pasos de reproducción originales exactos, mismo entorno, mismo resultado.

Cuando reabras, agrega un comentario antes de cambiar el estado. Incluye: la fecha en que lo estás reabriendo, una nueva captura de pantalla o grabación, los pasos de reproducción exactos que ejecutaste (aunque sean idénticos al original), y si estás viendo el mismo síntoma o una variación nueva. Si es una variación nueva en el mismo componente, es un bug diferente, no uno reabierto.

Supongamos que verificaste que el bug del descuento-que-resetea-el-envío estaba corregido en v2.8.1. En v2.8.3, después de que se publicó una nueva función alrededor del flujo de checkout, el bug volvió. Lo reabres, adjuntas una grabación y anotas: "Regresión introducida en v2.8.3. Corrección presente en el build v2.8.1, ya no está presente en el build actual. Reabriendo con nueva grabación."

Ese encuadre hace dos cosas. Reconoce que la corrección original era válida. Señala hacia una nueva regresión en lugar de implicar que el desarrollador no lo corrigió bien la primera vez. Esa distinción importa para la relación de trabajo.

Bugs duplicados: identificación y fusión sin conflictos

En cualquier producto activo, múltiples testers pueden reportar el mismo bug de forma independiente, especialmente con funciones que acaban de publicarse. Identificar duplicados temprano ahorra tiempo de triage y evita el esfuerzo dividido de los desarrolladores.

Antes de crear un nuevo bug, busca en tu tracker el síntoma. Busca por componente primero (checkout, login, upload), luego por palabras clave del mensaje de error o comportamiento. Si trabajas en Jira, usa el panel "Similar Issues": busca automáticamente cuando estás creando un ticket.

Si encuentras un duplicado después de crearlo, marca el tuyo como duplicado del original (no al revés, a menos que el tuyo sea claramente más detallado). Agrega un comentario: "Marcando como duplicado de PROJ-144. Mismo camino de reproducción, mismo síntoma. Agrego mis capturas al ticket original por si ayudan."

Luego anda al ticket original y realmente agrega el valor de tu duplicado. Quizás tu versión tiene un video más claro o una versión de navegador diferente que lo reproduce. Esa información es útil aunque tu ticket se cierre como duplicado.

Lo que hay que evitar: fusionar bugs que parecen iguales pero no lo son. Si dos tickets tienen el mismo mensaje de error pero gatillos distintos, pueden ser dos defectos separados. Verifica la causa raíz antes de fusionar. Un desarrollador que corrige un bug basándose en un reporte fusionado y se pierde el segundo gatillo no va a estar contento cuando lo descubra en producción.

Envejecimiento de bugs: qué hacer cuando Assigned no significa nada

Reportaste un bug. Se triage, se asigna a un desarrollador, y luego nada pasa durante tres sprints. La revisión de sprint llega y pasa, sin mencionarlo. El ticket sigue en "Assigned" como un fósil.

Esta es una de las frustraciones más comunes en QA, y la respuesta correcta es visibilidad, no insistencia.

Primero, revisa el bug tú mismo. ¿La prioridad es precisa? ¿Sigue siendo un bloqueante de algo? Si el contexto cambió y el bug ahora es menos relevante, ajusta la prioridad y agrega un comentario. Un bug de baja prioridad que lleva tres sprints es menos alarmante que uno de prioridad media.

Si la prioridad es precisa y el bug sigue importando, plantéalo explícitamente en la revisión del sprint. No como una queja, sino como un elemento de riesgo. "Tenemos PROJ-188 en Assigned por tres sprints. Afecta la función de exportación CSV, que nuestros usuarios enterprise señalan con frecuencia. Quiero marcarlo para el próximo sprint antes de que se convierta en una escalada de cliente."

La mayoría de los bugs que envejecen mueren porque nadie los volvió a plantear. Las reuniones de revisión de sprint y refinamiento del backlog existen exactamente para esto.

Nunca vayas directamente con un desarrollador a preguntar por qué no corrigió un bug. Eso genera fricción y se salta el proceso del equipo. Plantea los bugs que envejecen a nivel de equipo durante las ceremonias del sprint.

Si el bug genuinamente no debería corregirse en el roadmap actual, pide que se marque formalmente como Deferred con una razón documentada. Un Deferred honesto es mejor que un ticket zombie en Assigned: le da al equipo una señal clara y evita impresiones falsas sobre el conteo de bugs abiertos.

Jira vs Linear vs GitHub Issues en 2026

La lógica del flujo descrita arriba aplica en todas partes, pero las herramientas con las que trabajás tienen diferencias reales en cómo implementan las transiciones de estado.

Jira sigue siendo el estándar en equipos medianos y grandes de empresas. En 2026 está en su tercera generación de flujos desde la separación entre company-managed y team-managed. Los estados de los bugs en Jira son totalmente personalizables, lo que significa que cada equipo usa un subconjunto diferente de los estados descritos arriba. Tu primera semana en un nuevo equipo que use Jira debería incluir entender exactamente qué significan sus estados de flujo. No asumas que "In Progress" significa que un desarrollador está trabajando activamente. En algunas configuraciones de Jira significa "reconocido pero no iniciado." Revisa la documentación del flujo o pregunta directamente. Linear es ahora el estándar en la mayoría de las startups en etapa temprana y de crecimiento. Usa un modelo de estados más simple: No Status, Backlog, Todo, In Progress, In Review, Done, Cancelled. No hay un estado "Verified" dedicado por defecto: la verificación de QA sucede dentro de "In Review" o los equipos agregan un estado personalizado. Si te unes a un equipo con Linear, verifica si tienen un paso de verificación de QA en el flujo. Si no lo tienen, propón uno. Un ticket que va de "In Review" a "Done" sin el visto bueno de un tester es un patrón que eventualmente publica correcciones sin verificar. GitHub Issues es común en productos open-source y de herramientas para desarrolladores. Su modelo nativo de estados es solo Open y Closed, con etiquetas para todo lo demás. La mayoría de los equipos que hacen QA estructurado en GitHub Issues usan etiquetas como status: ready for QA, status: verified y milestones para rastrear el alcance del release. La fricción acá es que GitHub Issues no tiene un flujo forzado: la disciplina es completamente manual. En un equipo que carece de esa disciplina, los bugs pasan de Open a Closed sin ningún paso de verificación.

El hilo común: en cualquier herramienta que uses, entiende el flujo real que usa tu equipo, no lo que la herramienta soporta por defecto. Los estados del ciclo de vida existen independientemente de las etiquetas que use tu tracker.

Métricas: los números que te dicen si el proceso funciona

Rastrear estados de bugs individualmente es útil. Rastrear patrones en todos los bugs te dice si tu proceso de calidad es saludable.

Tasa de escape de defectos mide el porcentaje de bugs encontrados en producción versus bugs encontrados antes del release. Si tu equipo encuentra el 30% de los bugs después del release, el proceso de testing no está detectando suficiente antes de que el software se publique. La fórmula: (bugs encontrados post-release) / (total de bugs encontrados) × 100. Una tasa saludable para la mayoría de los equipos está por debajo del 15%. Si la tuya es mayor, mira en qué punto del ciclo de desarrollo se introducen los bugs y dónde termina la cobertura de testing. Tiempo medio de resolución (MTTR) mide el tiempo promedio desde que se crea un bug hasta que se cierra. Un MTTR que sube señala una de tres cosas: el equipo no tiene suficiente personal para el volumen de bugs, los bugs se están creando con menor calidad (tardando más en triagear y reproducir), o componentes específicos están generando una densidad de defectos desproporcionada. Rastrear el MTTR por componente ayuda a encontrar los puntos críticos. Reporte de envejecimiento de bugs abiertos es exactamente lo que suena: una vista de todos los bugs abiertos ordenados por cuánto tiempo llevan abiertos, agrupados por estado. La versión útil de este reporte segmenta por estado. Una acumulación en "New" significa que el triage está atrasado. Una acumulación en "Assigned" significa que los desarrolladores no están tomando los bugs. Una acumulación en "Fixed" significa que QA no está verificando con suficiente rapidez. Cada estado cuenta una historia diferente sobre dónde está el cuello de botella.

Estas tres métricas juntas dan un panorama razonablemente completo de la salud del ciclo de vida del bug. Ejecútalas mensualmente, no solo al final de un ciclo de release.

Cómo aplicar esto el lunes a la mañana

Entra a tu tracker y busca todos los tickets asignados a ti o creados por ti que no estén en Closed o Won't Fix. Para cada uno: ¿está en el estado correcto? ¿La prioridad sigue siendo precisa dado lo que sabes del sprint actual? ¿Hay tickets que llevan más de dos sprints en el mismo estado sin ningún comentario?

Para cada ticket que lleva mucho tiempo, agrega un comentario de una línea hoy: o una verificación de estado si la necesitas ("Sigue relevante: la función de exportación sigue en alcance, planteando para la próxima revisión de sprint"), o una solicitud explícita de Defer si ya no es relevante ("El contexto cambió desde que se creó: esta pantalla fue eliminada en v2.9. Recomendando cerrar.").

Esta revisión de tus bugs abiertos hace tres cosas: limpia tu backlog mental, le da al equipo información precisa sobre lo que realmente está abierto, y demuestra que estás gestionando activamente la calidad, no solo creando tickets y siguiendo adelante.

El ciclo de vida del bug no es burocracia. Es el mecanismo por el cual un hallazgo se convierte en una corrección. Cada transición de estado es una entrega, y cada entrega necesita que alguien la esté mirando. Ese es el trabajo.

→ See also: La Anatomía de un Bug Report que los Desarrolladores Realmente Arreglan | Severity vs Priority: La Habilidad de Triage que Hace Crecer a los Junior QA | Cómo Escribir un Caso de Prueba: Formato, Ejemplos y Errores Comunes