Plataforma
QA automatizada para una entrega de software con IA seria
Cada cambio escrito por IA se prueba como lo experimentaría un usuario: en un navegador real, antes de publicarse y después de llegar a producción.
Ciao QA es la capa de pruebas automatizadas de la plataforma: réplicas deterministas del navegador, tests que se autorreparan, smoke gates antes de publicar y comprobaciones en producción después de publicar. A diferencia de las suites de tests que se pudren a medida que cambia la aplicación, los tests de Ciao se reparan solos cuando evoluciona la UI, así la cobertura mantiene el ritmo del desarrollo a velocidad de IA en lugar de quedarse atrás.
Publicado 2026-07-03 · Última actualización 2026-07-03
La IA escribe más rápido de lo que los humanos pueden probar
El desarrollo asistido por IA desplaza el cuello de botella. El código que antes tardaba un sprint llega en una tarde, y cada uno de esos cambios puede romper el checkout, el login o el informe que un director lee cada lunes. Recorrer la app a mano no escala a ese ritmo, y las suites de tests tradicionales se degradan en el momento en que la UI cambia bajo ellas.
Ciao QA está construida para ese ritmo. Ejecuta réplicas deterministas del navegador, tests que se autorreparan, smoke gates antes de publicar y comprobaciones en producción después de publicar, de forma automática, en cada cambio, como parte del mismo ciclo que escribió el código.
Cómo funciona QA
QA corre como parte del ciclo de entrega: nada de esto es una herramienta aparte que adoptar ni un pipeline que mantener.
1. Los flujos se capturan como réplicas
Los recorridos clave del usuario —iniciar sesión, crear un registro, pagar— se capturan como réplicas deterministas del navegador: los mismos pasos, las mismas entradas, los mismos resultados esperados, en cada ejecución.
2. Los tests corren en un navegador real
Las réplicas se ejecutan contra la aplicación real tal como la experimentaría un usuario —renderizado real, red real, autenticación real—, no contra componentes simulados.
3. Los tests se reparan en lugar de pudrirse
Cuando la UI cambia legítimamente —un botón se mueve, una etiqueta se reformula—, los tests autorreparables se actualizan solos para ajustarse a la nueva realidad, en lugar de fallar por un selector obsoleto y terminar eliminados.
4. Los smoke gates guardan la puerta
Antes de cualquier publicación, los smoke gates ejecutan las réplicas críticas. Un control que falla detiene la publicación, así la versión rota no se publica a través de él.
5. Las comprobaciones en producción cierran el ciclo
Después de publicar, se ejecutan comprobaciones contra la aplicación en vivo para confirmar que el release se comporta bien en producción, donde la configuración y los datos son reales.
6. Los fallos vuelven como trabajo
Una comprobación fallida vuelve al ciclo con contexto —qué paso falló y qué se esperaba—, donde la corrección se puede construir y volver a verificar.
Por qué importa
Determinista importa porque los tests inestables entrenan a los equipos para ignorar el rojo. Cuando una réplica falla, algo realmente cambió, lo que hace que la señal valga la pena atender y que el control valga la pena confiar en él.
Autorreparable importa porque la alternativa es una suite que muere en silencio. Una cobertura que se mantiene sola sigue el ritmo del cambio a velocidad de IA, así el cambio número cien se prueba tan a fondo como el primero. Y los controles a ambos lados de la publicación significan que «funcionó en la vista previa» y «funciona en producción» quedan ambos verificados, no supuestos.
El hábito que esto construye es el punto central. Cuando cada publicación pasa por un control y cada release se comprueba en producción, publicar deja de ser un acto de valentía. Los equipos hacen más cambios, en piezas más pequeñas, porque el coste de equivocarse es una publicación detenida y no un lunes roto, y el registro de auditoría muestra cada control que pasó cada release.
Quién la usa
QA es uno de los seis roles en la organización de software con IA de Ciao, y distintas personas se apoyan en ella de forma distinta.
- Personas sin perfil de ingeniería que publican apps reales — Quienes no se puede esperar que escriban suites de tests obtienen una de todos modos, capturada a partir de los flujos que realmente tiene su app.
- Responsables de ingeniería — Controles en lugar de promesas: una publicación que falló su smoke gate no sale, sin importar quién la pidiera.
- Agencias — Cada aplicación de cliente obtiene recorridos protegidos sin un presupuesto de QA por proyecto ni una suite mantenida a mano por cliente.
- Equipos de operaciones y soporte — Las comprobaciones en producción atrapan regresiones en la app en vivo, así los problemas salen a la luz como hallazgos y no como tickets de soporte.
Notas de seguridad y gobernanza
- ✓ Los smoke gates se ejecutan antes de cada publicación; las comprobaciones en producción, después.
- ✓ Las réplicas son deterministas: los mismos pasos, los mismos datos, el mismo resultado esperado en cada ejecución.
- ✓ La autorreparación mantiene viva la cobertura a medida que evoluciona la UI.
- ✓ Los resultados de QA alimentan el estado del proyecto en Conductor, visible en toda la flota.
- ✓ Los resultados de los tests se suman al registro de auditoría de solo adición junto a merges y despliegues.
Una suite mantenida a mano frente a Ciao QA
El contraste con una suite mantenida a mano es estructural, no cosmético.
| Suite de tests mantenida a mano | Ciao QA | |
|---|---|---|
| Autoría | Los ingenieros escriben y actualizan scripts | Los flujos se capturan como réplicas a medida que se construye la app |
| Cambios de UI | Los selectores se rompen; los tests se saltan | Los tests se autorreparan para ajustarse a la nueva UI |
| Antes del release | El CI corre si alguien lo configuró | Los smoke gates detienen una publicación que falla |
| Después del release | Monitorización, si está configurada | Las comprobaciones en producción verifican la app en vivo |
| Fallos inestables | Reejecutar y esperar lo mejor | Réplicas deterministas: rojo significa que algo cambió |
Preguntas frecuentes
¿Qué significa «determinista» aquí?
Las réplicas ejecutan los mismos pasos, con las mismas entradas y las mismas expectativas, cada vez. Un fallo significa entonces que la aplicación cambió, no que el test tembló, lo que hace razonable condicionar una publicación a ellas.
¿Tengo que escribir los tests yo mismo?
No. Los recorridos clave se capturan a medida que se construye la aplicación, y puedes añadir los flujos más importantes para tu negocio. Los ingenieros pueden inspeccionar y extender lo que se ejecuta: es parte del proyecto, no una caja negra.
¿Qué pasa cuando falla un smoke gate?
La publicación se detiene. El fallo vuelve con contexto —el paso, la expectativa, lo que pasó en su lugar—, para que la corrección se pueda hacer y volver a verificar. Cuando el control está en verde, la publicación continúa.
¿Qué son las comprobaciones en producción, y por qué ejecutarlas después de publicar?
La vista previa y la producción difieren: la configuración, los datos, las integraciones y el tráfico solo son reales en una de ellas. Las comprobaciones en producción se ejecutan contra la aplicación en vivo después de cada release para confirmar que se comporta bien donde importa, y los hallazgos fluyen hacia Doctor y SysOps para su diagnóstico y respuesta.
¿Esto reemplaza a los ingenieros de QA?
No: cambia en qué invierten su tiempo. El trabajo mecánico de mantener vivos los tests de navegador está automatizado; las personas deciden qué recorridos son críticos, revisan lo que atrapan los controles y suben el nivel con el tiempo.