Multitask y Playwright MCP: automatiza tu QA en Cursor

Cuando la autorización de un sistema de login falla, la solución no siempre es escribir más código a mano. En esta práctica con Cursor usamos el MCP de Playwright para validar la autenticación con tests end-to-end y luego aceleramos todo con multitask, la función que corre specs en paralelo. Es material ideal para quien desarrolla con agentes de IA y quiere reducir tiempo de QA.

Por qué usar el MCP de Playwright para probar el login

Todo arranca con un problema concreto: al probar el sistema de login, la autorización no funcionaba. En lugar de depurar manualmente, le pedimos al agente que instalara el MCP de Playwright y validara con tests end-to-end que el spec recién construido sirviera [00:35].

Playwright es una herramienta que permite crear end-to-end testing con un loop de feedback para el agente. Esto significa que el agente intenta llevar un test del punto A al punto B, y si falla en medio del camino, recibe ese feedback y corrige sobre la marcha [00:22].

¿Qué es un test end-to-end? Es una prueba que valida un flujo completo de la aplicación, del inicio al final, como iniciar sesión y llegar al dashboard. Simula lo que haría un usuario real.

El agente instaló el MCP a nivel de proyecto dentro del archivo de configuración de Cursor, creó seis tests, aplicó los fixes que explicaban por qué no funcionaba y generó dos comandos: uno para correr los tests end-to-end en modo headless y otro con UI interactiva [01:05].

Cómo se valida la autenticación en el browser

Después del arreglo automático, viene la comprobación manual. Levantamos las aplicaciones y fuimos al navegador para probar el flujo real de acceso:

• Ingresar a localhost:3000/login.
• Usuario: admin.
• Contraseña: demo123.

Al entrar, el dashboard cargó sin problemas. Eso confirma que el sistema de autenticación quedó funcionando y que podíamos avanzar al siguiente paso [01:35].

Qué es multitask en Cursor y cómo divide el trabajo

Cursor incluye una función llamada multitask que permite correr tareas en paralelo. Le indicas cuáles specs quieres ejecutar y crea un subagente para cada uno, siempre que sea posible hacerlo al mismo tiempo [01:55].

Y aquí viene lo interesante: antes de ejecutar nada, multitask hace un análisis de las tareas y verifica cuáles puede correr en paralelo y cuáles debe correr en serie, es decir, una detrás de la otra [02:10].

¿Multitask ejecuta todo al mismo tiempo? No. Primero analiza dependencias y agrupa las tareas en olas. Solo corre en paralelo las que no dependen entre sí; el resto las ejecuta en secuencia.

Un detalle práctico del flujo: al notar que la conversación con el agente ya ocupaba el 62% del contexto, decidimos cerrar ese agente y abrir uno nuevo para empezar desde cero [02:30]. Manejar el contexto ocupado evita que el agente pierda precisión.

Cómo se organizan los specs en olas de ejecución

El trabajo se hizo sobre la rama main del proyecto, corriendo los specs 6, 7, 8 y 11 porque son los que podían ejecutarse en paralelo. El prompt le pedía usar multitask, evaluar cuáles corren juntos y actualizar contexto y dependencias [02:50].

Cada spec tiene un apartado de contexto y dependencias que indica cuáles specs deben estar construidos antes de continuar con el siguiente. Validar esas dependencias es lo que permite al agente identificar el orden correcto [03:10].

El análisis dividió el trabajo en tres olas:

1. Ola uno: corre el spec 6.
2. Ola dos: corre el 7 y el 11 en paralelo.
3. Ola tres: al terminar el 7, corre el 8, aunque el 11 no haya terminado.

Con ese mapa claro, el agente lanzó la ejecución. Implementó el spec 6, luego el 7 y el 11 con un agente para cada uno, y al terminar el 11 arrancó la ola tres con el spec 8 [03:45].

Cómo encontrar y arreglar bugs antes del QA manual

Con los specs implementados, le pedimos al agente que ejecutara tests end-to-end usando el MCP de Playwright. La idea es hacer este proceso automatizado antes de las pruebas manuales, para garantizar que todo funciona a nivel de software y ahorrar tiempo en el QA de la aplicación [04:30].

Las pruebas end-to-end encontraron cuatro bugs, y el agente los fue resolviendo a medida que los detectaba [04:50]. Después generó los scripts para correr los tests y levantó el proyecto en la terminal para la prueba manual.

En el navegador repetimos el acceso con admin y demo123, y el dashboard mostró:

• La sección para crear flags.
• El historial de auditoría de los cambios.
• Un botón de cerrar sesión.

Al entrar a los flags estaban vacíos, así que creamos uno nuevo y apareció el formulario correspondiente, con navegación de regreso, al historial y al dashboard [05:30]. Con eso, gran parte del dashboard quedó terminado.

El reto queda planteado: evalúa cuáles de tus specs puedes ejecutar en serie y cuáles en paralelo, pídele a multitask que lo haga por ti y revisa el resultado. ¿Cómo te fue con la división en olas? Cuéntalo en los comentarios.