Menú

Una guía sencilla para las pruebas de interoperabilidad (con ejemplos)

simple guide interoperability testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Antes de comprender la técnica de 'Prueba de interoperabilidad' , Primero entendamos el término 'Interoperabilidad'.

La interoperabilidad es la capacidad de un sistema para interactuar con otro sistema. Esta interacción es entre 2 sistemas diferentes o 2 aplicaciones diferentes en conjunto.

Muchas veces la interoperabilidad se confunde con Integración , compatibilidad y portabilidad. Bueno, existen diferencias entre estas técnicas.

¿Qué son las pruebas de interoperabilidad?

Permítanme comenzar explicando las diferencias.

Integración - Es una técnica cuando los componentes de un mismo sistema interactúan entre sí. Entonces, en el mundo de las pruebas, cuando hacemos las pruebas de integración, en realidad estamos probando el comportamiento de los 2 o más niveles más bajos de componentes del mismo sistema.

Compatibilidad - Es una técnica mediante la cual 2 o más aplicaciones interactúan en el mismo entorno. Entonces, en el mundo de las pruebas, cuando hacemos pruebas de compatibilidad; validamos si 2 o más aplicaciones o sistemas se comportan como se espera en el mismo entorno.

La intención aquí es comprobar que los dos sistemas realizan sus tareas esperadas, sin interferir entre sí trabajando, en el mismo entorno. Me gusta: MS Word y Calculator son 2 aplicaciones diferentes y realizan su comportamiento esperado de forma independiente en el mismo sistema operativo. Entonces decimos que estas 2 aplicaciones son compatibles entre sí.

Portabilidad - Es una técnica cuando una aplicación o sistema se comporta como se esperaba cuando se traslada a otro entorno. Entonces en Portabilidad probando, exportamos la aplicación a algún otro entorno y probamos su comportamiento. Por ejemplo, si hay una aplicación que funciona bien en Windows XP, también debería funcionar bien en Windows 10.

Interoperabilidad - Es una técnica de cómo una aplicación interactúa con otra aplicación. Entonces, cuando hacemos las pruebas de interoperabilidad, verificamos cómo los datos de 1 aplicación se transfieren a otra aplicación sin previo aviso, de manera significativa, y se procesan posteriormente para dar el resultado aceptado.

Este artículo en particular se centra en las pruebas de interoperabilidad (IOT), así que mantengamos nuestro enfoque en la interoperabilidad. :)

Lo que vas a aprender:

Pruebas de interoperabilidad: una breve introducción

Interoperabilidad = Inter + operable

Enterrar - significa 'entre nosotros', 'entre nosotros', 'mutuo'

Operable - significa 'capaz de realizar la tarea dada'

Entonces, combinar los 2 términos juntos: interoperabilidad significa 2 (o más) sistemas, capaces de realizar su tarea asignada de forma independiente y capaces de comunicarse entre sí como se espera sin afectar su funcionalidad individual asignada.

Ejemplo 1:Tome un ejemplo de cómo reservar su vuelo. Considere que necesita viajar de Nueva Delhi a Nueva York. Ahora no tiene vuelo directo. Tienes que viajar de Nueva Delhi a Londres y luego tomar un vuelo de conexión de Londres a Nueva York. Debido a que tiene algunas limitaciones de tiempo, reserva su vuelo de Nueva Delhi a Londres en las vías aéreas 'Jet Airways' y de Londres a Nueva York en 'Virgin Atlantic'. Eso significa que todos los datos de sus pasajeros se traspasaron desde Jet Airways hasta Virgin Atlantic. Entonces, aquí, Jet Airways y Virgin Atlantic, ambas son aplicaciones independientes en conjunto y, al reservar su vuelo, los detalles de la reserva se intercambiaron de Jet Airways a Virgin Atlantic de manera completa, sin previo aviso.

Ejemplo # 2:En líneas similares, piense en el sistema de administración hospitalaria, donde los registros de los pacientes se intercambian entre un departamento y otro departamento. Así que aquí el departamento se puede vincular a una aplicación. Los datos del paciente se intercambian entre una aplicación y otra sin previo aviso.

Entonces, ¿por qué necesitamos hacer el IOT?

Necesitaríamos hacer las pruebas de interoperabilidad para asegurarnos de que

  • Las aplicaciones en la red realizan su comportamiento esperado de forma independiente,
  • Puede intercambiar información sin previo aviso
  • La información / datos se intercambian sin interrumpir el comportamiento individual esperado
  • Los datos / información que se intercambian no se modifican ni cambian

¿Cómo realizar las pruebas de interoperabilidad?

Podemos seguir la rueda de Deeming (el ciclo PDCA) para realizar las pruebas de interoperabilidad.

#1) Plan

La planificación es la fase más importante para determinar la estrategia de hacer casi cualquier cosa en el desarrollo de software. Antes de planificar realmente la determinación del procedimiento para realizar la IOT, es fundamental que comprendamos todas y cada una de las aplicaciones o sistemas implementados en la red.

Debemos conocer todas las aplicaciones: su funcionalidad, comportamiento, entrada que toma y salida que revela.

También recomendaría que todas y cada una de las aplicaciones se prueben completamente funcionalmente sin defectos, antes de prepararlas para las pruebas de interoperabilidad. Por lo tanto, cuando planifique, no solo piense en 1 o 2 aplicaciones, piense en todas las aplicaciones como una sola unidad. Necesita tener una vista de pájaro al planificar esta técnica de prueba. No hace falta decirlo: documente su plan.

Podemos usar nuestro documento de plan de prueba estándar y adaptarlo un poco según el requisito de documentar la planificación de IOT. Una vez que su plan de prueba esté en su lugar, siga adelante para derivar sus condiciones de prueba.

El enfoque de derivar su condición de prueba no debe limitarse a las aplicaciones individuales; en su lugar, debería basarse en el flujo de datos a través de todas las aplicaciones. Las condiciones deben diseñarse de tal manera que se atraviesen, si no todas, pero la mayoría de las aplicaciones de la red.

Una vez que se identifican las condiciones de prueba, continúe con el diseño o el script (en caso de que planee automatizar) sus casos de prueba. Usted puede crear un RTM (Matriz de trazabilidad de requisitos) para mapear sus casos de prueba con condiciones de prueba y sus condiciones de prueba con condiciones / requisitos de prueba de aceptación.

Cuando se trabaja en una red, también es importante planificar las actividades de pruebas no funcionales. Es posible que esto no esté escrito ni documentado en ninguna parte, pero es obligatorio verificar los aspectos no funcionales del sistema en su conjunto. Estas áreas no funcionales incluirían desempeño y seguridad. Si es necesario, puede crear un plan separado para pruebas funcionales, pruebas de rendimiento y pruebas de seguridad; o cree un plan único y un documento diferente de condiciones de prueba para cada uno de estos tipos de prueba.

# 2) Hacer

Hacer: es el lapso de tiempo en el que realmente realiza su ejecución. Planifique su tiempo en consecuencia para ejecutar las pruebas funcionales y no funcionales. Seguimos el ciclo de prueba en esta fase de ejecutar los casos, registrar los defectos, hacer un seguimiento con el equipo de desarrollo para resolverlos, hacer la prueba de re-prueba y la prueba de regresión del sistema en su conjunto, informar los resultados de la prueba y moverlo a cierre.

# 3) Comprobar

Verificar: es la fase en la que revisamos los resultados de nuestras pruebas e intentamos mapearlos con los RTM y validar si se cumplen todos los requisitos esperados y si se atraviesan todas las aplicaciones. Verificamos que los datos se atraviesen e intercambien correctamente y sin problemas entre las aplicaciones / sistemas. También necesitaríamos validar que los datos que se recorren no se modifiquen.

También considere hacer una retrospectiva de todo el proceso de pruebas de interoperabilidad. Identifique las áreas que funcionaron bien, las que no funcionaron bien y los puntos de acción que deben ser atendidos.

# 4) Actuar

Actuar: es actuar sobre los elementos retrospectivos. Los puntos que fueron identificados como “buenas prácticas”, continuar ejecutando aquellos y los puntos que se podrían trabajar mejor, identificar los pasos para subsanarlos y actuar en consecuencia. Tenga en cuenta una cosa que las áreas o pasos que no funcionaron bien, NO deben repetirse. Después de todo, debemos aprender de nuestros errores y no repetirlos.

Los 5 ½ pasos:

  1. Identifica todas las aplicaciones que forman parte de la red.
  2. Identificar sus respectivas funcionalidades.
  3. Para cada aplicación, identifique la entrada que toma y la salida que devuelve.
  4. Identifique los datos que atravesarían todas o la mayoría de las aplicaciones.
  5. Identificar el comportamiento esperado para cada combinación de aplicación y fecha que necesita validarse.

½ Documentelo.

Considere la siguiente figura:

5 ½ pasos

Según la figura, intentemos replicar los 5 ½ pasos:

  1. La Aplicación 1, la Aplicación 2, la Aplicación 3 y la Aplicación 4 son 4 sistemas diferentes.
  2. Cada uno de estos sistemas tiene un conjunto definido de funciones que es necesario identificar.
  3. Es necesario identificar las entradas y salidas de cada sistema.
  4. En el caso de Application1, genera 2 salidas. 1 salida forma la entrada de la Aplicación 3 y 1 salida forma la entrada de la Aplicación 2. La salida de la Aplicación 2 forma la entrada de la Aplicación 3 y la Aplicación 4 y así sucesivamente.
  5. Se comprueba la validez de cada una de las entradas y salidas. El punto principal a considerar aquí es que los datos que se atraviesan en forma de entrada y salida no se modifican Y toda la aplicación está cubierta.

½ Esta cifra en la vida real puede no parecer tan simple. En realidad, esto da como resultado una estructura más compleja con n números de condiciones de entrada y salida.

Dibujar este tipo de figura daría una mejor imagen para identificar los datos y la información que atravesarían diferentes sistemas. Esto nos ayudaría a derivar las condiciones y los casos de prueba.

Un ejemplo:

Consideremos un ejemplo de realización de pruebas de interoperabilidad para un 'Sistema de gestión hospitalaria'.

Un hospital consta de los siguientes departamentos y subdepartamentos;

Sistema de gestión hospitalaria

Aquí cada departamento es una aplicación en sí mismo. Cada departamento (aplicación) tiene su propio subdepartamento (módulos) y cada módulo tiene sus propias unidades.

Entonces, ahora para considerar el alcance de IOT, aquí hay algunas condiciones de prueba:

  1. Un paciente que sufrió un accidente de tráfico (Departamento OPD - Accidente), necesita someterse a una cirugía de pierna (ORL - Cirugía general), luego debe someterse a fisioterapia (Departamento de soporte - Fisioterapia) y luego es dado de alta (Departamento de soporte - Cierre)
  2. Un niño ingresado en cuidados intensivos (Pediatría - Cuidados intensivos) necesita someterse a una cirugía (Pediatría / ORL - Cirugía general) y luego es dado de alta (Departamento de apoyo - Cierre / PR)
  3. Un paciente externo consulta a un médico general (departamento de OPD); toma los medicamentos recetados (Departamento de Apoyo - Farmacia) y se marcha.
  4. Una mujer embarazada viene a chequeos regulares (departamento de ginecología - cuidado materno-infantil), toma la medicación prescrita (departamento de apoyo - farmacia) y se va.
  5. Un paciente dental hace el tratamiento de conducto (departamento de Odontología), toma la medicación prescrita (departamento de soporte - farmacia) y se aleja.
  6. Un paciente ingresa en OPD (médico general), se somete a un tratamiento en (Departamento de Obstetricia y Ginecología - Obstetricia de alto riesgo) toma la medicación prescrita (Departamento de soporte - Farmacia) y es dado de alta

De esta forma identificamos todas las condiciones de prueba; teniendo en cuenta que la mayor parte del departamento debe estar cubierto.

Podemos dibujar un RTM para mostrar la cobertura como:

RTM

De esta manera podemos identificar más condiciones de prueba y podemos dibujar el RTM para ver nuestro alcance exacto. También podemos determinar la profundidad de nuestros esfuerzos de prueba basados ​​en el RTM.

Como en este ejemplo, vemos que el 'Departamento de Soporte' es la aplicación que es el punto de salida para toda (la mayoría) de la aplicación, por lo tanto, el esfuerzo de prueba para esta aplicación en particular es un poco más en comparación con otra aplicación.

dónde ver anime gratis en línea

Desafíos:

  1. Difícil probar toda la aplicación con todas las permutaciones y combinaciones.
  2. Las aplicaciones se desarrollan en diferentes combinaciones de hardware / software y se instalan en diferentes entornos, por lo que si alguno de los entornos no funciona, afectará las pruebas.
  3. Debido a los diferentes entornos y software, determinar la estrategia de prueba y ejecutarla es en sí misma una gran tarea.
  4. Estimular el entorno para realizar la prueba, es un gran desafío.
  5. En caso de cualquier defecto, realizar el análisis de causa raíz es un gran desafío.
  6. Debido a que las aplicaciones están en una red, habrá ocasiones en las que la red no funcione. Debido a esto, las pruebas también se ven afectadas.

¿Cómo puedo mitigar estos desafíos?

1) Intente utilizar las técnicas de prueba avanzadas como:

  • OATS (técnica de prueba de matriz ortogonal)
  • Diagramas de transición de estado,
  • Gráficos de causa y efecto
  • Análisis de porciones de equivalencia y valor límite.

Estas técnicas le ayudarían a identificar la interdependencia entre la aplicación e identificar los casos / condiciones de prueba que garantizarían la máxima cobertura.

2) Intente identificar algunos datos históricos como: bajo qué circunstancias los sistemas no funcionaron, cuánto tiempo se necesita para volver a estar en acción. En ese caso, intente ejecutar aquellos escenarios cuyas aplicaciones no se vean afectadas, o utilice el tiempo para documentar los escenarios e informar los resultados. Además, siempre que planifique o programe la prueba, siempre considere estos datos históricos como una entrada para su estimación y planifique en consecuencia.

3) PLAN – Utilice datos históricos, experiencias pasadas, habilidad del equipo, factores ambientales para identificar la estrategia de la prueba. Cuanto mejor sea su plan, mejor será su ejecución.

4) Comience a trabajar en la preparación del entorno mucho antes de que comience su ejecución real. No hace falta decir que planifique sus pasos cuando esté preparando el entorno. Asegúrese de que su entorno esté todo configurado, listo y en funcionamiento cuando comience su ejecución.

5) Antes de comenzar con el IOT, asegúrese de que las aplicaciones individuales se prueben completamente funcionalmente sin defectos. Luego, en caso de cualquier defecto, solo necesitaría buscar los factores ambientales que han dado lugar a algún error.

6) Como se discutió en el punto 2, planifique su actividad. Si se trata de una interrupción programada, debe considerar este tiempo de inactividad cuando planifique sus pruebas.

Prueba de interoperabilidad en móviles:

En móviles, hacemos pruebas de interoperabilidad cada vez que una nueva aplicación ( Aplicación movil ) es lanzado. Hay muchas áreas que debemos considerar al planificar esta prueba en dispositivos móviles:

  • Los tipos de dispositivos móviles disponibles en el mercado son enormes. Debería enumerar todos los tipos de dispositivos que consideraría para sus pruebas. Debería emparejar un tipo de dispositivo junto con el sistema operativo que admite.
  • Todos los sistemas operativos móviles se desarrollan en diferentes lenguajes de programación. Por lo tanto, la aplicación debe probarse con todas las variaciones del sistema operativo.
  • Comprender los factores legales y los contratos relacionados con la región.
  • El tamaño / resolución de diferentes dispositivos es diferente.
  • También se debe considerar el impacto en las aplicaciones móviles integradas.

Entonces, para hacer IOT en móviles, necesitaría planificar y crear un RTM tal como lo hicimos para una prueba de aplicación basada en computadora.

La intención, la estrategia, los riesgos y la ejecución serían los mismos, pero la Herramientas y técnicas Sería diferente en el caso de los móviles.

Conclusión:

Las pruebas de interoperabilidad son una tarea enorme. Esta técnica requiere una planificación adecuada que debe comenzar en paralelo cuando se inicia la planificación de la prueba del sistema.

Hay muchos factores que deben tenerse en cuenta al ejecutar esta técnica. Tenga en cuenta que debe disponer de tiempo suficiente para corregir los errores y volver a realizar las pruebas, ya que este es un gran esfuerzo, por lo que debe preverse un seguimiento de los defectos.

Esto puede suceder que no alcance el 100% cobertura , pero deberíamos ser lo suficientemente inteligentes como para seleccionar nuestros casos de tal manera que la mayoría de las aplicaciones se cubran en un solo flujo mediante el uso de buenas técnicas de escritura de casos de prueba.

Espero que este artículo haya sido útil para comprender la técnica de prueba de interoperabilidad. Háganos saber sus consultas / comentarios.

Lectura recomendada

^