Respuesta.

Las pruebas manuales de integración son una etapa importante en el ciclo de vida del software que se realiza después de las pruebas unitarias. Su objetivo es asegurarse de que los módulos o componentes individuales del sistema interactúan correctamente entre sí.

Historia de la cuestión: Inicialmente, las pruebas de software se realizaban por etapas: primero se verificaban los módulos individuales (pruebas unitarias) y luego todo el sistema en su conjunto. Sin embargo, en la práctica, se descubrió que muchos errores críticos ocurren precisamente en la interfaz entre los módulos. Surgió la necesidad de pruebas de integración, que identifican manualmente las discrepancias en el comportamiento de diferentes partes del sistema.

Problema: La principal dificultad es la falta de desarrollo adecuado de los escenarios de interacción entre los módulos y las dependencias olvidadas. Esto lleva a errores "invisibles": durante las pruebas aisladas todo funciona correctamente, pero tras la integración surgen fallos (por ejemplo, un tratamiento incorrecto de datos entre la API y la base de datos).

Solución: Una correcta organización de las pruebas manuales de integración incluye:

Análisis de la arquitectura del sistema y creación de un mapa de interacciones de los componentes.
Desarrollo de casos de prueba de integración basados en escenarios de usuario y datos límite.
Modelado de fallos parciales (por ejemplo, la falla de uno de los servicios) y evaluación de la reacción de todo el sistema.
Documentación de resultados y fijación de dependencias entre errores.

Características clave:

Mantenimiento de un esquema arquitectónico actualizado.
Consideración de todas las dependencias ocultas y explícitas entre las partes del sistema.
Atención especial a los escenarios de transmisión y transformación de datos en las interfaces de los módulos.

Preguntas trampa.

¿Cuál es la diferencia entre las pruebas manuales de integración y las pruebas manuales del sistema?

Las pruebas de integración se centran en probar las conexiones entre módulos específicos, mientras que las pruebas del sistema verifican todo el sistema en su conjunto desde la perspectiva de su funcionalidad empresarial.

¿Deberían usarse servicios externos reales en las pruebas de integración, o basta con emuladores?

Para integraciones críticas, el entorno real es preferible, pero se puede comenzar con emuladores (mock/stub). Las pruebas finales deben realizarse en un entorno lo más parecido posible al de producción (PROD).

¿Se pueden detectar todos los errores de integración únicamente a través de la automatización?

No: algunos defectos se detectan solo manualmente, cuando el probador nota problemas no evidentes en la lógica empresarial de intercambio de datos o en los escenarios de usuario no cubiertos por la automatización.

Errores típicos y anti-patrones

Ausencia de una lista clara de puntos de integración.
Realización de pruebas sin aislamiento del entorno.
Insuficiente detalle en los casos de prueba de integración.

Ejemplo de la vida real

Caso negativo

Las pruebas de integración entre el módulo de pagos y el módulo de pedidos se realizaron solo después de completar todas las demás pruebas y sin documentación separada.

Ventajas:

Ahorro de tiempo en la preparación de casos de prueba.
Rápido inicio de las pruebas sin coordinación compleja.

Desventajas:

Filtración de errores graves a producción, relacionados con el cobro doble de fondos.
Retrasos en el lanzamiento para corregir errores encontrados en el último momento.

Caso positivo

Los escenarios de integración se documentaron desde el principio, y los datos de prueba se acercaron lo más posible a las tareas reales de los usuarios.