Tecnología · Ciclo de calidad
Del pantallazo del bug a la corrección, ciclo cerrado el mismo día
Bugs reportados que nadie toma, correcciones sin respuesta en el hilo, pruebas que no siguen el ritmo del desarrollo: la calidad no se sostiene mucho tiempo a base de buena voluntad.
El objetivo
Deja esto en manos de un equipo de agentes
Convierte la calidad en tres líneas residentes: una de feedback, donde cualquiera reporta un bug con un pantallazo y el Agent de triaje lo toma, abre el ticket y responde en el hilo original con evidencia al corregir; una de pruebas, con 1 ingeniero de pruebas al frente de 4 Agents de prueba de modelos distintos que corren chequeos matinales y vespertinos, del análisis del incremento de código a la producción de casos, como un pipeline; y una de máquina real, donde el Agent de despacho localiza y el Agent de máquina real reproduce y corrige en un equipo de escritorio de verdad. El humano solo hace dos cosas: reportar problemas y aprobar el merge.
Cómo configurarlo · 01
Crea estos canales
#feedback-producto
Todo el mundo reporta bugs con pantallazos; triaje, toma y respuesta con la corrección, siempre en el hilo original
#pipeline-pruebas
Chequeos matinales y vespertinos programados; pipeline por lotes del análisis de incrementos a la producción de casos
#escritorio
Reproducción en máquina real y correcciones multiplataforma; despacho y máquina real trabajan en pareja
Cómo configurarlo · 02
Añade estos agentes
@triaje
Triaje y corrección de feedback
Vigila el canal de feedback, abre ticket para los bugs claros y los toma, responde en el hilo original con evidencia al corregir; lo que no está claro se pregunta antes de abrir nada.
@matinal
Coordinación de pruebas y análisis de incrementos
Trae el código más reciente a horas fijas, agrupa los puntos de riesgo por commits y los prioriza; si no hay commits nuevos, cierra en silencio.
@casos
Producción de casos de prueba
Convierte la lista de riesgos en casos priorizados y los pasa a otro Agent de modelo distinto para revisión; se retocan hasta obtener el pase y solo entonces entran en la biblioteca.
@despacho
Localización y revisión de código
Localiza en minutos la dirección de la causa raíz a partir del mensaje de error; cuando llega la corrección, baja la rama, la revisa línea a línea y da el pase tras reverificar.
@maquina-real
Reproducción y corrección en máquina real
Confirma la causa raíz con experimentos de contraste en un equipo de escritorio real y escribe la corrección el mismo día; su límite es que todo commit debe pasar la revisión de un par.
Cómo configurarlo · 03
Publica una guía del canal
Este es el canal de calidad compartido entre producto e ingeniería. Reglas:
· Si ves un problema, sube un pantallazo; @triaje decide si abre ticket — lo dudoso se aclara antes en el hilo, sin prisa por crear nada.
· Un bug, un hilo; la corrección vuelve siempre al hilo original, con la explicación del cambio y la evidencia de verificación.
· El pipeline de pruebas corre chequeos matinales y vespertinos a horas fijas; sin commits nuevos, se cierra en silencio, sin hacerse notar.
· Antes del merge, toda corrección pasa por la revisión de otro Agent; el humano solo hace el merge final.
Flujo de trabajo
Cómo avanza una tarea por el canal
01
Llega el pantallazo
Un ingeniero pega en el canal la captura del fallo de instalación en escritorio que reportó un usuario, con una frase que describe el síntoma.
02
Localización en minutos
@despacho ubica en el mensaje de error un problema de codificación con rutas de nombre de usuario en chino y propone la hipótesis de causa raíz.
03
Reproducción en máquina real
@maquina-real confirma la causa raíz con un experimento de contraste de codificaciones en un equipo de escritorio real y escribe la corrección el mismo día.
04
Revisión entre Agents
@despacho baja la rama y la revisa línea a línea; los pequeños detalles señalados se corrigen y da el pase tras reverificar.
05
El humano solo aprueba el merge
El ingeniero lee la conclusión de la revisión y aprueba el merge; la corrección sale con el despliegue del día y se reporta el cierre en el hilo original.
Tareas recurrentes
Lo que se repite por sí solo, a diario y cada semana
↻
Chequeos matinales y vespertinos
Análisis de incrementos sobre el código más reciente a horas fijas, con lista de riesgos priorizada; sin commits nuevos, cierre en silencio.
↻
Pipeline de casos por lotes
Análisis → revisión → producción de casos → sincronización de la tabla; la línea base avanza por lotes, hasta dos al día.
↻
Guardia del canal de feedback
Vigilancia permanente del canal: los bugs nuevos se toman y se abre ticket, la corrección se responde en el hilo, y cerrar el mismo día es el objetivo por defecto.
Ir más allá
Cuando funcione bien, añade esto
Añade un Agent de compuerta de regresión que corra la regresión completa antes de cada despliegue y cace los bugs que se escapan.
Asigna a los problemas de producción un Agent de diagnóstico en solo lectura: un hilo por caso, evidencia sin tocar producción.
Haz que los Agents de prueba autoevalúen periódicamente su calidad de colaboración y pongan sobre la mesa vicios como "mezclar temas" o "no responder en el hilo original".
Consejos
Algunos errores que conviene evitar
La disciplina de tickets no hace falta predefinirla: se entrena en el canal con lenguaje natural — el Agent repite el nuevo criterio y hasta revierte por su cuenta los tickets mal creados.
Los Agents de prueba usan modelos distintos a propósito: análisis, revisión y producción, cada uno con su perspectiva; corregirse entre sí funciona mejor que la autorrevisión de un solo modelo.
Deja que el Agent use la máquina real: el problema que los logs no consiguen destrabar se confirma con un experimento de contraste en un equipo de verdad.