Page Comparison

Objetivo  

...

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 POST → /v1/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 → /v1/accounts/block-codeblocks : 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 → /v1/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 POST → /accountv1/balancebalances: 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→ /v1/balances/transfers: 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→ /v1/balances/transfers-p2p: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→ /v1/balances/transfers-qrfl: 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 syncPOST → /v1/balances/syncs: 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 

• Card

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

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

    • GET /cards/embosser/details 

    • POST /cards/embosser/block 

    • POST /cards/activation 

    • PUT/cards/account 

    • GET /cards/account 

  • Card adapter/Fiserv card gateway: Encapsula los servicios relacionados con tarjetas del proveedor traduciéndola a una interfaz común. 

    • /cards/embosser 

    • /card/embosser/block 

    • /cards/activation 

    • /account/prepaid 

    • /account/balance/details 

    • /cards/embosser/details 

Niveles de pruebas

Pruebas de integración de componentes (Equipo QA Palo):

...

Estas pruebas se enfocan en garantizar el correcto funcionamiento y comunicación de diversos sistemas, paquetes y microservicios. Su objetivo principal es verificar que estos componentes interactúen de manera adecuada, intercambiando datos de forma correcta y trabajando en conjunto según los requisitos establecidos. Estas pruebas son fundamentales para asegurar la interoperabilidad y la comunicación efectiva entre los diferentes elementos involucrados.

Tipos de pruebas

Pruebas funcionales:

Estas pruebas se enfocarán en verificar si el software cumple con los requisitos y funcionalidades establecidas. Durante estas pruebas, se evaluará el comportamiento del sistema frente a diferentes escenarios y se verifica si produce los resultados esperados. Se exploran las diferentes funcionalidades, se ingresan datos de prueba y se comprueba la respuesta y el comportamiento del sistema.

...

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). 

• DISEÑO DE CASOS DE PRUEBA:  

Los artefactos base para esta actividad serán proporcionados por el equipo de Spin y una vez se cuente con la documentación de especificación de requerimientos necesaria se definirán los escenarios de prueba para evaluar el sistema, determinando que aspectos se probarán, los datos de prueba y los resultados esperados. 

• DESARROLLO DE SCRIPTS:  

Una vezobtenido el visto bueno del diseño de los casos de prueba, se procederá al desarrollo de scripts automatizados según lo establecido en la sección de Pruebas automatizadas. 

Concluidos los scripts, se iniciará el ciclo de ejecución de pruebas de los servicios a medida que vayan concluyendo su desarrollo.  

• ESTRATEGIA DE EJECUCIÓN:   

En cada sprint, se realizará la ejecución del ciclo 1 y se llevará a cabo una validación, en caso de que se encuentren fallos se procederá a realizar la validación del ciclo 2, y así sucesivamente, hasta lograr una ejecución satisfactoria. 

Durante las pruebas, se buscará identificar, corregir y volver a probar todos los defectos de alta y media gravedad, siguiendo los criterios de entrada establecidos. Además, se dará prioridad a la ejecución y verificación de los casos de prueba automatizados para los defectos de menor gravedad, con el fin de prepararlos para su corrección futura según los lineamientos de gestión y seguimiento de defectos. 

• ANÁLISIS DE RESULTADOS:   

Al finalizar la ejecución se hará una evaluación de los resultados y se llevará a cabo un reporte con los hallazgos. En caso de que se detecten comportamientos no esperados o deseados, se reportarán los incidentes de acuerdo con los lineamientos de Spin. 

• CORRECCIÓN DE DEFECTOS:   

Los problemas o defectos identificados durante las pruebas se informan al equipo de desarrollo para su corrección. Se realiza un seguimiento de los problemas corregidos y se realiza una nueva ejecución de pruebas para verificar que se hayan solucionado adecuadamente. 

• RETESTING: 

Después de que se hayan realizado las correcciones, se ejecutan nuevamente las pruebas para asegurarse de que los problemas se hayan resuelto y que no se hayan introducido nuevos errores. 

...