Pruebas del One Page Checkout de PrestaShop 9.2: un plan práctico de QA
Las pruebas del checkout deben demostrar que el pedido final coincide con las últimas elecciones válidas del cliente. Una pantalla de confirmación verde no basta si llegan al Back Office un transportista, dirección, importe de impuestos o estado de pago incorrectos.
Este plan es para PrestaShop 9.2 RC1 en una instalación de pruebas aislada. Registra las versiones exactas del módulo de checkout, del tema y de los módulos de pago junto con la del núcleo. La documentación oficial del checkout señala específicamente la compatibilidad de módulos; su implementación puede evolucionar al margen de las suposiciones de los scripts personalizados de una tienda. Referencia de integración de módulos.
Los casos siguientes son pruebas propuestas. No afirman que esas combinaciones ya las hayan superado.
Empieza por entender cómo el One Page Checkout nativo cambia la compra; el plan de aceptación debe cubrir el checkout que pretendes utilizar, incluidas sus integraciones de pago y entrega.
Crear datos de prueba que hagan evidentes los resultados incorrectos
Utiliza un catálogo pequeño y deliberadamente variado: un artículo físico normal, uno con entrega restringida, un producto con combinaciones y, si la tienda los vende, un artículo virtual. Establece stock y precios conocidos. Evita un catálogo aleatorio grande que dificulte explicar cada fallo.
Crea un invitado, un cliente registrado con una dirección y otro con varias. Utiliza datos sintéticos. Define al menos dos destinos con distinta elegibilidad de entrega. Si su tratamiento fiscal difiere, ten disponible el cálculo esperado según la configuración del comerciante antes de ejecutar la prueba.
Crea un umbral de envío y cupones que ejerciten las reglas reales de tu tienda. No supongas en qué orden deben aplicarse descuentos y umbrales; escribe la configuración prevista y el total esperado de cada conjunto de prueba.
Para cada prueba, conserva:
- Versiones del núcleo, tema y módulos, además del contexto de tienda e idioma.
- Carrito inicial, estado del cliente y configuración relevante.
- Acciones exactas, resultados esperados y reales.
- Identificadores de carrito y pedido, referencia sandbox del pago y marcas de tiempo.
- Capturas o trazas de solicitudes con datos sensibles ocultos cuando sean necesarias para explicar un fallo.
Una captura es una prueba útil de lo que vio el cliente. El registro del pedido y el resultado del pago establecen lo que confirmó la tienda. Captura ambos.
Probar la identidad del cliente como una transición de estado
Finalización como invitado
Empieza en una sesión limpia del navegador. Añade un producto, introduce información de contacto y dirección válidas, elige la entrega y completa un pago sandbox. Comprueba que se crea un único pedido previsto, que los datos del cliente son correctos y que el importe registrado coincide con el resumen final.
Repite dejando un campo obligatorio vacío. El checkout debe identificar el problema sin descartar otros datos válidos. Corrige el campo y vuelve a enviar. Un fallo de validación no debe dejar un pedido parcial oculto que después genere un duplicado.
Cliente habitual
Inicia sesión con una cuenta que tenga dos direcciones. Selecciona la no predeterminada y completa el pedido. Verifica el destino en el pedido guardado, no solo el botón de opción seleccionado.
Después inicia otro carrito, cambia de identidad mediante el flujo admitido de inicio o cierre de sesión y vuelve al checkout. Comprueba que las direcciones, precios y opciones de entrega específicos del cliente pertenecen a la identidad actual. No aceptes que se muestre la dirección de un cliente anterior como un problema visual inofensivo.
Actualización y navegación
Actualiza después de introducir una dirección, elegir la entrega y volver de un pago cancelado. Usa la acción de volver del navegador cuando el flujo lo permita. La política prevista de persistencia debe documentarse y el cliente debe poder recuperarse sin pagar dos veces sin saberlo.
Invalidar correctamente las opciones dependientes al cambiar la dirección
El escenario importante no es solo introducir dos direcciones. Es cambiar la dirección después de que el checkout ya haya derivado otros estados.
| Secuencia | Comprobación requerida |
|---|---|
| Seleccionar transportista y después cambiar el país de destino | Se recalcula la elegibilidad de entrega |
| Introducir un código postal válido y después uno no válido | Se identifica la entrada no válida antes de la aceptación final |
| Elegir una región y cambiar a un país con reglas regionales distintas | Ninguna región obsoleta determina silenciosamente el resultado |
| Utilizar direcciones separadas de facturación y entrega | Cada una se guarda con la función correcta |
| Editar una dirección guardada durante el checkout | El pedido final utiliza la edición aceptada |
Ejecuta también un caso de edición rápida: cambia dos veces un campo relevante antes de que termine la primera actualización. El estado final mostrado y guardado debe corresponder a la última entrada aceptada. La limitación de red del navegador puede revelar un problema de orden sin acceder a los detalles internos del módulo.
Si ocurre un fallo, conserva la secuencia y los tiempos. «El envío está mal» da poco que reproducir a un desarrollador; «el país cambió después de elegir el punto de recogida y la opción antigua permaneció en el pedido» permite actuar.
Probar conjuntamente envío, cupones e impuestos
El envío y las promociones suelen fallar en los límites. Sitúa el carrito justo por debajo del umbral configurado de envío gratuito, alcanza el umbral y vuelve a quedar por debajo. Aplica y elimina el cupón relevante en cada punto significativo.
No compruebes solo que cambia el total. Contrasta el importe con el cálculo preparado de forma independiente e inspecciona la línea de envío del pedido resultante. Un total visualmente plausible puede seguir siendo incorrecto.
Para módulos de transportistas, selecciona un punto de recogida o una fecha de entrega si se utilizan esas funciones. Cambia de transportista y vuelve al anterior. Verifica que toda selección restaurada siga siendo válida para la dirección y el carrito actuales. Completa el pedido e inspecciona los datos utilizados en su preparación.
Para impuestos, utiliza las configuraciones conocidas de la tienda y los resultados esperados. Incluye un cambio de destino y un caso de grupo de clientes si afectan a tu tienda. Esto es QA de software respecto a reglas configuradas, no consejo sobre qué tratamiento fiscal es legalmente correcto.
Prueba deliberadamente una combinación no elegible. Un producto restringido y un destino no admitido deben producir un estado de bloqueo comprensible, no un botón de pago aparentemente disponible que solo falle al final.
Tratar los pagos fallidos como casos normales de aceptación
Utiliza los resultados sandbox documentados de cada proveedor. Cubre éxito, rechazo, cancelación y un retorno interrumpido del navegador cuando la integración admita esas simulaciones.
Un caso fiable compara tres observaciones: lo que informa el proveedor, lo que registra el módulo de pago y lo que ve el cliente. Pueden volverse coherentes de forma asíncrona, así que define un periodo razonable de observación para el módulo en vez de asumir que todo resultado es inmediato.
Incluye estas comprobaciones:
- Enviar una vez y verificar la relación prevista entre pedido y pago.
- Hacer doble clic o repetir la acción admitida de envío y comprobar efectos de negocio duplicados.
- Cancelar externamente y confirmar que la recuperación no marca falsamente el pedido como pagado.
- Volver tras el éxito y actualizar la página de confirmación sin crear otro pedido.
- Cambiar el carrito tras un intento fallido, volver a intentar y verificar el nuevo importe.
- Cuando lo permita el sandbox del proveedor, reproducir una notificación y comprobar el tratamiento de duplicados.
No fabriques callbacks ni evites la verificación del proveedor para hacer que una prueba parezca exitosa. Utiliza las herramientas sandbox admitidas por la integración e involucra a su responsable cuando no pueda simularse un fallo de forma segura.
Un fallo de recuperación es distinto de un fallo al iniciar el pago. Infórmalos por separado para que quede claro el contrato afectado.
Comprobar la interacción móvil y el aislamiento de tiendas
Elige tamaños reales de dispositivo representativos de los clientes. Prueba con el teclado en pantalla abierto, autocompletado, una dirección larga y un error de validación por encima de la zona visible. Comprueba que la acción final siga siendo localizable y que los totales puedan revisarse antes de enviar.
Utiliza navegación solo con teclado en escritorio. Cuando se actualice una sección, verifica que el foco siga siendo razonable y que pueda encontrarse un error. Una prueba exitosa con ratón no demuestra que todos los clientes puedan utilizar el flujo.
En multitienda, crea configuraciones deliberadamente distintas en dos tiendas: un transportista disponible en una, un cupón aplicable solo donde corresponda y una configuración de pago distinta si se admite. Repite el checkout relevante en cada tienda con sesiones separadas. Verifica la asociación del pedido a la tienda y la cuenta de integración que recibe el evento de prueba.
El objetivo no es probar todas las combinaciones posibles. Prioriza las que puedan mover dinero, cambiar la elegibilidad de entrega o filtrar la configuración de una tienda a otra. Añade casos de presentación de menor riesgo después de cubrir esas invariantes.
Antes de repetir un caso, restaura o recrea su estado inicial. Un cupón ya consumido por un pedido anterior, un stock reducido o una cuenta creada en el intento previo pueden cambiar el resultado. Asigna identificadores previsibles a los datos de prueba y documenta qué objetos son reutilizables. Así se evita informar de contaminación de pruebas como si fuera una regresión del checkout y se hace mucho más fiable la reproducción por otro probador.
Mantén el resultado esperado independiente de la pantalla observada. Copiar el total mostrado en el informe como total esperado haría que un cálculo incorrecto se validara a sí mismo.
Convertir los resultados en una decisión útil de aceptación
Clasifica los fallos por su efecto en el negocio. Un pago incorrecto o la duplicación de pedidos bloquean la aceptación. Una elección de transportista no válida también es un fallo de corrección. Un problema estético de alineación tiene otra gravedad, salvo que impida al cliente entender o completar la compra.
Repite la secuencia exacta que falló tras corregirla y después los casos cercanos que compartan la misma dependencia. Por ejemplo, una corrección del refresco de pagos justifica comprobar tanto los refrescos por dirección como por transportista. Repetir casos ajenos sin motivo añade tiempo sin aclarar el impacto de la corrección.
Mantén visibles las limitaciones pendientes en el registro de aprobación. Un caso marcado «no probado» no es un aprobado. La confirmación de un proveedor de módulos aporta apoyo útil, pero no sustituye probar la configuración propia de la tienda.
El resultado final debe identificar la combinación de versiones probada, los escenarios críticos superados, los fallos restantes y la persona responsable de la siguiente decisión. Mientras 9.2 siga siendo software RC, esa decisión es sobre la preparación para seguir evaluando, no sobre permiso para instalar la candidata en una tienda en producción.
Para conocer el contexto de la plataforma, consulta nuestra guía de actualización segura de PrestaShop 8 a 9 y aplica las comprobaciones específicas de versión anteriores a la instalación que estás evaluando.