Pruebas SIT: qué son las pruebas de integración de sistemas

Las pruebas SIT (system integration testing, o pruebas de integración de sistemas) comprueban que su software funciona correctamente con los demás sistemas de los que depende, como un proveedor de pagos, un banco o la base de datos de un socio. En el orden habitual, este nivel llega después de que su propio producto supere las pruebas de sistema y antes de que los usuarios de negocio prueben el conjunto completo en las pruebas de aceptación.

Prescindir de las pruebas SIT es arriesgado cuando distintas empresas construyen y gestionan las piezas de las que depende su producto. Cada equipo puede superar sus propias comprobaciones mientras el enlace entre dos sistemas sigue fallando. Ese fallo suele aparecer primero delante de los clientes. Para evitarlo, decida pronto quién prueba esas conexiones, en qué entorno y con los datos de quién.

Como estas comprobaciones dependen de que varios propietarios de sistemas trabajen juntos, el trabajo suele recaer en un equipo de QA dedicado capaz de coordinar las pruebas con cada proveedor implicado. En este artículo, nuestros ingenieros de QA explican qué abarcan las pruebas de integración de sistemas, en qué se diferencia este método de las pruebas de integración y de las pruebas de aceptación de usuario (UAT), y en qué tipo de proyectos compensa este paso adicional.

¿Qué comprueban realmente las pruebas SIT?

Las pruebas SIT examinan cómo se conecta su producto con servicios externos. El International Software Testing Qualifications Board (ISTQB), el organismo internacional que certifica a los probadores de software, define las pruebas de integración de sistemas como la comprobación de «las interfaces del sistema bajo prueba y otros sistemas y servicios externos». Dicho de forma sencilla, una interfaz es el punto en el que dos programas se pasan datos entre sí.

Piense en una tienda online que envía cada pedido a un proveedor de pagos, a la base de datos de un almacén y a un servicio de correo electrónico. Cada uno de esos servicios puede funcionar perfectamente por separado. Las pruebas SIT se preguntan si el pedido sigue llegando completo y correcto después de cada traspaso.

En la práctica, los probadores buscan cuatro tipos de problemas:

• Datos que no coinciden: un servicio envía una fecha, un precio o una dirección en un formato que el otro lado interpreta de otra manera.
• Traspasos rotos: un mensaje se pierde, llega duplicado o llega demasiado tarde para servir de algo.
• Caídas sin gestionar: cuando el servicio de un socio deja de estar disponible, su producto se bloquea sin explicar al usuario qué ha pasado.
• Accesos rechazados: el token de seguridad de su producto, una llave digital temporal que demuestra quién está pidiendo los datos, funciona dentro de su propio sistema, pero el servicio del otro extremo lo rechaza.

Muchos de estos errores se remontan a unos pocos patrones de fallo de integración recurrentes, como notificaciones automáticas que nunca llegan o respuestas que informan de un éxito mientras ocultan un error.

SIT vs pruebas de integración vs UAT: dónde encaja cada una

Es habitual confundir las SIT, las pruebas de integración y la UAT, porque las tres tienen que ver con software que funciona en conjunto. La diferencia está en la escala y en la pregunta que responde cada nivel. El programa de estudios actual del ISTQB incluso divide las pruebas de integración en dos: las pruebas de integración de componentes, para las piezas de un mismo producto, y las pruebas de integración de sistemas, para las conexiones entre productos.

Las pruebas de integración suelen consistir en comprobar dos piezas que han creado sus propios desarrolladores, como un formulario de registro y la base de datos que guarda las cuentas nuevas. Las SIT amplían el alcance a sistemas que pertenecen a otros equipos o proveedores, por ejemplo un proveedor de pagos o el servicio de tarjetas de un banco. Las pruebas de aceptación de usuario ponen el producto terminado y conectado en manos de los usuarios de negocio, que pueden confirmar, por ejemplo, que un pedido de venta se tramita como se espera.

La tabla siguiente compara las SIT y la UAT, junto con los dos niveles anteriores:

¿Cuándo necesita su proyecto pruebas SIT?

Necesita pruebas SIT cuando su producto depende de sistemas que usted no controla. El riesgo es mayor en las grandes empresas, donde su aplicación intercambia datos con herramientas de otros equipos, como una base de datos de clientes o un sistema de planificación de recursos empresariales (ERP), el software que gestiona las finanzas, el inventario y las nóminas. Los flujos de pago e identidad requieren el mismo cuidado, porque el dinero o los datos personales pasan por un proveedor de pagos, un banco o un servicio de verificación.

El software antiguo también eleva el riesgo, ya que una aplicación nueva a menudo tiene que funcionar con un sistema que nadie quiere tocar. El caso más reciente es un asistente de IA capaz de actualizar su calendario, sus registros de clientes o sus tickets de soporte, porque se conecta por separado a cada una de esas aplicaciones, y cualquiera de esos enlaces puede fallar.

En la UE, los bancos, las aseguradoras y otras entidades financieras tienen además un motivo legal para probar estas conexiones. Según el Reglamento de Resiliencia Operativa Digital (DORA), estas empresas deben comprobar periódicamente cómo resisten sus sistemas bajo presión, y es posible que los proveedores tecnológicos externos tengan que participar.

En cambio, un producto sencillo que construye un solo equipo y que depende de pocos servicios de terceros necesita mucho menos de este trabajo. En ese caso, unas buenas pruebas de integración y de sistema suelen cubrir el riesgo. Las pruebas de extremo a extremo, que siguen el recorrido real de un usuario por la aplicación de principio a fin, detectan después lo que esos dos niveles pasen por alto.

El lugar de las pruebas SIT en su estrategia de pruebas

Las SIT suelen llegar cerca del final de la secuencia de pruebas. El ISTQB describe cinco niveles de prueba, y la mayoría de los proyectos los ejecutan aproximadamente en este orden:

1. Pruebas de componentes: los desarrolladores comprueban cada pequeña pieza de código por separado.
2. Pruebas de integración de componentes: el mismo equipo confirma que esas piezas funcionan juntas.
3. Pruebas de sistema: probadores independientes comparan el producto completo con sus requisitos.
4. Pruebas de integración de sistemas: el equipo de pruebas verifica las conexiones del producto con sistemas externos.
5. Pruebas de aceptación: los usuarios de negocio confirman que el producto cubre sus necesidades.

En los proyectos reales, los niveles se solapan. Un equipo puede empezar a comprobar una conexión terminada mientras otras funciones siguen en pruebas de sistema, lo que saca a la luz antes los problemas con los socios. Aun así, el orden importa. Si su propio producto todavía tiene errores abiertos, una comprobación de conexión fallida podría apuntar a su código o al sistema del socio, y nadie sabría a cuál. La misma confusión también puede empezar en el otro lado. En Granola, un bloc de notas con IA, un inicio de sesión de Google poco fiable hacía fallar las pruebas automatizadas aunque la aplicación funcionara, así que creamos una herramienta interna y segura de inicio de sesión que mantuvo esos falsos fallos fuera de los resultados.

Criterios de entrada y salida: cuándo pueden empezar las SIT y cuándo terminan

Los criterios de entrada y salida establecen qué debe estar listo antes de que empiecen las pruebas SIT y qué se considera terminado. Acordar ambas listas desde el principio evita discusiones entre proveedores más adelante.

Las pruebas pueden empezar cuando:

• Las partes de su producto que intervienen en cada conexión han superado las pruebas de sistema, sin errores críticos abiertos.
• Cada socio ha facilitado un sandbox, una copia de prueba que se comporta como el servicio real.
• Existen registros de ejemplo coincidentes en todos los lados, por ejemplo el mismo cliente de prueba en su aplicación y en el banco.
• Cada propietario de sistema ha designado a una persona de contacto que pueda investigar los fallos en su lado.

El trabajo está terminado cuando:

• Se han probado todas las conexiones previstas, incluido lo que ocurre cuando un socio deja de estar disponible.
• No quedan errores abiertos de prioridad crítica o alta.
• El propietario de cada sistema ha dado su visto bueno a los resultados de su parte.

¿Cuáles son los cuatro enfoques de las pruebas SIT?

Todo proyecto de pruebas SIT tiene que decidir en qué orden se incorporan los sistemas. La secuencia influye en la rapidez con la que se descubren los problemas y en lo fácil que resulta rastrear cada fallo. Estos son los cuatro enfoques más utilizados:

• Big bang: todo se conecta a la vez y se prueba en conjunto. El enfoque sirve para configuraciones pequeñas, pero cada sistema añadido hace más difícil encontrar la causa de un fallo.
• Descendente (top-down): el equipo empieza por la aplicación con la que interactúan sus usuarios y añade uno a uno los servicios internos y de socios que hay detrás. Hasta que la siguiente pieza está lista, los probadores usan stubs, sustitutos sencillos que devuelven respuestas predefinidas.
• Ascendente (bottom-up): el trabajo empieza por los sistemas centrales del back-end, como el procesamiento de pagos y su base de datos principal, y avanza hacia lo que ve la gente. Hasta que se conectan las aplicaciones de cara al cliente, los probadores usan drivers, pequeños programas que envían las mismas peticiones que más tarde activarán las acciones de los usuarios.
• Sándwich: los equipos prueban desde arriba y desde abajo a la vez y se encuentran en el medio, algo adecuado para proyectos grandes en los que muchos grupos trabajan en paralelo.

En un proyecto con varios proveedores, las pruebas descendentes, ascendentes o sándwich suelen compensar, porque cada conexión nueva se comprueba por separado y así cada fallo tiene un origen evidente. La mayoría de los sistemas intercambian datos a través de interfaces de programación de aplicaciones (API). Una API es un conjunto fijo de peticiones que un programa puede enviar a otro, algo parecido a la carta de pedidos que acepta una cocina. Una vez que las conexiones son estables, las pruebas automatizadas de API pueden volver a ejecutar los escenarios clave después de cada versión.

Cómo ejecuta QAwerk las SIT entre equipos y proveedores

QAwerk se incorpora a las pruebas SIT como parte de un solo equipo con sus desarrolladores y proveedores. El primer paso es un mapa de todas las conexiones, que muestra el propietario de cada sistema y los datos que circulan por cada enlace. A continuación, acordamos con cada proveedor el acceso al sandbox, las cuentas de prueba y los datos de ejemplo que podemos usar. Después, nuestros ingenieros cubren el flujo normal y también los fallos, como un socio que responde con lentitud, envía datos erróneos o deja de estar disponible. Cada error va directamente al equipo que puede corregirlo, con las pruebas necesarias para reproducir el problema.

Los detalles cambian según los sistemas implicados. Por ejemplo, en Thirdfort, una aplicación regulada de verificación de identidad, probamos la verificación de documentos de identidad basada en los kits de desarrollo de Onfido y ReadID, junto con la vinculación de extractos bancarios que muestra el origen de los fondos de un cliente. Onfido también aparecía en ChitChat, una aplicación de mensajería para enviar dinero a amigos, pero allí el trabajo se centró en cómo la aplicación intercambiaba datos con ese servicio y con Primer, su proveedor de pagos. Arctype, en cambio, exigió otro tipo de trabajo de integración. Para esa aplicación, que los desarrolladores usan para consultar y gestionar bases de datos, probamos las conexiones con cinco sistemas de bases de datos: MySQL, PostgreSQL, SQLite, Yugabyte y PlanetScale.

Podemos incorporarnos antes de su primera integración con un socio o a mitad de un despliegue. Los ingenieros de QAwerk evaluarán el estado del proyecto, definirán el alcance y entregarán resultados aplicables desde el primer momento. ¿Listo para empezar las pruebas de integración de sistemas? Contáctenos hoy.

Preguntas frecuentes

¿Qué son las pruebas SIT?

Las pruebas SIT (pruebas de integración de sistemas) son la fase que comprueba un producto junto con los servicios externos conectados a él, como una pasarela de pago, un socio de envíos o la herramienta de contabilidad de una empresa. El objetivo es detectar los fallos que solo aparecen cuando sistemas construidos por separado intercambian información, por ejemplo un pedido que el software del almacén rechaza o un reembolso que nunca llega al cliente.

¿Las SIT van antes de la UAT?

Sí, las pruebas de integración de sistemas (SIT) normalmente terminan antes de las pruebas de aceptación de usuario (UAT), la última comprobación, en la que los usuarios de negocio deciden si el software se adapta a su trabajo diario. Esta secuencia protege su tiempo. Si las compras o los pagos siguen fallando entre sistemas conectados, los probadores de aceptación acaban registrando errores técnicos y no pueden valorar el flujo de trabajo en sí. Es habitual un breve solapamiento, pero los errores críticos de integración deben corregirse antes.

¿Cuál es la diferencia entre las SIT y las pruebas de sistema?

Las pruebas de sistema miran hacia dentro y comprueban que un producto completo cumple sus requisitos, a menudo con los servicios de los socios simulados. Las SIT, en cambio, miran hacia fuera y sustituyen esas simulaciones por los sistemas reales de los socios o por sandboxes realistas. Por ejemplo, el proceso de pago de una tienda online puede superar las pruebas de sistema con un servicio de pago ficticio y después fallar en las SIT porque el proveedor real espera los importes en céntimos mientras la tienda los envía en euros.

¿Quién realiza las pruebas de integración de sistemas?

Las pruebas SIT suelen dirigirlas probadores independientes, ya sea el propio equipo de QA de una empresa o un proveedor de QA externo, porque el trabajo abarca sistemas que no pertenecen a ningún desarrollador en concreto. Cada socio o equipo interno aporta una persona de contacto que concede el acceso de prueba e investiga los fallos en su lado. Los desarrolladores corrigen los errores encontrados en su código, y los usuarios de negocio se incorporan más tarde para las pruebas de aceptación.

¿Se pueden automatizar las SIT?

Las pruebas SIT se pueden automatizar en parte. Las comprobaciones estables y repetibles, como enviar un pago de ejemplo al sandbox de un proveedor y verificar la respuesta, pueden ejecutarse automáticamente después de cada versión. Los probadores manuales siguen siendo imprescindibles para las conexiones nuevas con socios, los escenarios de fallo poco habituales y los entornos de prueba que se comportan de forma distinta al servicio real. Un reparto habitual consiste en automatizar los flujos principales ya probados y explorar a mano todo lo nuevo.