¿Es normal recibir un proyecto sin pruebas de integración de API, deberíamos haberlo exigido en el contrato?

Llevo años metido en estos proyectos, la agencia está intentando endosaros la parte más pesada del trabajo, las pruebas de escenarios. Que el endpoint devuelva 200 no significa nada. El banco o el proveedor de pago da el visto bueno, pero ¿qué pasa si vuestro sistema sufre un timeout en ese momento? Una infraestructura de pago sin probar no se pone en producción.

Lo crítico en los sistemas de pago es la gestión de webhooks. Cuando el usuario cierra el navegador o se corta la conexión, ¿son capaces de procesar la notificación asíncrona que llega por detrás? ¿Cómo se comporta la API en caso de reembolso o cancelación parcial? Tienen que hacer estas pruebas en el entorno sandbox con peticiones simuladas y entregaros los registros de logs.

Bloquead ya el pago final. Mandad un correo a la agencia y decidles "según nuestros criterios de aceptación no se firmará el acta de conformidad sin que el proveedor de pago documente en su entorno de pruebas 5 escenarios básicos (cobro exitoso, límite insuficiente, cancelación de 3D secure, timeout y reembolso automático)". Su actitud cambiará al instante.

Hicimos un error parecido hace dos años en nuestro proyecto turístico con un presupuesto de 18.000 EUR. Confiamos en la agencia y lo pusimos en producción; la primera semana se cobró el dinero en 22 transacciones pero la reserva del calendario no se registró. Tuvimos que devolver 3.100 EUR a los clientes y cerrar el sistema 10 días. Los tres días que no dedicamos a probar nos costaron dos semanas.

¿Hay alguna cláusula en el contrato que firmasteis sobre pruebas de aceptación o el proceso de puesta en marcha? Si han metido una cláusula estándar tipo "se considerará aprobado si no se presenta objeción en los 14 días siguientes a la aprobación del cliente", puede que tengáis que enviar ya una notificación de objeción por escrito antes de que venza el plazo.

Yo creo que la agencia ni siquiera tiene un desarrollador con la cualificación para escribir pruebas de integración. Normalmente instalan el plugin ya hecho, pegan dos claves de API y creen que el trabajo está terminado. Por eso se escaquean. Seguramente, aunque les apretéis, no serán capaces de sacar una matriz de pruebas decente.

Al recibir el proyecto deberíais pedir estos tres documentos: 1) La tabla de resultados de escenarios ejecutados en el entorno sandbox, 2) Capturas de pantalla de los mensajes de error mostrados al cliente en transacciones fallidas, 3) El informe de conciliación entre las transacciones hechas con tarjetas de prueba en el panel de pago y la base de datos de la web. Sin esto, el sistema no se considera entregado.

no os preocupéis pero tampoco deis marcha atrás pero a los programadores no les gusta nada hacer pruebas porque limpiar los bugs que salen ahí retrasa la entrega. vosotros manteneos firmes con vuestro dinero que esos 4.000 EUR no salgan de caja hasta que llegue el informe de pruebas.

Me quedé tranquilo al leer esta respuesta, así que no solo me pasa a mí... Si no se definen los criterios de aceptación cuándo termina el trabajo es discutible.

Si no lo pones por escrito desde el principio, luego surgen discusiones.

Permíteme resumir lo que se ha dicho hasta ahora. El sistema sigue vivo después de la entrega; el mantenimiento es una partida aparte.

El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas. Comprobado por experiencia.

Tienes razón, yo también pasé por lo mismo. El sistema sigue vivo después de la entrega; el mantenimiento es una partida aparte.

Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza. Eso es todo, disculpa si me he extendido demasiado.

Exacto, y encima no es tan conocido. El sistema sigue vivo después de la entrega; el mantenimiento es una partida aparte.

También me gustaría saber si alguien lo hace de otra manera.

No sabía eso. Antes de decidir, mirad qué datos tenéis en la mano.

Por supuesto, cambia si tu situación es diferente.

Ha sido una buena idea abrir este hilo.

¿Podría ampliar un poco esto? o sea el sistema sigue vivo después de la entrega; el mantenimiento es una partida aparte.

Lo dejo como nota por si sirve.

Hay algo que no entiendo. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Yo pasé por esto, déjenme contarlo... El error cometido por prueba de integración de api suele ser reversible pero caro.

Lo dejo como nota por si sirve.

Estoy siguiendo esto.