Cómo crear pruebas automáticas con IA para una tienda online

La frase «la IA ha probado la tienda» no dice qué se comprobó. Una página puede cargar y, sin embargo, aplicar mal un descuento o enviar un pedido dos veces. Para que una prueba automática aporte valor, alguien debe definir una conducta visible, un resultado esperado y un entorno en el que un fallo no cobre a clientes. Un asistente puede proponer el primer borrador del test; la decisión sobre qué riesgo cubrir sigue siendo editorial y técnica.

Primero, un entorno que no venda de verdad

Prepara una copia de pruebas con productos, usuarios y cupones ficticios. Bloquea los envíos a clientes y verifica el modo de prueba de la pasarela. WooCommerce recomienda ejecutar las pruebas en un sitio de staging y advierte que incluso los pedidos de prueba pueden disparar correos, integraciones y registros de analítica. Una captura de pantalla que muestre «pedido recibido» no demuestra que nada más se haya activado.

Si utilizas WooPayments, su documentación del modo de prueba explica cómo simular pagos y localizar transacciones de ensayo. Para otra pasarela hay que seguir su manual; no presupongas que el ajuste de WooCommerce desactiva todos los cobros externos. Incluye en la ficha del entorno qué correos se interceptan, qué integraciones se han desconectado y cómo se eliminan los datos ficticios.

Convierte tareas de cliente en casos comprobables

Escribe cuatro historias breves antes de pedir código a la IA. «Busco un producto por su nombre y veo un resultado relevante»; «envío un formulario y recibo una confirmación»; «aplico un cupón válido y cambia el total»; «termino una compra simulada y aparece un único pedido». Añade la variante que debería fallar: búsqueda sin resultados, formulario incompleto, cupón caducado o pago rechazado. Cada caso debe indicar datos de entrada, acción, resultado visible y comprobación posterior en el sistema.

Una ficha útil para el cupón sería: producto de ensayo de 40 euros; cupón ficticio del 10 % aplicable a ese producto; expectativa de descuento de 4 euros antes de cualquier otro cargo. La cantidad es un ejemplo aritmético, no una medición de una tienda. El test ha de leer el total real y comprobar por separado impuestos, transporte y restricciones definidas en la configuración. Pedir «que el checkout funcione» produce una prueba demasiado vaga.

Usa la IA como redactora de tests, no como juez

Entrega al asistente la historia, las reglas del cupón y la tecnología de la web. Pide que proponga casos positivos y negativos, explique cada aserción y señale los supuestos que faltan. Revisa el resultado con quien conoce el negocio. Por ejemplo, un test que espera «algún mensaje de éxito» puede aprobar aunque el formulario no haya guardado el correo; otro puede confundir un descuento visible con un pago realmente correcto.

En Playwright conviene seleccionar controles por su nombre accesible o etiqueta, una práctica recomendada en la documentación oficial de localizadores. Sus aserciones sobre elementos web pueden esperar y volver a comprobar un estado dinámico. Esto reduce fallos por tiempos de carga, pero no corrige una expectativa de negocio equivocada. Evita aserciones basadas solo en clases CSS o en que exista un botón.

Haz que cada prueba deje una respuesta interpretable

Ejecuta un caso por escenario y usa datos identificables, como cliente-prueba-cupon-01. Comprueba que el pedido de prueba aparece una sola vez, que el importe coincide con la regla escrita y que el cupón inválido muestra un rechazo comprensible. Aísla cuentas y sesiones para que un carrito anterior no contamine el siguiente caso; Playwright recomienda pruebas independientes precisamente para evitar fallos encadenados.

Cuando falle, conserva traza, mensaje y datos del escenario. El visor de trazas de Playwright permite revisar acciones y estados de la página. La traza ayuda a reproducir el fallo, pero puede contener información sensible: usa datos ficticios y controla quién accede al archivo. Un reintento que pasa a la segunda no equivale a un comportamiento fiable; investiga por qué cambió el resultado.

Qué dejar fuera hasta poder controlarlo

No conectes un agente generativo a producción para que «explore» el checkout sin límites. Puede crear pedidos, consumir cupones o activar notificaciones. Empieza por pruebas repetibles en staging y una revisión humana de los casos generados. Si el catálogo o las reglas cambian, actualiza primero la expectativa; no aceptes que la IA modifique un test únicamente para devolverlo a verde.

Este tutorial trata de validar el recorrido de compra. Se diferencia de automatizar operaciones cotidianas de la tienda: aquí la meta es detectar una regresión antes de que afecte a compradores, no procesar ventas. Una prueba aprobada confirma solo los escenarios y el entorno ejecutados; necesita complementarse con revisión de accesibilidad, seguridad y comportamiento de integraciones.

Fuentes y método

Guía documental elaborada con WooCommerce sobre pedidos de prueba, WooPayments y documentación oficial de Playwright. Los ejemplos son planes de ensayo: no se ejecutó una prueba sobre una tienda ni se observaron errores reales.