Esta lista está dirigida a una empresa que se prepara para recibir un configurador de productos, ofertas o proyectos. Permite definir las pruebas esperadas antes de aceptar la entrega, sin imponer una tecnología concreta.

Define qué debe entregar el configurador

El resultado esperado determina los controles. Una estimación orienta al visitante; una solicitud de presupuesto debe transmitir información suficiente para tramitarse; una compra debe conservar las opciones y el importe validados en el pedido. Define ese resultado antes de probar las pantallas.

Precisa también quién mantiene las opciones, sus incompatibilidades y las tarifas. Elige una configuración de referencia cuyo resultado esperado se calcule de forma independiente a partir de las tarifas y reglas aprobadas. Si el resultado esperado se copia del configurador, la prueba puede confirmar el propio error de la herramienta.

Una tabla de pruebas para utilizar con tu proveedor

Para cada fila, anota la configuración utilizada, el resultado esperado, el obtenido y una prueba: captura del resumen, referencia de la solicitud o registro recibido. Haz las pruebas en un entorno previsto para ello y con datos de contacto de prueba.

Situación que provocar Resultado esperado Prueba que conservar
Completar una configuración de referencia Opciones, cantidades y total coinciden con el cálculo independiente. Resumen y cálculo de referencia.
Volver a la primera elección después de añadir opciones Las opciones que han pasado a ser incompatibles se retiran o se señalan antes de confirmar; el precio se actualiza. Comparación antes y después del cambio.
Intentar una combinación prohibida Se explica la regla y la configuración no puede confirmarse en ese estado. Mensaje y comprobación de que no se ha creado una solicitud inválida.
Introducir una dimensión o cantidad en su límite permitido y después justo por encima Se respeta el límite de negocio; la unidad y la corrección necesaria son claras. Valores probados y respuestas.
Cambiar rápidamente varias opciones con precio El precio final corresponde a la última elección, aunque las respuestas de red lleguen en otro orden. Elección final e importe confirmado.
Actualizar la página o volver más tarde Se respeta el comportamiento previsto: recuperación coherente o aviso explícito antes de empezar de nuevo. Estado recuperado y mensaje mostrado.
Enviar dos veces la misma solicitud o reintentar después de un corte Se reconoce el mismo envío y se puede comprobar su estado, sin duplicados silenciosos. Referencia del envío y control en la herramienta receptora.
Repetir el recorrido en móvil y con teclado Las opciones, los errores y el resumen siguen siendo accesibles; ningún control esencial queda oculto. Recorrido observado y posibles incidencias.
Modificar una tarifa después de guardar una configuración El precio anterior sigue siendo identificable; cualquier actualización se explica antes de confirmar. Versión de la tarifa y regla de recálculo.

Esta tabla es una base. Añade las reglas propias de tu actividad: disponibilidad, zona atendida, plazo de fabricación o validación técnica. Un configurador destinado solo a presupuestos no necesita simular un pago, pero hay que comprobar la llegada de las solicitudes a la herramienta comercial.

Precio: distingue entre mostrar y validar

El visitante debe entender qué incluye el importe: opciones, cantidad, moneda, impuestos y posibles gastos pendientes de determinar. Una estimación debe identificarse como tal. Para una venta, compara el resumen con el importe que realmente aparece en el proceso de pago.

La comprobación técnica también debe confirmar que modificar el precio enviado por el navegador no permite imponer ese importe. OWASP recomienda recalcular los valores sensibles en el servidor a partir de datos fiables, en lugar de confiar en los campos enviados por el cliente. Solicita una prueba de este control en el entorno de pruebas: un total correcto en pantalla no lo demuestra.

Ejemplo metodológico: una opción que deja de ser posible

Imaginemos un configurador ficticio de casetas de jardín. El acabado elegido solo está disponible para ciertos modelos. El visitante selecciona ese acabado y después vuelve atrás para cambiar de modelo.

La prueba consiste en seguir la misma configuración hasta el final. El nuevo modelo debe activar la regla acordada: pedir otro acabado o retirar el que ha pasado a ser incompatible, explicándolo. Si se retira la opción, su suplemento debe desaparecer del total. El resumen y la solicitud recibida deben describir exactamente la misma caseta.

Este ejemplo ilustra un método de pruebas de aceptación; no describe a ningún cliente ni resultado de Codezilla. Comprueba una regla a través de varias pantallas y hasta la recepción, donde las pruebas pantalla por pantalla pueden dejar pasar una incoherencia.

Recorrido: permite comprender y corregir

En un recorrido de varias etapas, muestra el progreso y conserva las opciones cuando el visitante vuelva para revisarlas. El W3C recomienda estructurar los formularios en pasos lógicos y hacer comprensible su progreso.

Una incompatibilidad no debe traducirse en un botón desactivado sin explicación. La guía del W3C sobre notificaciones de formularios recomienda mensajes claros sobre los errores y el éxito del envío. Durante las pruebas, comprueba que el visitante detecta el problema, entiende cómo corregirlo y conserva el resto de la información introducida.

Recepción: comprueba qué podrá utilizar el equipo

Abre la solicitud en su destino real: bandeja de entrada, CRM, herramienta de presupuestos o pedido. Compárala con el resumen. Debe permitir recuperar la configuración, sus opciones, cantidades, importe y contexto tarifario, así como los datos de contacto necesarios para tramitarla.

Distingue entre la recepción en el sistema y el envío de un correo. Si la solicitud queda registrada pero falla la notificación, el equipo debe poder encontrarla. Si el envío sigue siendo incierto, el visitante debe poder consultar su estado o reintentar sin crear otra solicitud sin saberlo.

¿Cuándo aplazar la apertura?

Un precio incorrecto, una combinación prohibida aceptada o una solicitud que no aparece son motivos para aplazar. Una incidencia visual secundaria puede planificarse para después si no dificulta la comprensión ni la acción. Para cada incidencia pendiente, designa quién valida la corrección y qué escenario debe repetirse.

Estas pruebas no sustituyen una auditoría completa de seguridad o accesibilidad. Establecen un punto concreto: las reglas prioritarias del configurador se han comprobado hasta su resultado de negocio. Para definir un desarrollo a medida conectado a tu sitio, prepara tus reglas, una configuración de referencia y el destino de las solicitudes. Hablemos de tu configurador a partir de estos elementos.

Para preparar el siguiente paso