Page Comparison

Objetivo  

Esta estrategia de pruebas tiene como objetivo principal establecer un enfoque claro para las pruebas automatizadas. En este sentido, se incluirán detalles sobre la estrategia de ejecución de las pruebas, el alcance de las mismas, los recursos requeridos, los ambientes de pruebas, las herramientas a utilizar y los supuestos pertinentes. Asimismo, se abordarán los posibles riesgos y se presentará un plan de mitigación correspondiente.  

Objetivos de las pruebas 

• Verificación de la funcionalidad: Asegurar que los servicios desarrollados por el equipo de DevTeam funcionen correctamente y cumplan con las especificaciones y requisitos definidos. Esto implica verificar que los endpoints respondan adecuadamente, devuelvan los datos esperados y ejecuten las acciones correspondientes. 

• Regresión y estabilidad: Confirmar que las modificaciones o actualizaciones en los servicios no hayan introducido errores o afectado funcionalidades previamente validadas. El objetivo es garantizar la estabilidad y consistencia de los servicios a lo largo del tiempo. 

• Integración y colaboración: Facilitar la integración y colaboración entre diferentes componentes de desarrollo. Las pruebas permiten que los equipos trabajen de manera independiente, validando la interoperabilidad y la comunicación adecuada entre las diferentes partes del sistema. 

• Ahorro de tiempo y recursos: Reducir el tiempo y los recursos necesarios al eliminar la necesidad de realizar pruebas manuales repetitivas. 

Estos objetivos se aplican a todos los componentes descritos en la arquitectura del proyecto Mirror Strategy, con el fin de prepararlos para su integración con la aplicación SPIN en un ambiente productivo o, en su defecto, en el ambiente que el equipo de Spin establezca. 

Pruebas Automatizadas 

El proceso de automatización de pruebas se llevará a cabo siguiendo los lineamientos, herramientas, nomenclaturas y estructuras definidos por el equipo de SPIN.  

...

Al seguir los lineamientos y estándares definidos por el cliente, nos aseguramos de que la automatización de pruebas se alinee con sus requerimientos y expectativas. Esto nos permite entregar resultados consistentes y relevantes que respalden la toma de decisiones informadas. 

Ciclo de ejecución de pruebas 

• PLANIFICACIÓN:  

Se establecerán los objetivos, se identificará el alcance y se elaborará una estrategia de pruebas que será presentada para la aprobación de Spin (Documento actual). 

...

Estos pasos se repiten hasta que se cumplan los criterios de finalización de las pruebas, como la satisfacción de los objetivos establecidos y la aprobación para pasar a la siguiente etapa del desarrollo o para lanzar el software al mercado. Es importante destacar que el ciclo de pruebas puede ser adaptado y ajustado según las necesidades y características específicas del proyecto. 

Generalidades 

Los templates, documentos y herramientas necesarias para cumplir con las actividades de prueba deberán ser proporcionados por el equipo de Spin. 

...

Durante el desarrollo de scripts automatizados, se tendrán en cuenta tanto escenarios individuales de cada servicio como escenarios integrales. Esto implica que se automatizarán pruebas específicas para cada uno de los servicios ofrecidos, así como pruebas que involucren la interacción y funcionalidad conjunta de varios servicios. 

Precondiciones para las actividades de prueba 

El documento de Especificación Funcional ha sido aprobado. 

...

Para el entorno de pruebas de SPIN, se cuentan con datos de prueba datos similares a los utilizados en producción. Estos datos estarán disponibles en el sistema antes de comenzar las pruebas funcionales. 

Alcance

...

de las pruebas

Funcionalidades a probar

• Account

  • Finnancial account aggregation service: Expone los servicios asociados al dominio de cuentas mediante REST/grpc. 

  • Account Mirror: Administra la información de bloqueos de cuenta manteniéndola sincronizada con el proveedor de servicios financieros. 

    • GET /accounts/details: Realiza una consulta al mirror repository para verificar el estado de bloqueo de una cuenta utilizando el número de cuenta proporcionado en la solicitud. Si la información se encuentra disponible en el mirror, se retorna dicha información. En caso contrario, se realiza una sincronización con el proveedor externo para obtener la información más reciente. A continuación, se retorna esa información al solicitante y, de manera asíncrona, se actualiza el mirror con los datos obtenidos. 

    • POST /accounts/block-code: Actualiza los bloqueos de la cuenta directamente hacia el proveedor externo, retorna la información correspondiente al solicitante y de forma asíncrona actualiza el mirror repository con la información obtenida. 

    • POST /accounts/sync: Realiza una sincronización de la información de la cuenta hacia el mirror repository o base de datos.  

  • Balance Mirror: Administra la información de saldos manteniéndola sincronizada con el proveedor de servicios financieros. 

    • GET /account/balance: Realiza una consulta al mirror repository para verificar el saldo de una cuenta utilizando el número de cuenta proporcionado en la solicitud. Si la información se encuentra disponible en el mirror, se devuelve dicha información. En caso contrario, se realiza una sincronización con el proveedor externo para obtener la información más reciente. A continuación, se retorna esa información al solicitante y, de manera asíncrona, se actualiza el mirror con los datos obtenidos. 

    • PUT transacción: Se envía la transacción directamente hacia el proveedor externo con los datos del request (sincronización incial con Fiserv), retorna la información correspondiente al solicitante y asíncronamente se actualiza la base de datos con el saldo que retornó la operación. 

    • PUT transacciónP2P:Se envía la transacción directamente hacia el proveedor externo con los datos del request (sincronización incial con Fiserv) conteniendo la información de la persona origen y destino, retorna la información correspondiente al solicitante y asíncronamente se actualiza la base de datos con el saldo que retornó la operación para la persona origen y destino. 

    • PUT frozen: Efectúa la “congelación” un saldo comprometido para una transacción, de tal manera que no pueda ser dispuesto para otras transacciones. Se envía la transacción directamente hacia el proveedor externo, retorna la información correspondiente al solicitante y asíncronamente se actualiza la base de datos con el saldo que retornó la operación. 

    • PUT sync: El webhook llama a este servicio para validar el saldo de la cuenta directamente hacia el proveedor externo, retorna la información correspondiente al solicitante y de forma asíncrona actualiza el mirror repository con la información obtenida.   

  • Account adapter/Fiserv account gateway: Encapsula los servicios relacionados con cuentas del proveedor traduciéndola a una interfaz común.  

    • Llamadas a Fiserv: 

      • /account/details 

      • /account/block-code 

      • /accounts/details 

      • /account/balance/details 

      • /account/FL-balance 

      • /account/FL-transferP2P 

      • /account/QRFL-balance 

      • /account/balance/details 

Tipos de pruebas

Entregables y actividades de prueba 

...