Un QA de Cloud.ru reduce una tarea de autotests de medio día a 1–1,5 horas con OpenSpec

El agente escribió los tests, el código es limpio y pytest muestra verde. ¿Se puede cerrar la tarea? No necesariamente. Un ingeniero de QA de Cloud.ru contó cómo, tras varios casos así, montó un proceso con cuatro agentes y especificaciones. Ahora dedica más tiempo a los requisitos y los riesgos que al código en sí.

Un test en verde que no demuestra nada

El proyecto tiene una funcionalidad para publicar la estructura de la documentación en Git. Si en una nueva publicación desaparece una sección de la estructura, el archivo correspondiente debe eliminarse del repositorio. El agente escribió un test, test_update_structure_removes_orphan_doc_file. Publica una estructura con las secciones overview y setup, luego la publica de nuevo sin setup, clona el repositorio y comprueba que el archivo setup ya no está.

Parece razonable: se comprueba el estado real de Git, no solo la respuesta de la API. Pero antes del borrado, el agente nunca verificó que el archivo hubiera estado allí. Confirmaba la presencia del documento mediante get_repowiki_docs(), y ese método puede devolver metadatos sin mirar el repositorio en sí. Si en la primera publicación el archivo no llegó a aparecer, el test pasaría igualmente: tras la segunda publicación tampoco está. El test comprueba el estado final, pero no la transición en sí, de «el archivo estaba» a «el archivo no está».

La autoverificación del agente desarrollador no lo detectó: analizó la lógica del test, pero no hizo experimentos. El problema lo encontró otro agente, el revisor. Después, se añadió al test un paso con repowiki_repo_clone() as clone_before, que comprueba la existencia del archivo antes de la nueva publicación. La misma clase de error aparece también en casos sencillos: el agente comprueba el HTTP 400, pero no mira la estructura del cuerpo del error.

Cómo funciona el proceso

El autor abre Claude Code y le da al agente principal, el orquestador, el número de una tarea de Jira. Las reglas están descritas en el archivo CLAUDE.md del repositorio: qué agentes hay, de qué se encarga cada uno, cómo pasar de una etapa a otra y cuándo se necesita la confirmación de una persona. Ahora hay cuatro agentes:

• test-planner investiga la tarea y los tests existentes y crea un OpenSpec change. Contiene proposal.md (por qué), design.md (enfoque y restricciones) y tasks.md (pasos concretos). Después, el plan pasa por openspec validate --strict.
• test-qa-writer implementa los tests según tasks.md y marca los puntos completados.
• test-reviewer contrasta la implementación con la especificación y los acuerdos de arquitectura. No ejecuta los tests por sí mismo; trabaja solo con el código y los artefactos.
• docs-writer actualiza la documentación.

La persona interviene en dos puntos. El primero, tras el plan: comprueba si el agente ha entendido bien la tarea, si se han omitido casos y si la solución encaja en la arquitectura del proyecto de tests. Las dudas sobre la lógica de negocio las aclara con los desarrolladores. El segundo, tras la revisión: el orquestador trae su conclusión y la decisión de rehacer o archivar la toma la persona.

En el change quedan qa-report.md y review.md. Así, la tarea conserva su historial: qué se planificó, qué se hizo y qué observaciones surgieron.

Comprobar que no son tonterías

Además de la revisión, el autor hace ejecuciones reales y comprueba la sensibilidad de los tests. Por ejemplo, cambia a propósito el valor esperado en un assert y observa si el test falla. No es un mutation testing completo del servicio, sino una forma barata de asegurarse de que las aserciones comprueban algo.

Hay también una salvedad honesta. El desarrollador y el revisor pueden trabajar con el mismo modelo. La separación de roles no hace la comprobación totalmente independiente, pero cambia la posición y los criterios de evaluación. Justo este esquema detectó el caso del archivo setup.

Qué llevarse de todo esto

El autor valora la ganancia así: en lugar de media jornada laboral, la tarea lleva en torno a una hora u hora y media, y parte del trabajo los agentes lo hacen mientras él está ocupado con otra cosa. La estimación es aproximada y es la experiencia de una persona en un proyecto. Para tareas pequeñas, él mismo admite simplificar el proceso.

Conclusiones prácticas para los equipos que delegan los tests en agentes:

• Incluya en los criterios de aceptación la comprobación del estado inicial, no solo del final. Para cualquier test del tipo «tras la acción X algo cambió» hace falta un paso que confirme que antes de X no era así.
• No tome la autoverificación del ejecutor por una revisión. Una pasada aparte, con otro rol y otro prompt, detecta lo que el autor del código no ve.
• Guarde las especificaciones y las conclusiones de la revisión en el repositorio, junto al código.
• Mantenga a una persona en dos bifurcaciones: la aprobación del plan y la aceptación del resultado.

El artículo original analiza a continuación un caso con CRUD para etiquetas de Git: había tres tests de GET /tags que comprobaban solo el campo name, y no había cobertura para POST ni DELETE. Pero la conclusión principal ya se ve en la descripción del proceso. Los agentes asumen la implementación, mientras que de los requisitos y de la calidad final sigue respondiendo una persona.