Pruebas de Integración de Productos: Un enfoque práctico

Normalmente un producto de software tiene sus procesos de pruebas de integración para verificar que los
módulos o componentes que lo conforman funcionan correctamente en conjunto o integrados.

1. PRUEBAS DE INTEGRACION

Las pruebas de integración en los proyectos de desarrollo de software, no solo se presentan en la integración entre
módulos de un mismo producto sino que se están planteando proyectos que ofrecen soluciones conformadas por
varios productos de software, lo cual le da una nueva dimensión al proceso de pruebas de integración. Estas
corresponden a las pruebas de integración entre productos, en el cual podríamos considerar los productos como
componentes más grandes, sin embargo existen características que las hacen particulares considerando que son
productos construidos por empresas diferentes y que obedecen a estándares de construcción diferentes, en as
más diversas plataformas (Figura 1). Para el proceso de pruebas de integración se han establecido los
siguientes aspectos:

1. Identificar las aplicaciones que forman parte de la solución y su participación en el proceso, es decir la función
de la aplicación dentro de la solución. Cada una de las aplicaciones debe estar certificada funcionalmente, es
decir haber concluido los procesos de pruebas funcionales. Es requisito que las aplicaciones hayan finalizado su
proceso de pruebas funcionales o al menos hayan logrado un alto nivel de estabilidad ya que si esto no
se cumple, durante la ejecución de las pruebas de integración es más difícil establecer la procedencia
de las no conformidades identificadas lo que ocasiona desperdicio de tiempo del equipo de trabajo
intentando localizar su procedencia.
2. Identificar la forma de acceso e invocación de cada una de las aplicaciones o componentes de la
solución, para esto se definen estándares que describen la manera de acceder a las aplicaciones y la
ubicación dentro de la pantalla de los puntos de acceso.
3. Validar los estándares de presentación de la solución. Cada una de las aplicaciones deben cumplir
con estos estándares, los cuales son definidos por el cliente y normalmente corresponden a la imagen
que quiere proyectar. Estos estándares son variables de acuerdo con el cliente, si bien son aspectos que se
validan en las pruebas de unidad, como se plantean para un proyecto de integración que varía de cliente en
cliente y para un producto terminado estas pruebas se ejecutan como parte de las pruebas de integración.
4. Identificar la interacción entre las aplicaciones, es decir cuales aplicaciones requieren interacción y que
mecanismo usará para hacerla. Está interacción se define desde dos puntos de vista:
• Sincronización de Datos.
• Integración Funcional.

Para llevar a cabo adecuadamente estos procesos se requiere:

• Especificar si en la integración se construirá un repositorio central de datos.

• Especificar los mecanismos de comunicación entre las aplicaciones.

En lo posible no se debe realizar interacción directa entre cada par de aplicaciones ya que dependiendo
del número de productos que participen, aumenta la complejidad del mantenimiento de la solución. Es
recomendable el uso de uno o más mediadores que permita estandarizar el mecanismo de integración.

5. Identificar el mecanismo de autenticación en las aplicaciones. Debe ser un mecanismo unificado para la
solución. A pesar de que son varias aplicaciones, la autenticación de usuarios debe realizarse una vez.
6. La administración de usuarios debe realizarse desde una de las aplicaciones y debe ser replicado en forma
automática en las demás aplicaciones.
7. Para facilitar el proceso de integración se usa un repositorio central de datos que comparte información entre
diferentes aplicaciones. El repositorio central de datos debe validarse de acuerdo con la estructura de las fuentes
que lo alimentan.

Material de Estudio (2ª Unidad) - Aci-554

8. Se debe disponer de una herramienta que permita realizar consultas y reportes sobre el repositorio central.
9. En caso que existan aplicaciones con buscador, este se debe centralizar, es decir definir un buscador sobre el
cual se registran los demás buscadores existentes de la aplicación.
10. Validación del cumplimiento de los requerimientos del ambiente de pruebas Integrado. Las versiones del
software base de las aplicaciones puede ser muy variado. El ambiente de pruebas debe corresponder al
definido por el arquitecto de la solución y se debe verificar que no existan conflictos entre los productos y
versiones requeridos para el funcionamiento de cada uno de los productos que integra la solución.
11. Establecer si la solución incluye un instalador único o múltiples instaladores, dependiendo de la
complejidad de la solución y del número de aplicaciones que componen la solución, así como la
diversidad de software base.
12. La documentación de las soluciones debe tener una apariencia unificada.

Figura 1. Integración de Productos para ofrecer Solución al cliente.

Para garantizar la estabilidad de la aplicación y el cumplimiento de los requerimientos

propuestos se plantean las siguientes pruebas :

Look & Feel

A partir de los estándares de presentación definidos sedefinen los requerimientos

de pruebas genéricos que se validan en cada una de las aplicaciones que componen la
solución. Se lleva registro de los requerimientos ejecutados y los hallazgos obtenidos. En caso que
alguno de los requerimientos no aplique sobre alguno de los productos también se deja registro
de ello, describiendo las razones por las cuales no se considera dentro del producto.

Autenticación Unica de Usuarios

Se valida el registro de los usuarios a la solución, la conexión se realiza una vez y este debe ser
reconocido en cada una de las aplicaciones de la solución, sin que se solicite nuevamente login y
usuario al invocar la ejecución de alguna de ellas. Se debe verificar que los accesos del
usuario en cada aplicación corresponden a los definidos en cada producto de la solución.

Administración de Usuarios

Se validan los requerimientos de administración de usuarios (creación de usuarios,

modificación de datos, cambio de password, eliminación de usuarios, activación y desactivación
de usuarios).Esta función normalmente se implementa a través del mediador.

Material de Estudio (2ª Unidad) - Aci-554

 Operación en Ambiente Integrado

Consiste en validar que cada producto funciona adecuadamente en la plataforma definida

para la solución, sin que exista conflicto entre el software base instalado e incluso entre las
mismas aplicaciones. Para realizar esta validación se realiza la selección de los procesos que se
ejecutarán en el ambiente integrado, los cuales no cubren la totalidad de los procesos de la
aplicación, sino aquellos de mayor relevancia de acuerdo con el alcance del producto. Esta
selección se enfocará en los requerimientos positivos. Se deja a criterio del ingeniero de pruebas la
selección de requerimientos negativos si lo considera necesario.

Búsqueda Unificada

Se validan que a partir de un buscador central se tenga acceso a los buscadores de las
demás aplicaciones. Se debe establecer cuales de las aplicaciones tienen buscador y se valida
que exista compatibilidad entre los parámetros de búsqueda y que los resultados sean correctos y
completos.

Repositorio Central de Datos

Se realiza validación de la estructura del repositorio central de datos para garantizar que no
exista conflicto con los tipos de datos y longitudes de los mismos. El repositorio debe tener en
cuenta la estructura de los datos fuentes y destinos para garantizar su correcta operación. Además,
debe considerar que los destinos pueden ser múltiples aplicaciones.

Visualizador del repositorio central de datos

El repositorio central de datos varía de proyecto en proyecto, por lo cual se requiere validar que se
puedan realizar consultas y reportes sobre este.

Sincronización de Datos

Se refiere a la definición de datos comunes entre las aplicaciones, tales como las ubicaciones o
zonas geográficas. Es información que maneja más de una aplicación y que debe permanecer
sincronizada, por lo que se define una fuente, los destinos y un mecanismo de sincronización para
cada destino, que podría ser por equivalencias u homologación. Las pruebas van orientadas a
realizar validación de la sincronización de datos, es decir que la replicación de los datos básicos
comunes entre aplicaciones se cumpla adecuadamente. Los mecanismos empleados son muy variados
y van desde APIs hasta mediadores que permiten configuración flexible de la información.

Integración Funcional

Se validan la sincronización a nivel de procesos, es decir la interacción entre los productos a partir de la
ejecución de procesos y la transferencia de información a otros procesos.
Se deben identificar los procesos de las aplicaciones que interactúan y el mecanismo de
intercambio de información. Este puede realizarse a través de interfaces directas entre
aplicaciones o mediante el uso de herramientas altamente configurables que actúan como
mediadores.
Instalador

En caso que se construya un instalador único para la aplicación, se debe validar

el correcto funcionamiento de este, es decir que realice la instalación de los productos de

Material de Estudio (2ª Unidad) - Aci-554

 software que componen la solución y el software adicional requerido para su adecuada
operación. Adicionalmente, se debe validar que
el instalador maneje situaciones de excepción.

Documentación en Línea

Se realiza la validación de la documentación en línea de acuerdo con los siguientes aspectos:

- Look & Feel de la aplicación
- Inclusión de funcionalidades relacionadas con integración.
- Eliminación de funcionalidades debido a la integración.

PRUEBAS NO FUNCIONALES

Adicionalmente, dependiendo de las características de la solución se pueden requerir la ejecución de

pruebas No Funcionales tales como:

• Pruebas de desempeño (carga)

• Pruebas de Resistencia (stress)
• Pruebas de Seguridad
• Pruebas de Rendimiento
• Pruebas de Volumen
• Pruebas de Concurrencia

Material de Estudio (2ª Unidad) - Aci-554

 2. EQUIPO DE PRUEBAS

El equipo de pruebas involucrado en las pruebas de integración es el siguiente:

• Coordinador de Proyectos: Responsable de asegurar la asignación de recursos para el

cumplimiento del plan de pruebas de integración.
• Líder de Proyecto: Responsable del proceso de pruebas de la solución.
• Lider de Componente : Un componente agrupa varios productos cuyas funcionalidades se
relacionan. El líder de componente es responsable del proceso de pruebas de integración
entre las aplicaciones que conforman su componente.
• Especialista Componente: Actua como consultor del líder de componente y como apoyo al
proceso de pruebas de integración.
• Líder de Producto: Responsable del proceso de pruebas funcionales de su producto y la
integración de este con otros productos.

Además, cada líder de producto es responsable de validar el cumplimiento del proceso de pruebas
para cada uno de los aspectos de integración. Y para cada aspecto se asigna un líder que responde por
el proceso completo dentro de la solución.

Líder SQA Look and Feel

Aspecto

Líder SQA
Aplicación A

Líder SQA
Aplicación B

Material de Estudio (2ª Unidad) - Aci-554

 Aplicación C Líder SQA

Material de Estudio (2ª Unidad) - Aci-554

 3. METODOLOGÍA DE PRUEBAS

Para la realización de las pruebas de integración, se utiliza una metodología de pruebas

propias, la cual tiene como etapas: Planeación, Análisis, Diseño y construcción de instrumentos,
ejecución de pruebas, control y seguimiento, análisis de resultados y retroalimentación.
Se construye una matriz de descomposición funcional para el proyecto de integración, en
la cual se relacionan todos los procesos relevantes para la integración y a la
cual se asociarán las matrices de requerimientos de cada proceso de integración.

Una vez identicazos los aspectos relevantes de la integración se realiza la construcción de

matrices de requerimientos de pruebas. Inicialmente se construyen matrices genéricas que son
aplicadas sobre cada uno de los productos y se generan las particularidades requeridas. Por
ejemplo, una vez definido el diseño gráfico de la aplicación se debe validar en cada una de
las aplicaciones que componen la aplicación, con base e la información de los estándares
gráficos se construye una matriz genérica, la cual contiene los requerimiento derivados del
diseño. Sobre esta matriz es posible que haya que registrar las características particulares de
cada aplicación, para lo que se genera una matriz particular.

Como estas matrices se deben aplicar sobre cada producto de la solución, es el líder
de SQA responsable del producto quién se encarga de realizar las pruebas del aspecto
respectivo. Por lo que un aspecto, por ejemplo Look and Feel puede ser validado por
ingenieros de SQA diferentes en cada una de las aplicaciones.

Existen procesos para los cuales no se requieren matrices particulares por cada aplicación, sino
que se genera una única matriz para toda la solución, por lo cual se asigna a un único
responsable para el proceso de pruebas.

Se construirán matrices genéricas de integración para la autenticación de usuarios,

administración de usuarios y buscador.

Los instrumentos para prueba para verificación de la operación en ambiente integrado se

hace de la siguiente manera:

- Se construiye una matriz DF que incluiye una selección de los procesos que se validan. En
esta Matriz DF se hace una aclaración que indica que los procesos corresponden a un
subconjunto de las funcionalidades del producto.
- Se selecciona un subconjunto de requerimientos de pruebas para validar los procesos en
el ambiente integrado.Esta selección se enfocará en los requerimientos positivos.Se deja
a criterio del líder de pruebas la selección de requerimientos negativos si lo considera
necesario.

Para las pruebas de integración funcional, el líder de pruebas de integración elabora

un inventario de pruebas para los procesos. Con base en estos procesos el líder de pruebas
de la aplicación a partir de
la cual se origina el proceso construye los instrumentos requeridos para las pruebas
funcionales y en colaboración con los líderes de las aplicaciones destino ejecutan
las pruebas. El responsable del proceso es el líder de pruebas de la aplicación que inicia
el proceso de integración funcional.

Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet. 7

 4. REPORTE DE HALLAZGOS

El reporte de No Conformidades identificadas durante el proceso de pruebas de integración

se hace teniendo en cuenta las siguientes consideraciones:

 Es importante identificar a que proceso corresponde la no conformidad, si corresponde a las

pruebas integración o funcional. En caso que corresponda a una no conformidad funcional se
reporta al correspondiente producto base. Las no conformidades de integración, se reportan a la
integración.
 Para cada uno de los productos creados se crea un componente que corresponde a cada uno de
los aspectos a considerar en las pruebas de integración los cuales corresponden a:
• Invocación de Aplicaciones
• Look and Feel
• Autenticación de Usuarios
• Administración de Usuarios
• Buscador
• Sincronización de Datos
• Integración Funcional
• Repositorio de Datos
• Instalador
• Documentación

Por ejemplo, en caso que las No Conformidades correspondan a la configuración

para la sincronización de datos, estas serán reportadas a la sincronización de datos. En
caso que las No conformidades correspondan a la estructura del repositorio, serán
reportadas al componente Repositorio.

 Al identificar una no conformidad durante el proceso de pruebas, el ingeniero de pruebas debe

identificar la procedencia, es decir cual es la aplicación que genera la no conformidad para que
sea reportada a ella. Si no se identifica claramente la procedencia se puede perder tiempo
valioso intentando establecer su origen.
 Las no conformidades se asignan al líder de desarrollo de cada producto que participa en la solución.

Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet. 8

 5. PLATAFORMA DE PRUEBAS

De acuerdo con los requerimientos técnicos de cada uno de los productos que componen la solución, se
define el ambiente de la solución y los mecanismos que se usarán para realizar la integración, esto lo
realiza el arquitecto de la solución.

Dado la diversidad de las plataformas sobre las cuales se implementan los productos, es posible que
el ambiente de integración esté formado por una gran variedad de software y diferentes versiones de los
mismos.
Una vez implementado el ambiente de pruebas, se debe realizar la validación del ambiente de pruebas para
garantizar que corresponde al definido.
Las versiones de producto no pueden ser alteradas sin la autorización de líder de pruebas de la
solución y con la previa aprobación del arquitecto de la solución. En caso de modificaciones en las
versiones del software base se debe analizar el impacto de estas en el proceso de pruebas.

6. METRICAS DE INTEGRACION

Cada proyecto requerirá unas métricas particulares dependiendo de las características de la solución
y lo que se necesite medir. Sin embargo, a nivel general se plantean los siguientes indicadores de
integración:

1. Número total de No Conformidades por aspecto (Look & Feel, Integración

funcional, sincronización de datos, etc) y por severidad.
2. Número total de No Conformidades correspondientes al proceso funcional e
identificadas durante el proceso de pruebas de integración.
3. Desviación de tiempos reales versus tiempos estimados en la planeación de pruebas.
4. Total de Horas Hombres invertidas en las actividades de pruebas.
5. Total de Horas Hombres invertidas por aspecto, por producto y por solución.
6. Tiempos promedios de solución de no conformidades por parte del equipo de
desarrollo.
7. Tiempos promedios de validación de no conformidades.
8. Tiempos totales de regresión, es decir el tiempo invertido en pruebas de regresión.
9. Tiempos Promedios de Pruebas de integración por proyecto.
10. Nro de No conformidades por proyecto versus número de productos involucrados en
la solución.

Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet. 9