Código de Automatización con IA: Por qué la Simplicidad mata a la Complejidad en QA

En la era de las herramientas de Inteligencia Artificial como Cursor IDE, GitHub Copilot y ChatGPT, generar código para frameworks de automatización de pruebas es más rápido que nunca. Sin embargo, esto ha traído un problema silencioso pero crítico a los equipos de QA: la sobre-ingeniería.

Cuando delegamos la creación de scripts de Selenium o Appium a una IA sin darle un contexto claro, esta tiende a generar código utilizando las características más avanzadas, abstractas y complejas del lenguaje. El resultado: frameworks llenos de flujos reactivos, lambdas anidadas y genéricos que asustan a los testers funcionales que están haciendo la transición a la automatización, y que convierten el mantenimiento de las pruebas en una pesadilla.

En QA Automation, la legibilidad mata a la complejidad. Un script de prueba debe ser tan claro que cualquier miembro del equipo pueda identificar por qué falló un test en menos de tres segundos.

A continuación, te comparto la estrategia que utilizo como Mentor y SDET para "domar" a la IA y obligarla a generar código simple, robusto y altamente didáctico, junto con el System Prompt exacto que puedes empezar a usar hoy mismo.

El System Prompt para entrenar a tu IA (Cursor / Copilot / ChatGPT)


Si utilizas un archivo .cursorrules o configuras las instrucciones personalizadas de tu IA, copia y pega el siguiente prompt. Está optimizado para mantener arquitecturas limpias basadas en patrones clásicos (Singleton, Factory, Builder) y manejo de datos moderno pero accesible mediante JSON.

Actúa como un Ingeniero de Automatización de Pruebas (SDET) Staff con un enfoque pedagógico y de mentoría. Tu objetivo es generar código de automatización en Java para Selenium y Appium que sea limpio, mantenible y fácil de entender por testers funcionales en transición o Juniors.

Sigue estrictamente estas directrices técnicas de diseño y la regla de simplicidad:

  1. PATRONES DE DISEÑO PERMITIDOS (Mantenlo simple):
  • Usa únicamente los patrones indispensables para QA: Singleton (para la gestión del WebDriver/AndroidDriver), Factory (para la creación de drivers según el navegador/plataforma) y Builder (para construir objetos de datos de prueba o configuraciones).
  • EVITA arquitecturas sobre-diseñadas o patrones complejos que añadan abstracción innecesaria. El flujo del test debe ser lineal y evidente.
  1. MANEJO DE DATOS CON JSON:
  • Toda la configuración de entornos, usuarios y propiedades del framework debe manejarse leyendo archivos JSON (no uses archivos .properties).
  • ALERTA DE SIMPLICIDAD: Al leer el JSON, prefiere métodos sencillos y utilitarios tradicionales empleando librerías estándar (como org.json o métodos directos de lectura de mapas básicos). Evita crear arquitecturas complejas de mapeo de objetos (POJOs avanzados con Jackson/Gson) o deserializaciones anidadas que requieran genéricos avanzados.
  1. EVITA JAVA AVANZADO:
  • No generes expresiones Lambda complejas, Streams anuidos o Programación Funcional. Si necesitas buscar un elemento en una lista o procesar datos, usa bucles ‘for’ tradicionales y bloques ‘if-else’.
  • Los nombres de las variables y métodos deben ser ultra-descriptivos y auto-explicativos.

REGLA DE ORO: El código debe ser tan directo que cualquier tester con bases esenciales de Java pueda debuggear un fallo en menos de un minuto sin perderse en abstracciones de código.

  1. PATRONES DE DISEÑO PERMITIDOS (Mantenlo simple):
    • Usa únicamente los patrones indispensables para QA: Singleton (para la gestión del WebDriver/AndroidDriver), Factory (para la creación de drivers según el navegador/plataforma) y Builder (para construir objetos de datos de prueba o configuraciones).
    • EVITA arquitecturas sobre-diseñadas o patrones complejos que añadan abstracción innecesaria. El flujo del test debe ser lineal y evidente.
  2. MANEJO DE DATOS CON JSON:
    • Toda la configuración de entornos, usuarios y propiedades del framework debe manejarse leyendo archivos JSON (no uses archivos .properties).
    • ALERTA DE SIMPLICIDAD: Al leer el JSON, prefiere métodos sencillos y utilitarios tradicionales empleando librerías estándar (como org.json o métodos directos de lectura de mapas básicos). Evita crear arquitecturas complejas de mapeo de objetos (POJOs avanzados con Jackson/Gson) o deserializaciones anidadas que requieran genéricos avanzados.
  3. EVITA JAVA AVANZADO:
    • No generes expresiones Lambda complejas, Streams anizados o Programación Funcional. Si necesitas buscar un elemento en una lista o procesar datos, usa bucles ‘for’ tradicionales y bloques ‘if-else’.
    • Los nombres de las variables y métodos deben ser ultra-descriptivos y auto-explicativos.

REGLA DE ORO: El código debe ser tan directo que cualquier tester con bases esenciales de Java pueda debuggear un fallo en menos de un minuto sin perderse en abstracciones de código.

Caso de Estudio: Código Abstracto vs. Código Legible

Para entender el impacto de guiar a la IA, analicemos un escenario común en Selenium: buscar un producto específico dentro de una lista de elementos web (WebElements) capturados en la interfaz de usuario.

❌ El enfoque de la IA por defecto (Complejo e Intimidante)

Sin instrucciones de simplicidad, la IA intentará optimizar el código usando Programación Funcional, Streams y expresiones Lambda de Java 11+. Aunque es código válido y elegante para un desarrollador backend, para un tester que está aprendiendo automatización resulta confuso y difícil de depurar con breakpoints:

Java

// Código generado por defecto: Difícil de leer y debuggear para Juniors
public WebElement buscarProducto(String nombre) {
    return driver.findElements(By.className("product-title")).stream()
            .filter(element -> element.getText().trim().equalsIgnoreCase(nombre))
            .findFirst()
            .orElseThrow(() -> new NoSuchElementException("Producto no encontrado: " + nombre));
}

El enfoque con el Prompt de Mentoría (Lineal, Claro y Funcional)

Al aplicar las reglas del prompt, la IA reescribe la misma lógica utilizando estructuras de control tradicionales. El flujo es totalmente secuencial, fácil de seguir línea por línea durante una sesión de debugging y perfectamente comprensible para cualquier perfil de QA:

Java

// Código generado con el prompt: Estructura lineal y auto-explicativa
public WebElement buscarProducto(String nombreProducto) {
    // 1. Obtenemos la lista de todos los elementos en la página
    List<WebElement> productos = driver.findElements(By.className("product-title"));
    
    // 2. Iteramos de forma tradicional sobre la lista
    for (WebElement producto : productos) {
        String textoProducto = producto.getText().trim();
        
        // 3. Si coincide con el producto que buscamos, lo retornamos de inmediato
        if (textoProducto.equalsIgnoreCase(nombreProducto)) {
            return producto; 
        }
    }
    
    // 4. Si termina el ciclo y no lo encuentra, lanzamos una excepción clara
    throw new NoSuchElementException("No se encontró el producto con el nombre: " + nombreProducto);
}

Conclusión: Construye Frameworks que unan al Equipo, no que lo dividan

Automatizar pruebas no se trata de demostrar qué tan avanzada es nuestra habilidad en Java, sino de garantizar la calidad del software de la manera más eficiente y colaborativa posible. Si creas un framework que solo tú puedes entender y mantener, has creado un cuello de botella, no una solución de ingeniería.

Utiliza este prompt en tus herramientas de asistencia con IA para asegurar que cada clase, factory o utilitario para leer configuraciones en JSON mantenga un balance perfecto entre la robustez profesional y la simplicidad pedagógica.

¿Qué opinas? ¿Has tenido que lidiar con frameworks sobre-diseñados en tus proyectos? ¡Te leo en los comentarios!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *