Respuesta.

La prueba manual de integraciones es el proceso de verificación de la interacción entre diferentes módulos, servicios o sistemas externos manualmente, sin scripts automáticos.

Historia de la pregunta:

En los inicios del desarrollo de productos de TI, todos los sistemas se creaban de forma monolítica, pero a medida que crecían las empresas y aumentaba el número de servicios externos, las pruebas de integración se volvieron relevantes. Los testers comenzaron a preguntarse: ¿cómo asegurarse de que los datos y acciones se transmiten correctamente entre los sistemas, por ejemplo, que un pago exitoso se refleja tanto en la facturación como en el sistema de contabilidad?

Problema:

La mayor dificultad es la falta de un entorno totalmente funcional: las integraciones pueden depender de servicios externos, API inestables o limitaciones externas. Además, las pruebas manuales en cada punto de integración pueden ser muy laboriosas, es fácil cometer un error en la secuencia de pasos o pasar por alto una consecuencia en cascada importante.

Solución:

Use entornos de prueba con "mocks" (mock/stub) para garantizar la repetibilidad de la prueba.
Estructure los casos de prueba, escriba verificaciones paso a paso de mensajes, registros, estados.
Primero verifique los casos límite, timeouts, reintentos de llamadas de integración, y la reacción del sistema a fallos.

Características clave:

Necesidad de comprender la lógica empresarial de ambas partes integradas.
Consideración de la asincronía y los errores en la transmisión de estado.
Soporte para la resistencia a fallos parciales.

Preguntas capciosas.

¿Qué son los dobles de prueba (test doubles) y para qué se necesitan en la prueba manual de integraciones?

Los dobles de prueba son simulaciones de componentes de integración (por ejemplo, mock, stub, fake). En las pruebas manuales, se necesitan para ejecutar escenarios cuando el verdadero sistema externo no está disponible o sus llamadas tienen un costo.

¿Se puede considerar que la integración está probada si los casos de prueba solo cubrieron el happy path?

No. Es necesario probar obligatoriamente los edge cases: errores de conexión, formatos de datos incorrectos, timeouts, respuestas inesperadas.

¿Es suficiente con verificar solo el envío/recepción de datos o se necesita más?

Es importante verificar la corrección del CONTENIDO de los datos, su transformación y el comportamiento del sistema ante varios errores en las interacciones.

Errores típicos y anti-patrones

Trabajar solo con la parte "propia" del sistema, sin verificar el comportamiento del lado del socio.
Ignorar escenarios negativos.
No analizar los registros o no acumular un historial de errores de integración.

Ejemplo de la vida real

Caso negativo

El tester verifica la integración entre CRM y el sistema de facturación solo en la adición exitosa de un pedido. No verifica el error de sincronización y la omisión de la transacción.

Pros:

Cobertura rápida de los escenarios principales.

Contras:

Un error en el fallo de la integración solo se descubrirá con datos reales.

Caso positivo

El tester crea un conjunto de pruebas desactivando y activando la conexión a Internet, sustituyendo con tokens no válidos. Valida los registros de ambas partes.