Cada nivel de pruebas cumple un papel específico en el desarrollo de software y responde a una pregunta distinta:
Tests unitarios - “¿Ha cambiado una función que debía permanecer sin cambios?” Prueban las piezas de código más pequeñas y aisladas (funciones o métodos individuales) de forma independiente del resto del sistema. (Un análisis detallado de los tests unitarios se trata en otro artículo del blog.)
Tests de integración - “¿Siguen funcionando correctamente juntos los componentes después de un cambio?” Prueban conexiones reales entre módulos (p. ej., base de datos + capa de servicio + API), y no solo funciones aisladas. Descubren escenarios en los que las partes individuales pasan por separado pero fallan al combinarse.
Tests E2E (End-to-End) - “¿Funciona el sistema como lo viviría un usuario real?” Simulan flujos de trabajo completos del usuario (inicio de sesión → acción → resultado) a través de la interfaz o la API reales. Detectan regresiones que ni los tests unitarios ni los de integración pueden encontrar, porque estos problemas solo aparecen dentro de un flujo de trabajo real.
(Existen, por supuesto, otros tipos de pruebas, como los *Smoke tests**, las pruebas de carga o las de seguridad, que quedan fuera del alcance de este artículo.)*
Todos los niveles de pruebas automatizadas comparten un objetivo común: verificar que la funcionalidad no se ha roto fuera del alcance de la Task en la que se está trabajando. Una Task puede completarse a la perfección según las especificaciones y, aun así, romper otra cosa como efecto secundario no deseado. Sin una capa de pruebas que vaya más allá del cambio concreto, nadie lo notaría hasta que un usuario informe del problema en producción.
El papel esencial de las pruebas manuales
A pesar de la automatización avanzada y de la integración de la IA, las pruebas manuales conservan su papel indispensable y principal. Un tester humano aporta criterio real, intuición y la capacidad de detectar matices sutiles o comportamientos inesperados de la interfaz que los scripts automatizados pasan por alto con facilidad. La verificación manual fue, es y siempre será lo que da al equipo de desarrollo un 100 % de confianza en que la aplicación está lista para usuarios reales.
Desarrollo asistido por IA y cómo compensar la "ceguera"
En la era del desarrollo asistido por IA, una capa de pruebas automatizadas es aún más crítica. Un agente de IA no puede percibir todo el sistema a la vez, por lo que los efectos secundarios son más probables que con un desarrollador humano que lleva consigo todo el contexto y el historial de decisiones pasadas. Los tests sirven como mecanismo para compensar sistemáticamente esta ceguera del sistema antes de que el código llegue a la aprobación humana final.
Impacto práctico: los retos de las pruebas E2E con IA
Crear tests E2E es especialmente complejo para la IA. No se trata solo de escribir el propio script de prueba, sino sobre todo de preparar datos de prueba adecuados para que el software pueda usarlos (a menudo solo para una pequeña parte de la prueba). Preparar esos datos es muy exigente.
Piensa en una acción aparentemente sencilla: hacer clic en una lista desplegable y seleccionar un parámetro (p. ej., el tipo de documento Factura). Si la prueba falla o no se completa, es crucial diagnosticar la causa raíz exacta. Pueden haberse dado varias situaciones:
- La IA se perdió y no pudo encontrar el elemento desplegable en la interfaz (aunque está presente).
- La prueba encontró un error anterior en el camino y no pudo recuperarse.
- El desplegable existe, pero no contiene los datos esperados para seleccionar.
- La IA recurrió a JavaScript (un atajo invisible), estableciendo el valor por programa con éxito pero dejándolo invisible para un usuario real.
En torno a un único desplegable pueden surgir numerosos problemas. Lo clave es si la IA (o el sistema de evaluación) puede distinguir un error genuino de un fallo en cascada causado por otra cosa. Que los datos se guarden con éxito no garantiza que todo funcione correctamente.
Enfoque conductual y cobertura de pruebas
Por este motivo, los tests siempre deben centrarse en el aspecto conductual del sistema, probando lo que realmente esperamos que ocurra:
Happy Path (~90 % de los casos): el foco principal está en lo que los usuarios harán la inmensa mayoría de las veces.
Casos límite críticos: condiciones límite que no ocurren con frecuencia, pero que son vitales para la integridad del sistema.
Otras combinaciones menos probables no se prueban de antemano. Si ocurren en producción, se corrigen sobre la marcha o se previenen mediante restricciones y validaciones del software (p. ej., deshabilitar la navegación hasta que los datos de entrada sean válidos).
Pruebas E2E en AITM
Dentro de AITM, las pruebas E2E representan una fase obligatoria del pipeline, explícita, para las Tasks que afectan a la interfaz (determinadas por el tipo/intención de la Task). No es un añadido opcional que se omite cuando se acercan los plazos: un pipeline no puede marcarse como completo sin ella.
Si falta un test E2E o el entorno no está disponible, el build falla por defecto (con raras excepciones en las que se permite continuar con un E2E fallido). Además, cada ejecución E2E captura capturas de pantalla visibles en los resultados de la Task.
Cómo funciona E2E actualmente:
- Antes de ejecutar los tests, se garantiza que el build es correcto y se ejecuta en su propio worktree aislado.
- El estado de la base de datos se prepara con datos de prueba específicos junto con los registros por defecto.
- Las pruebas se centran estrictamente en el Happy Path (no cubren todos los escenarios posibles).
Hoja de ruta futura de E2E:
- Flow Maps - El sistema construye un mapa de rutas hacia los elementos dados, vinculado directamente a la lógica de negocio (ya integrado en AITM).
- Navegación autónoma - Los tests leen el mapa de rutas en vivo, sabiendo exactamente dónde hacer clic, escribir y verificar (actualmente en fase de pruebas).
- Comparación de estados (Visual Diffing) - Cada paso se registra con capturas de pantalla tomadas antes y después de las modificaciones de código, para confirmar que los elementos y datos esperados coinciden con lo esperado en la BD o la interfaz.
- Verificación de la lógica de negocio - Comprobación automatizada de los datos de salida esperados (p. ej., totales de factura verificados; actualmente en desarrollo).
- Ejecuciones de integración nocturnas - Los tests de integración de extremo a extremo se generarán automáticamente a partir de los estados de los pasos y los requisitos del software para ejecutarse por la noche. Cualquier fallo generará Tasks o solicitará verificación humana (ya que la IA puede equivocarse y necesita la aprobación de una persona).
- Escenarios avanzados - Las futuras versiones incorporarán inyección de parámetros no válidos, pruebas de concurrencia con varias instancias y simulaciones de casos límite.
Resumen de los principios básicos de E2E
La esencia de unas pruebas E2E eficaces se basa en gestionar los mapas y las relaciones entre entidades de datos. Para el 90 % del software, se reduce al ciclo de vida estándar:
#AITM #Data Input Validation #E2E #Integration test #AI TESTING