Los ingenieros de QA de SpaceWeb encargaron a la IA escribir autotests: un script funcional en 50 minutos

Todo QA conoce esta aritmética: hay más funcionalidades que manos, los lanzamientos arden y la mitad del día se va en casos de prueba repetitivos y "esqueletos" de autotests. La ingeniera de QA de SpaceWeb Evgenia Myasnikova, junto con el jefe de I+D Vitali Kireev, decidió comprobar qué parte de esa rutina se puede delegar honestamente en un LLM y dónde simplemente genera paja que luego acabas reescribiendo a mano.

Tres tareas para la IA y una elección importante

El equipo no intentó automatizarlo todo a la vez. Eligió tres áreas: documentación y datos de prueba (comprobaciones positivas, negativas y de valores límite, planes de prueba, checklists), scripts de automatización y ampliación de las comprobaciones de seguridad y de API. El principio es sencillo: la IA hace el borrador y el tester lo lee, lo completa y lo depura.

La principal decisión práctica afecta a los datos. Por la información sensible, el agente se conectó a un modelo local, Qwen3.8-27B. Para la documentación y el código se usó un asistente interno, y todo se ejecutó sobre la pila habitual: Postman, Python, Pytest y Selenium. Si trabajas con código cerrado y esquemas internos de API, para este trabajo no es imprescindible una nube externa.

En los formularios funciona así. Se cargan en el modelo las precondiciones, los requisitos de obligatoriedad de los campos y la validación, y se obtiene una tabla de comprobaciones positivas y después negativas. Para la integración con GitHub/GitLab, la IA destacó además los escenarios más críticos. Para la API, al agente se le dio un ejemplo de JSON válido para crear un VPS y se le pidió preparar datos: solicitudes mínimas y de referencia, valores límite, dominios cirílicos, caracteres especiales y casos no válidos, como crear un servidor en una región inexistente.

Aun así, hay que leer el resultado con atención. En uno de los ejemplos el nombre de host figura como "exactamente 63 caracteres", pero la cadena es notablemente más larga, y en una dirección IPv6 se coló un espacio. Para una prueba de valores límite puede ser intencionado, pero es más seguro verificar estas cosas a mano.

Un autotest en menos de una hora

El caso más ilustrativo es la automatización de la creación de un buzón de correo en el panel de hosting. El prompt está redactado paso a paso y contiene todo lo que sabe la persona frente a la pantalla: Pytest, Selenium, Chrome, la autorización desde conftest.py, selectores exactos, reglas para la contraseña (de 8 a 20 caracteres, letras, dígitos, caracteres especiales) y la redirección esperada a la página review. El modelo generó un test_mail_add.py listo, con comentarios, esperas explícitas mediante WebDriverWait y comprobaciones del resultado.

Después se complicó la tarea y se pidió parametrizar el test para distintos nombres de buzón. Salieron dos tests: test_create_valid_mail_box y test_reject_invalid_mail_box. Los conjuntos positivos comprueban longitudes de 1 y 64 caracteres, caracteres especiales y dígitos. Los negativos comprueban mayúsculas, espacios, la barra y una longitud de 65. Si un caso falla, se ve de inmediato qué escenario se ha roto.

En cuanto al tiempo: unos 30 minutos se fueron en el prompt y la búsqueda de selectores, y otros 20 en la depuración. No es "pulsar un botón y listo", pero para un esqueleto rutinario el resultado es bueno.

Las limitaciones también se ven en el código. En el test negativo, la IA no sabía cómo reacciona el sistema ante un error, así que propuso dos variantes: o el frontend muestra un error, o el formulario se envía y no hay redirección. La segunda variante quedó comentada y el comportamiento tuvo que aclararlo una persona. Además, en el test positivo, a los nombres que no terminan en dígito se les añade un sufijo aleatorio. Por eso el caso de "exactamente 64 caracteres" se convierte en un nombre más largo que el límite, es decir, la comprobación de valor límite en la práctica se rompe. Cosas así solo las detecta la revisión.

IDOR: hay un punto de partida, pero aún no hay resultados

El tercer caso trata de la seguridad de la API. Había que comprobar IDOR en el método edit (JSON-RPC): el campo service_ref sirve como identificador directo del objeto, y el servidor debe verificar si el usuario tiene derechos sobre él. El agente propuso enseguida una comprobación básica: enviar la misma solicitud con el service_ref de otro usuario. Después el equipo le pidió escribir con Requests un script que recorra los valores de un archivo TXT con identificadores de servicios ajenos.

En la parte accesible de la publicación el texto se interrumpe en este paso, así que aquí no hay resultados finales sobre IDOR. No conviene sacar conclusiones sobre si la IA encontró vulnerabilidades reales.

Qué llevarse a la práctica

• Dale al modelo contexto estructurado: precondiciones, el esquema del método, un ejemplo de JSON válido, selectores concretos. La calidad del resultado depende del prompt.
• Trata la salida como un borrador. Revisa los límites de los valores, el comportamiento esperado ante errores y los localizadores.
• Para datos sensibles, despliega un modelo local: SpaceWeb demostró que con él es posible un escenario funcional.
• Empieza por la rutina: casos de prueba, datos de prueba, esqueletos de tests de UI. Ahí el ahorro se ve con más claridad.

La conclusión honesta es esta: la IA no sustituye al ingeniero de QA, pero le quita la parte más mecánica. El control de calidad sigue en manos de quien sabe cómo debe comportarse el sistema.