Objetivo
...
Establecer una guía detallada de las actividades de prueba a desarrollar en el proyecto Spin – Mirror Strategy. Esta guía proporcionará información completa sobre los objetivos y la estrategia de prueba, así como el alcance del proyecto, recursos necesarios, entornos de prueba, herramientas a utilizar, actividades planificadas y plazos asociados a las pruebas. Además, se analizarán los posibles riesgos y se presentará un plan de mitigación correspondiente.
Objetivos de las pruebas
Garantizar el correcto funcionamiento y rendimiento de tres servicios que encapsulan las operaciones del proveedor de servicios financieros. Estos servicios están diseñados para dirigir las llamadas a una base de datos local, evitando así la necesidad de comunicarse con el proveedor a menos que sea estrictamente necesario.
Para cada servicio nos enfocaremos en alcanzar los siguientes objetivos:
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.
Identificar defectos o errores: Detectar y reportar defectos o errores en el producto. Al identificar estos defectos, se puede tomar acción para corregirlos y mejorar el producto.
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, Esto 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.
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
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.
...
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.
...
.
...
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 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
...
Entregables y actividades de prueba
...