Pruebas automatizadas para el proceso de pago de la tienda en línea

Nuestra tienda se actualiza casi cada semana, y después de casi cada actualización, algo se rompe silenciosamente en el camino hacia el pedido. Un código promocional deja de aplicarse, el costo de entrega desaparece del total, el paso de pago devuelve al cliente a un carrito vacío. Nos enteramos de ello por los compradores que escriben al soporte, que es la forma más costosa de saber que el proceso de pago está roto, porque por cada persona que escribe, hay varias que simplemente se van. La verificación manual después de cada cambio no es realista: no hay nadie en el equipo con una hora libre para ello, y después del tercer lanzamiento consecutivo, la persona que verifica deja de mirar con atención.

Lo que quiero es un conjunto de escenarios automatizados que sigan el mismo camino que un cliente real. Desde la tarjeta del producto hasta un pedido pagado: agregar al carrito, cambiar la cantidad y eliminar un artículo, aplicar y cancelar un código promocional, elegir entre métodos de entrega y ver el total recalcularse, registro e inicio de sesión con una contraseña incorrecta entre los casos, y la cuenta personal después: historial de pedidos, direcciones guardadas, repetir un pedido anterior. El diseño móvil necesita sus propios escenarios, no una copia redimensionada de los de escritorio: la mayoría de nuestros pedidos se realizan desde teléfonos, y ahí es donde el carrito suele romperse primero. Todo debe comenzar por sí mismo en cada compilación, sin que nadie recuerde presionar un botón.

El informe es tan importante como las pruebas. Un gerente debería poder leerlo sin preguntar a un ingeniero: qué escenario falló, en qué paso, qué había en la pantalla en ese momento y cómo se veía la ejecución: una captura de pantalla del punto de fallo y una grabación de video de la prueba fallida. También necesito instrucciones escritas para nuestros propios desarrolladores, para que agregar un nuevo escenario más tarde sea una tarea normal y no un proyecto de arqueología.

Condiciones que estoy declarando de antemano: las pruebas se ejecutan en el entorno de staging con una clave de pago de prueba, nunca se realizan pagos reales; los pedidos de prueba no deben llegar a la contabilidad y reportes de la tienda; una prueba que falla en cada segunda ejecución se corrige o se elimina: una prueba poco confiable es peor que no tener prueba, porque la gente deja de leerla.

Lo que espero recibir:
— escenarios de extremo a extremo desde la tarjeta del producto hasta el pedido pagado, incluyendo códigos promocionales y opciones de entrega;
— escenarios de registro, inicio de sesión y cuenta personal;
— un conjunto separado de escenarios para el diseño móvil;
— inicio automático de todo el conjunto en cada compilación, con un resultado claro de aprobado o reprobado;
— un informe que un no ingeniero pueda leer, con una captura de pantalla del paso fallido;
— grabación de video de cada ejecución fallida, mantenida el tiempo suficiente para investigarla;
— instrucciones escritas para nuestros desarrolladores sobre cómo agregar y mantener escenarios;
— una breve sesión de entrega para que el equipo pueda ejecutar y extender el conjunto por su cuenta.