Estrategia de Pruebas – Mirror Strategy
- Giselle Olvera (Unlicensed)
- Ángeles Díaz (Unlicensed)
- Héctor Villa (Unlicensed)
- Judith Medina Ruiz (Unlicensed)
Introducción
El contar con una estrategia de pruebas bien pensada es crucial para entender el alcance general del proyecto, y qué enfoques, herramientas y habilidades de pruebas se requieren para desarrollar un exitoso mirror strategy en su funcionamiento interno y sus componentes.
Índice
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 descritos como consideraciones describiendo la situación y recomendación de mitigación según corresponda.
Estrategia de pruebas
Objetivos de las pruebas
Garantizar el correcto funcionamiento 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 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, 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.
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.
Generalidades
Pruebas automatizadas
Los templates, documentos y herramientas necesarias para cumplir con las actividades de prueba deberán ser proporcionados por el equipo de Spin.
Las pruebas exploratorias se llevarán a cabo como primera instancia una vez que el equipo de desarrollo haya terminado el desarrollo del servicio/componente y haya notificado al equipo de pruebas.
Todos los defectos serán reportados en Jira utilizando el template indicado por el equipo de Spin.
El equipo de pruebas tendrá acceso al entorno de pruebas a través de una conexión VPN.
El equipo de pruebas asume que el equipo de Desarrollo de PALO-IT proporcionará todas las entradas necesarias requeridas durante el diseño y la ejecución de las pruebas.
Todas las actividades de prueba dentro del ciclo de desarrollo serán realizadas por el equipo de QA.
El equipo de desarrollo proporcionará planes de corrección de defectos basados en las reuniones de defectos durante cada ciclo de planificación. Esta información se compartirá con el equipo de pruebas antes de iniciar los ciclos de corrección de defectos.
Cualquier corrección de defectos planificada se compartirá con el equipo de pruebas antes de aplicar las correcciones en el ambiente de QA.
Durante las pruebas, no se permitirá tiempo de inactividad en el entorno debido a interrupciones o correcciones de defectos.
El sistema se considerará como una caja negra. Si la información se muestra correctamente en los servicios y en los informes, se asumirá que el proceso funciona correctamente.
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.
Pruebas performance
Los templates, documentos y herramientas necesarias para cumplir con las actividades de prueba deberán ser proporcionados por el equipo de Spin.
Todos los hallazgos serán reportados en Jira utilizando el template indicado por el equipo de Spin.
El equipo de pruebas tendrá acceso al entorno de pruebas a través de una conexión VPN.
El equipo de pruebas asume que el equipo de Desarrollo de PALO-IT proporcionará todas las entradas necesarias requeridas durante el diseño y la ejecución de las pruebas.
Todas las actividades de prueba dentro del ciclo de desarrollo serán realizadas por el equipo de QA.
El equipo de desarrollo proporcionará planes de corrección de defectos basados en las reuniones de defectos durante cada ciclo de planificación. Esta información se compartirá con el equipo de pruebas antes de iniciar los ciclos de corrección de defectos.
Cualquier corrección de defectos planificada se compartirá con el equipo de pruebas antes de aplicar las correcciones en el ambiente de QA.
Durante las pruebas, no se permitirá tiempo de inactividad en el entorno debido a interrupciones o correcciones de defectos.
El sistema se considerará como una caja negra. Si la información se muestra correctamente en los servicios y en los informes, se asumirá que el proceso funciona correctamente.
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
Pruebas automatizadas
El documento de Especificación Funcional ha sido aprobado.
Se cuenta con los documentos de historias de usuario y especificación antes de iniciar la fase de diseño de pruebas.
El desarrollo del sistema ha sido completado de acuerdo con el alcance del sprint, se han realizado pruebas unitarias con un porcentaje de aprobación establecido por la herramienta de análisis de código estático. Los resultados de estas pruebas han sido compartidos con el equipo de pruebas para evitar duplicación de escenarios de prueba y defectos.
El entorno de pruebas ha sido configurado con los servicios desplegados y está listo para su uso.
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.
Pruebas performance
La documentación proporcionada por nuestro equipo técnico nos muestra:
Los consumos, tiempos, usuarios realizados por cada endpoint referentes al mes de abril que con base a ello se analizo para determinar las peticiones a realizar por cada prueba.
El entorno de pruebas ha sido configurado con los servicios desplegados y está listo para su uso.
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.
Ciclo de ejecución de pruebas
01 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).
02 Diseño de casos de pruebas
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.
03 Creación de scripts
Una vez obtenido 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.
04 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.
05 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.
06 Corecció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.
07 Re testing
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.
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.
Alcance de las pruebas
A continuación se enlistarán las funcinalidades que se probarán para el proyecto de Mirror Strategy:
Funcionalidades a probar
Componentes Mirror Strategy
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.
Balance Mirror:
Administra la información de saldos manteniéndola sincronizada con el proveedor de servicios financieros.
Método → Path | Descripción |
|---|---|
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/blocks | 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 desde Fiserv hacia el repositorio espejo o base de datos, a través del adaptador. Este proceso se activa cuando ocurren cambios debido a transacciones realizadas fuera de Spin, y Fiserv envía una notificación de dicho cambio. El propósito es almacenar la información actualizada en el repositorio espejo. |
Método → Path | Descripción |
|---|---|
POST → /v1/balances | 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 → /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 → /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 → /v1/balances/transfers-qr | 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. |
POST → /v1/balances/syncs | El servicio de webhook invoca esta funcionalidad para validar el saldo de la cuenta directamente con el proveedor externo. Luego, devuelve la información correspondiente al solicitante de forma asíncrona y, al mismo tiempo, actualiza el repositorio espejo con los datos obtenidos. De esta manera, se garantiza la sincronización y actualización oportuna del mirror repository en relación a la información de la cuenta. |
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/QR-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.
Método → Path | Descripción |
|---|---|
POST → /v1/cards/embossers/details | Realiza una consulta al mirror repository para consultar la información de la tarjeta. 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/cards/embossers/blocks | Actualiza los bloqueos de la tarjeta 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/cards/account | Vincular una tarjeta con un número de tarjeta |
PUT → /v1/cards/account | Desvincular una tarjeta con un número de tarjeta |
Card adapter/Fiserv card gateway:
Encapsula los servicios relacionados con tarjetas del proveedor traduciéndola a una interfaz común.
Llamadas a Fiserv:
/card/embosser/block
/cards/activation
/account/prepaid
/cards/embosser/details
Customer
Finnancial customer aggregation service:
Expone los servicios asociados al dominio de clientes mediante REST/grpc.
Método → Path | Descripción |
|---|---|
POST → /v1/customers | Crea un nuevo registro de cliente en Fiserv. Enviando sus datos personales en el cuerpo del request para que se pueda crear un perfil de cliente único. Esta comunicación es directa de aggregation a gateway. |
PUT → /v1/customers | Actualiza la información de un cliente previamente creado. Esta comunicación es directa de aggregation a gateway. |
PUT → /v1/customers/account | Vincula a un cliente en la cuenta de Spin. Esta comunicación es directa de aggregation a gateway. |
Customer adapter/Fiserv customer gateway:
Encapsula los servicios relacionados los clientes en el proveedor traduciéndola a una interfaz común.
Llamadas a Fiserv:
/customer
/customer
/account/customer
Alcance por tipo de prueba
Pruebas automatizadas:
Account Aggregation (RESY y gRPC)
Card Aggregation (REST)
Customer Aggregation (REST y gRPC)
Pruebas de performance:
Account Aggregation (RESY y gRPC)
Card Aggregation (REST)
Customer Aggregation (REST y gRPC)
Pruebas a ejecutar
Niveles de pruebas
Pruebas de integración de componentes (Equipo QA Palo)
Estas pruebas se enfocan en verificar la comunicación, interoperabilidad y comportamiento general del sistema. Se aseguran de que los componentes estén conectados correctamente, los datos se transmitan sin problemas y el sistema funcione según los requisitos establecidos. Se comprueba la integración fluida de APIs, bases de datos y otros servicios, se identifican posibles errores en el flujo de datos y se verifica el cumplimiento de las expectativas establecidas.
Pruebas de integración de sistemas (Equipo QA Palo y QA Spin)
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 / automatizadas
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.
Se realizará la automatización de Pruebas bajo el framework definido por SPIN.
El equipo de pruebas realizará la automatización para poderse ejecutar en ambientes previos a producción.
El equipo de pruebas realizará la automatización para escenarios individuales de cada servicio y de escenarios integrales.
Se documentara el como poder desarrollar mas escenarios de prueba en caso de requerirlos, esta documentación contemplara REST y gRPC, ambas automatizaciones bajo los lineamientos y framework de SPIN. Dicha dicha documentación podrá consultarse en el KT de Automatización https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2496430085/Transferencia+de+conocimiento+-+Mirror+Strategy#Plan-y-ejecuci%C3%B3n-de-pruebas
Alcance
Ejecutor | Equipo de pruebas. |
|---|---|
Protocolo | Rest - https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521694326 gRPC - https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2484961314 |
Método | La prueba se realizará creando flujos end to end para la verificación de varios servicios. |
Tiempo | Una vez que haya concluido la carga de código en los ambientes |
Herramienta | Rest Assured, Serenity, JUnit4. |
El desarrollo de los scripts se realizará de modo que las pruebas puedan ejecutarse en cualquier entorno existente en las plataformas 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.
Pruebas no funcionales / performance
Las pruebas no funcionales se centran en evaluar el rendimiento del software en términos de tiempos de respuesta y capacidad para manejar una carga de trabajo específica. El objetivo es garantizar que el software cumpla con los estándares y requisitos adicionales, y se diseñan con el propósito de asegurar un funcionamiento óptimo en diversas situaciones, cumpliendo así con los criterios de calidad establecidos.
Se realizará las pruebas de performance al terminar las pruebas funcionales de los servicios propuestos para cada escenario integral, permitiendo así validar el performance de una acción completa.
El equipo de pruebas solicitará en su debido momento el ambiente de performance al equpo de DevOps + Desarrollo de SPIN.
Se documentara el como poder desarrollar mas escenarios de prueba en caso de requerirlos, esta documentación contemplara REST y gRPC, ambas automatizaciones bajo los lineamientos y framework de SPIN. Dicha dicha documentación podrá consultarse en el KT de Automatización. https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2496430085/Transferencia+de+conocimiento+-+Mirror+Strategy#Plan-y-ejecuci%C3%B3n-de-pruebas
Alcance
Ejecutor | Equipo de pruebas. |
|---|---|
Protocolo | Rest - https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521694421 gRPC - https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521661750 |
Método | La prueba se realizará creando flujos end to end para la verificación de varios servicios. |
Tiempo | Una vez que haya concluido la carga de código en ambiente staging |
Herramienta | K6 |
Notas alcance
Es importante hacer mención, que el alcance de las pruebas automatizadas en QA, esta limitada a pruebas funcionales de REST y gRPC en framework proporcionado por SPIN (Rest Assure), y pruebas de performance de REST y gRPC en la herramienta de K6.
Pruebas de carga
Estas pruebas se ejecutan para comprender el comportamiento del sistema ante una carga determinada que puede ser el número de usuarios concurrentes que el cliente espera en producción, sin forzarlo a una capacidad mayor a la esperada. Con esta prueba, se pretende conocer la cantidad de usuarios que verdaderamente soporta el sistema, los flujos más críticos para implementar una mejora en los mismos y detectar posibles cuellos de botella para corregirlos y así, optimizar el rendimiento en un lapso determinado.
Métricas de pruebas
Tiempo medio de respuesta | Respuesta de peticiones menor a 2 segundos |
|---|---|
Tiempo máximo de respuesta | Respuesta de peticiones entre 2 y 4 segundos |
Tasa de error | Se analizarán los resultados de los escenarios de prueba para revisar la probabilidad entre una o más comparaciones de los resultados de las pruebas realizadas concluyan incorrectamente, que la diferencia observada sea significativamente diferente de la esperada. |
Usuarios concurrentes | Número de usuarios activos |
Pruebas de estrés
En esta se pone a prueba la robustez y la confiabilidad del software, sometiéndose a condiciones de uso extremas, de esta forma se satura el sistema hasta un punto donde aparezcan defectos potencialmente peligrosos para facilitar la configuración de alarmas del sistema cuando se alcancen ciertos límites, permitiéndonos saber qué componentes fallan.
Herramientas
TestRail
Herramienta de gestión de pruebas que ayuda a organizar, planificar y realizar un seguimiento eficiente del proceso de pruebas.
Jira
Herramienta de gestión seguimiento a problemas y tareas relacionadas con el proceso de pruebas.
Detalles de las pruebas
Ambientes de pruebas:
Se ejecutarán de acuerdo con el framework actual de Spin:
Las pruebas en Genesys y Spin se realizarán de la siguiente forma:
Pruebas automatizadas → Ambiente QA
Pruebas performance → Ambiente Stage, el cual una copia del entorno de producción.
Para detalle de la configuración en los entornos, consultar: https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2525528084
Escenarios de pruebas:
Se ejecutarán los HappyPath de cada endpoint.
Defectos
Los defectos/Issues encontrados en la ejecución de pruebas automatizadas, se estará gestionando dentro de la herramienta de Jira, donde se especificara a detalle la descripción del defecto encontrado, así como la evidencia de apertura como la evidencia cuando el issue haya sido cerrado.
Los defectos serán trabajados contemplando el siguiente workflow.
Creación del bug.
Asignación y gravedad de issue.
Asignación a desarrollo.
Solución de defecto.
Pruebas de aceptación.
Captura de evidencia.
Cierre de defecto.
Entregables y actividades de pruebas
Como resultado de la ejecución de las pruebas, la documentación contemplada para la entrega a SPIN.
Para asegurarnos que los casos de prueba han tenido éxito o se han finalizado, se han considerado todos los escenarios posibles positivos/negativos de las función que debe ejecutar el endpoint. En el informe se detallará mucho más el contexto y panorama en el cual fueron ejecutadas las pruebas de este proyecto.
Consideraciones adicionales
TimeOut en transacciones
Debido a la forma como opera el operador financiero actual (Fiserv) los servicios de Spin aguardan a que llegue la respuesta aún si tarda varios segundos. Si la respuesta tarda más de 10 segundos Spin responde al usuario que la transacción no se logró completar; si pasado ese tiempo llega la respuesta del operador financiero, los servicios de Spin reversan la transacción, puesto que ya se informó al usuario que no se ejecutó. Todo esto con el fin de garantizar la consistencia de la información que fluye entre Spin y el operador.
Teniendo en cuenta lo anterior, los servicios del proyecto Mirror Strategy no manejan un TimeOut en las operaciones delegando a la lógica actual de Spin la tarea de decidir cuando una transacción se ejecuta o no correctamente. Internamente los servicios del proyecto realizan las validaciones necesarias para garantizar que se encuentren disponibles o arrojen la respuesta correspondiente en caso que no.
Se requiere que en las pruebas integrales se mapee este caso para asegurar que en los proceso de Spin ejecuten la reversa de la transacción para que el mirror cumpla con la funcionalidad del componente del flujo transaccional.