El ciclo de vida de un bug: de 'nuevo' a 'cerrado' sin perderse en el camino

Un defecto no se arregla: se gestiona. Esa es la respuesta corta a por qué existe un ciclo de vida del bug. Cuando un tester encuentra una falla, no basta con avisar y esperar que alguien la corrija. El defecto entra en un flujo de estados con reglas claras: quién lo tiene, qué se espera de esa persona, y cuándo puede considerarse realmente cerrado. Saltarse ese flujo es la forma más común de que un bug marcado como "arreglado" reaparezca dos semanas después en producción.

El ciclo de vida de un defecto es, en el fondo, un contrato entre tres roles: quien reporta, quien corrige y quien verifica. Cada estado del defecto dice de quién es la pelota en este momento. Si nadie sabe de quién es la pelota, el defecto se queda flotando, y los defectos que flotan son los que llegan al cliente.

01 · el mapaQué es el ciclo de vida y por qué existe

El ISTQB define un defecto como una imperfección en un componente o sistema que puede hacer que este no cumpla su función requerida. La gestión de defectos, según su glosario, es el proceso de reconocer, registrar, clasificar, investigar, resolver y disponer de los defectos [1]. Esa lista de verbos ya es, casi palabra por palabra, el ciclo de vida: cada verbo corresponde a un estado por el que pasa el defecto.

La razón de fondo es sencilla. Un defecto suelto no tiene dueño ni memoria. Un defecto dentro de un flujo de estados siempre tiene un responsable actual y un historial de por dónde pasó. Eso convierte una queja informal en una unidad de trabajo rastreable, que se puede medir, priorizar y auditar.

Cada estado del defecto responde una sola pregunta: ahora mismo, ¿de quién es la pelota?

Conviene no confundir dos cosas que suenan parecidas. La severidad mide cuánto daño hace el defecto al sistema. La prioridad mide con qué urgencia debe corregirse desde el punto de vista del negocio. Un error ortográfico en el logo puede ser de severidad baja pero prioridad alta si sale en la portada mañana. El ciclo de vida es independiente de ambas: un defecto trivial y uno crítico recorren los mismos estados, solo que a distinta velocidad.

02 · los estadosDe 'nuevo' a 'cerrado', paso por paso

Los nombres exactos cambian entre herramientas como Jira, Bugzilla o Azure DevOps, pero el esqueleto es casi universal. Estos son los estados que importa entender.

Nuevo. El defecto acaba de reportarse. Aquí se juega media partida: un buen reporte trae pasos para reproducir, resultado esperado, resultado obtenido, entorno y evidencia. Un reporte pobre condena al defecto a rebotar en "necesito más información" durante días.

Asignado. Alguien, casi siempre un líder técnico o de QA, revisa que el defecto sea válido y se lo asigna a quien debe corregirlo. Aquí la pelota pasa de QA a desarrollo.

En progreso. La persona desarrolladora está trabajando en la corrección. El defecto tiene dueño y está en movimiento.

Resuelto. El código ya se corrigió, pero ojo: resuelto no es cerrado. Es una afirmación de una parte que la otra todavía no comprobó. La pelota vuelve a QA.

Verificado. QA vuelve a ejecutar el escenario y confirma que el defecto ya no ocurre. Esta es la línea que separa el testing serio del "confía en mí, ya lo arreglé".

Cerrado. El defecto se da por terminado. Solo se llega aquí después de verificar, no antes.

03 · el punto críticoPor qué la verificación no es opcional

El momento más frágil del ciclo es el salto de "resuelto" a "cerrado". Es tentador cerrar en cuanto desarrollo dice que ya está, sobre todo cuando la fecha de entrega aprieta. Pero cerrar sin verificar rompe el contrato entero. Un defecto resuelto es una hipótesis; un defecto verificado es un hecho.

La distinción conecta con algo más grande: la diferencia entre verificar y validar. Verificar responde "¿se corrigió lo que dijimos que corregiríamos?". Validar responde "¿resuelve esto el problema real del usuario?". El cierre de un defecto es, en miniatura, un acto de verificación, y por eso no puede saltárselo la persona que hizo el arreglo.

Hay una razón adicional para tomarse en serio esta etapa: la corrección de un defecto puede introducir otro. Es lo que se llama un defecto de regresión. Por eso una verificación madura no solo comprueba que el bug original desapareció, sino que revisa que nada cercano se haya roto en el intento. Ahí es donde la gestión de defectos se enlaza con la estrategia de pruebas de regresión.

04 · el tableroQué mide un ciclo sano

Cuando el ciclo de vida funciona, el tablero de defectos empieza a contar cosas útiles. La tasa de reapertura revela si los arreglos aguantan o si se cierran en falso. El tiempo en cada estado muestra dónde se atascan los defectos: si viven días en "nuevo", el problema es el triaje; si viven días en "resuelto", el cuello de botella es la verificación. La densidad de defectos por módulo señala qué parte del producto concentra el riesgo.

Nada de esto es posible sin estados disciplinados. Un defecto que salta directo de "nuevo" a "cerrado" no deja rastro que medir. El ciclo de vida no es burocracia: es la condición para que el equipo aprenda de sus propios errores en lugar de repetirlos.

La próxima vez que alguien diga "ya arreglé el bug", vale la pena preguntar en qué estado está. Si la respuesta es "resuelto", el trabajo todavía no terminó. Solo cuando alguien distinto a quien lo corrigió vuelve a mirar, ejecuta el escenario y confirma que la falla se fue, el defecto puede pasar de nuevo a cerrado sin perderse en el camino.