Cuando encuentras un bug, lo primero que haces es intentar entender de dónde viene. Pero ese momento de descubrimiento es solo el principio — un bug pasa por muchas más fases hasta que se cierra definitivamente. Y conocer ese ciclo completo es fundamental para trabajar bien en un equipo de desarrollo.
En este artículo te explico cada fase del ciclo de vida de un bug con ejemplos reales.
Qué es el ciclo de vida de un bug
El ciclo de vida de un bug es el proceso que sigue un defecto desde que se detecta hasta que se cierra. Define los estados por los que pasa, quién es responsable en cada momento y qué decisiones se toman a lo largo del camino.
Tener un ciclo de vida bien definido evita que los bugs se pierdan, se olviden o se cierren sin haber sido realmente resueltos.
Las fases del ciclo de vida de un bug
1. Nuevo (New)
El bug acaba de ser detectado y reportado. El QA Engineer lo documenta en Jira con toda la información necesaria: título descriptivo, pasos para reproducirlo, resultado obtenido, resultado esperado, entorno y evidencias.
En este momento el bug existe oficialmente en el sistema pero todavía nadie lo ha analizado.
Si quieres saber cómo reportar un bug correctamente puedes leer cómo reportar un bug en Jira paso a paso.
2. Asignado (Assigned)
El bug ha sido revisado por el equipo y se asigna a un desarrollador para que lo analice y lo corrija. En equipos ágiles que trabajan con Scrum, esta asignación suele ocurrir durante el daily standup o en una sesión de refinement.
3. En análisis (In Analysis)
El desarrollador analiza el bug para entender la causa raíz — exactamente lo que haces tú cuando encuentras un defecto. ¿De dónde viene? ¿Qué parte del código lo está causando? ¿Afecta a otras funcionalidades?
Esta fase es crítica. Una corrección sin un análisis correcto puede arreglar el síntoma pero no la causa, y el bug reaparece más tarde.
4. En progreso (In Progress)
El desarrollador está trabajando activamente en la corrección. El bug está siendo resuelto.
5. Pendiente de verificación (Ready for QA)
El desarrollador ha terminado la corrección y la ha entregado al entorno de pruebas. Ahora le toca al QA verificar que el bug está realmente resuelto.
Esta fase es muy importante. No basta con que el desarrollador diga que está arreglado — el QA tiene que verificarlo de forma independiente siguiendo exactamente los mismos pasos que usó para reportarlo originalmente.
6. Verificado (Verified)
El QA ha comprobado que el bug está corregido correctamente. La funcionalidad ahora funciona como se esperaba.
Pero la verificación no termina aquí. El QA también hace pruebas alrededor de la corrección para asegurarse de que el arreglo no ha introducido nuevos bugs — lo que se conoce como pruebas de regresión.
7. Cerrado (Closed)
El bug ha sido verificado y corregido. Se cierra en Jira con toda la información documentada.
8. Reabierto (Reopened)
El QA ha verificado que la corrección no funciona correctamente — el bug sigue apareciendo o aparece de forma diferente. En este caso el ticket se reabre y vuelve al desarrollador con los detalles de por qué la corrección no es válida.
El reopen es uno de los momentos más delicados en la relación QA-desarrollador. Un reopen bien documentado con evidencias claras facilita la comunicación y evita fricciones innecesarias.
Estados adicionales que puedes encontrar
Además de los estados principales, existen otros estados que aparecen en función de las decisiones del equipo:
Rechazado (Rejected): el equipo analiza el bug y concluye que no es un bug sino el comportamiento esperado según los requisitos. Se cierra sin corrección.
Duplicado (Duplicate): ya existe otro ticket abierto para el mismo bug. Se cierra y se referencia al ticket original.
No reproducible (Cannot Reproduce): el desarrollador no puede reproducir el bug con la información proporcionada. Se devuelve al QA para que añada más detalles o lo reproduzca en el entorno del desarrollador.
Diferido (Deferred): el bug existe y es válido pero el equipo decide no corregirlo ahora por falta de tiempo, baja prioridad o porque se corregirá en una versión futura.
No se corregirá (Won’t Fix): el bug existe pero el equipo decide conscientemente no corregirlo — normalmente porque el coste de la corrección supera el impacto del bug.
El ciclo de vida en un diagrama
El flujo típico de un bug es este:
Nuevo → Asignado → En análisis → En progreso → Pendiente de QA → Verificado → Cerrado
Con posibles desviaciones:
Pendiente de QA → Reabierto → En progreso (si la corrección no funciona)
Nuevo → Rechazado (si no es un bug)
Nuevo → Duplicado (si ya existe)
Nuevo → No reproducible (si falta información)
El papel del QA en cada fase
El QA Engineer no solo interviene al principio y al final. Tiene un rol en varias fases del ciclo.
En la fase Nuevo — detecta, reproduce y documenta el bug con toda la información necesaria.
En la fase Análisis — responde preguntas del desarrollador, proporciona información adicional y ayuda a reproducir el bug en diferentes entornos si es necesario.
En la fase Pendiente de QA — verifica la corrección siguiendo los pasos originales y hace pruebas de regresión alrededor del área corregida.
En la fase Verificado — cierra el ticket o lo reabre con evidencias claras si la corrección no es correcta.
Un QA que conoce bien el ciclo de vida del bug trabaja de forma más eficiente y genera menos fricciones con el equipo de desarrollo.
Herramientas para gestionar el ciclo de vida
En equipos profesionales el ciclo de vida del bug se gestiona con herramientas específicas. Las más usadas en España son Jira, que es el estándar en equipos ágiles, TestRail para gestión de casos de prueba y Azure DevOps en entornos Microsoft.
En mis proyectos uso Jira para gestionar el ciclo de vida completo de los bugs. Puedes ver un ejemplo real en mi GitHub.
Si quieres saber más sobre los tipos de bugs y cómo clasificarlos puedes leer tipos de bugs en testing: clasificación completa. Y si necesitas ayuda para implementar un proceso de QA en tu equipo puedes ver mis servicios en fatimaqa.com.