Las pruebas de integración entre 2 sistemas se van a definir en 2 fases, origen y destino, para poder probarlos independientemente y que los errores de uno no afecten a las pruebas de otro.

Se han definido una serie de precondiciones que deben estar cubiertas para poder llevar a cabo las pruebas, por lo que en tiempo de planificación se deben contemplar las tareas necesarias para que estas precondiciones estén ok en la fecha que se haya establecido para las pruebas, en caso contrario habrá que reagendar estas pruebas.

Las pruebas se ejecutarán desde las aplicaciones en sus entornos de preproducción, en adelante PRE, sin necesidad de alterar los mensajes manualmente puesto que se ha establecido un mecanismo para que los casos de error puedan ser probados.

Para la finalización con éxito de la certificación de los servicios a probar es altamente recomendable que los proveedores previamente ejecuten la batería de pruebas de integración en los entornos previos a PRE, preparados para tal efecto. Para cualquier duda o si necesitan soporte para la ejecución de las pruebas pueden ponerse en contacto con la OTI. Para poder tener un soporte y respuesta en tiempo adecuada se recomienda que las pruebas a realizar sean planificadas y notificadas a la OTI para poder organizar adecuadamente los trabajos.

Entornos 

  1. DES: Los proveedores pueden realizar sus pruebas de integración previas a PRE en el entorno de DES, que ya está preparado para estar conectado con los entornos de los proveedores, por lo que pueden pasar la batería de pruebas establecidas por la OTI para preparar sus desarrollos y hacer las modificaciones necesarias antes de generar el paquete de PRE. En este entorno se puede solicitar el soporte de la OTI si lo necesitan.
  2. PRE: La certificación de las pruebas de integración la realiza Gobernanza en el entorno de PRE de forma autónoma. Para ello necesitará un usuario de aplicación y el juego de datos que se solicitará al JP de la misma para poder lanzar mensajería desde la propia aplicación. De esta forma, en caso de pasar las pruebas, se garantiza que la aplicación que se está probando no va a tener problemas sintácticos en la transmisión de la información y se tiene preparado el escenario de cara a las pruebas funcionales. En caso de no pasar las pruebas supondrá un nuevo correctivo de la aplicación pero es algo que no debería ocurrir puesto que la batería de pruebas que Gobernanza pasará son las mismas que se le distribuye al proveedor para que las realice en sus entornos y en DES. Puede ser necesario soporte por parte del proveedor.
  3. PRO: Tras la certificación de las pruebas de integración en PRE y dada la inmutabilidad del paquete entre PRE y PRO se dan por cubiertas las pruebas de integración y se puede proceder a la validación funcional de PRO. En este entorno se puede solicitar el soporte de la OTI si lo necesitan para la validación funcional.

Pruebas de integración de los servicios de destino

Precondiciones

  1. El desarrollo esté terminado e instalado adecuadamente en el entorno de PRE, donde se va a realizar la batería de pruebas.
  2. URL, usuario y contraseña con permisos en la aplicación invocadora.
  3. Juego de datos para ejecutar las pruebas (identificadores como puede ser nuhsa). Se necesitan datos válidos e inválidos para las pruebas de error. Facilitado por el proveedor de la aplicación destino.
  4. Usuario y contraseña de Maco PRE para obtener en cualquier momento tickets válidos de la aplicación invocadora. Facilitado por el proveedor de la aplicación origen.
  5. Si es posible reproducir los errores 500 se facilitará por parte del proveedor de la aplicación destino el conjunto de datos necesario.

Proceso de pruebas

  1. Se ejecutará por parte de la OTI todas las pruebas definidas en la correspondiente página de pruebas de integración de Confluence en el entorno de PRE.
  2. Se registrará por parte de la OTI el resultado obtenido, en la correspondiente página de pruebas de integración de Confluence, con las evidencias (consultas realizadas y respuestas obtenidas), para que pueden ser reproducidas por el proveedor.
  3. La OTI comunicará a los interesados que las pruebas se han realizado y documentado.
  4. En el supuesto de que existan errores en las pruebas de integración, se esperará a las correcciones necesarias y a la comunicación por parte del sistema, empezando el proceso de nuevo desde el paso primero.

Postcondición

  1. Finalizadas las pruebas con éxito, los servicios validados pasan a estar certificados como que han pasado las pruebas de integración para esa versión del servicio, si hubiese algún desarrollo que implique algún cambio en uno de estos servicios se deben repetir las pruebas para los servicios afectados y recertificarlos para la nueva versión.

Pruebas de integración de las llamadas en origen

Precondiciones

  1. El desarrollo esté terminado e instalado adecuadamente en el entorno de PRE, donde se va a realizar la batería de pruebas.
  2. URL, usuario y contraseña con permisos en la aplicación invocadora.
  3. Juego de datos para ejecutar las pruebas (identificadores como puede ser nuhsa). La OTI, en caso de ser necesario, puede definir un conjunto de datos para probar los distintos casos de error. Por ejemplo, "para probar una llamada sin ticket ni firma para obtener las prescripciones se deberá consultar al NUHSA ANXXXXXXXXX".
  4. El sistema destino debe tener disponibles los servicios en PRE y estos servicios a su vez deben estar ya certificados.

Proceso de pruebas

  1. El responsable del desarrollo a verificar ejecutará en el sistema origen en su entorno de PRE todos los casos de pruebas definidos en la correspondiente página de pruebas de integración de Confluence y facilitará las evidencias (consultas realizadas y respuestas obtenidas) a la OTI.
  2. Se registrará por parte de la OTI el resultado obtenido, en la correspondiente página de pruebas de integración de Confluence, junto con las evidencias.
  3. En el supuesto de que desde la OTI se detecte que existan errores en las pruebas de integración de integración realizadas o falte algún caso de uso, se notificará, quedándose el proceso a la espera de las correcciones necesarias, empezando el proceso de nuevo desde el paso primero.

Postcondición

  1. Finalizadas las pruebas con éxito, los servicios validados pasan a estar certificados como que han pasado las pruebas de integración para esa versión del servicio, si hubiese algún desarrollo que implique algún cambio en uno de estos servicios se deben repetir las pruebas para los servicios afectados y recertificarlos para la nueva versión. 

Aplicaciones certificadas

Toda aplicación para poder dar servicio en el SAS debe haber pasado la certificación de la Oficina Técnica de Interoperabilidad. Esta certificación consiste en completar las pruebas de integración coordinadas por la OTI. Una vez obtenida la certificación en el listado de servicios concreto, esta aplicación puede implantar dichos servicios en otros centros del SAS sin necesidad de volver a repetir las pruebas de integración, aunque sí deben pasar pruebas funcionales.

  • Sin etiquetas