Qué pasa con tus tests cuando cierra tu proveedor de QA

En abril de 2026, la empresa de testing con IA Octomind anunció que cerraba. El servicio terminó en mayo. A sus clientes les pidieron que exportaran sus tests, y pudieron hacerlo: la plataforma generaba código Playwright estándar, así que las suites podían correr en cualquier lado.

Esa es la versión buena de la historia. No todos los proveedores cierran, y no todos guardan tus tests en un formato que puedas llevarte. Si el tuyo no lo hace, un cierre, un cambio de precio o una adquisición te dejaría reconstruyendo la suite con los tiempos de otro.

Tests alquilados vs tests propios

La mayoría de las plataformas de testing funcionan como un alquiler. Tus tests viven en su editor, corren en su infraestructura y se cobran por ejecución, por usuario o por test. El primer día es cómodo: nada que configurar y un dashboard listo.

El costo aparece después:

• Irse es reescribir. Los tests grabados en un formato propietario no corren en ningún otro lado.
• El precio por uso castiga los buenos hábitos. Correr la suite en cada pull request es justo lo que quieres, y justo lo que un precio por ejecución desalienta.
• Tus developers no pueden arreglarlos. Si el test vive fuera del repo, actualizarlo es trabajo de otro, y se queda atrás del código.

Los tests propios son código común en tu repositorio. Corren con los minutos de tu CI, se revisan en los mismos pull requests que las features que prueban y siguen funcionando les pagues o no a alguien.

Tres preguntas para tu proveedor (o para ti)

1. Si cancelamos hoy, ¿con qué nos quedamos? “Un export” no es respuesta. Pregunta en qué formato y si corre sin su plataforma.
2. ¿Dónde corren los tests? ¿En tu CI o en sus servidores? Si es en los suyos, ¿qué pasa con tus deploys cuando se caen?
3. ¿Quién puede cambiar un test? Si un developer le cambia el nombre a un botón, ¿puede arreglar el test en el mismo pull request?

Si las respuestas son “nada”, “sus servidores” y “solo desde su editor”, estás alquilando.

Por qué entregamos la suite

Por eso cada Sanity Suite que construimos está escrita en un framework estándar, normalmente Playwright, vive en tu repo y corre en tu CI. Maintenance es opcional. Si lo cancelas, no se rompe nada: la suite sigue corriendo y tu equipo puede ampliarla.

No se trata de hacer fácil dejarnos como un gesto. Se trata de que los tests que nadie en tu equipo puede leer ni cambiar en realidad no te están protegiendo.