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 el token digital exitoso en su funcionamiento interno y sus componentes.

Índice

Objetivo

El objetivo de la estrategia de pruebas es describir el enfoque y marco general para las pruebas manuales, automatizadas y de performance, adicional se indica el alcance de las pruebas, recursos necesarios, ambientes de pruebas, herramientas a utilizar, supuestos, los posibles riesgos y plan de mitigación, etc.

El objetivo de las pruebas de Token Digital, contemplan los lineamientos SPIN, sobre el desarrollo de las pruebas automatizadas, así como la ejecución, evidencia y reporte de hallazgos.

Las funcionalidades contempladas dentro de Token digital son las siguientes:

• Enrollamiento

• Activación de token

• Autenticación

• Flujo transaccional

Estrategia de ejecución

Teniendo la documentación requerida para la creación de los casos de pruebas, se realizará el análisis y diseño de los casos que abarcaran los componentes a desarrollar, dichos componentes se irán entregando por funcionalidad, y cada funcionalidad ya tendrá los casos de pruebas listos para proceder con la etapa de ejecución.

Cada sprint se realizará la ejecución del ciclo 1 y validación de no conformidades en caso de que haya.

En caso de que haya no conformidades en un ciclo 2 se realizará la validación del ciclo 3 y así sucesivamente hasta finalizar satisfactoriamente la ejecución.

Gestión de las pruebas

Se realizará el ciclo de pruebas de los servicios que se vayan entregando, donde se realizará las pruebas exploratorias, funcionales y se adelantará la automatización sin ejecutarse ya que la ejecución automatizada se realizará al finalizar el ciclo funcional, y a medida que se van ejecutando las pruebas funcionales y se van encontrando no conformidades se procederá a extender los ciclos hasta finalizar las pruebas sin ninguna no conformidad.

Objetivo de las pruebas

El objetivo de la prueba es verificar que los servicios desarrollados por el equipo de DevTeam, funcionan de acuerdo con las especificaciones técnicas y funcionales descritas por el negocio de SPIN.

La prueba ejecutará y verificará los casos de pruebas automatizados, identificará, corregirá y volverá a probar todos los defectos de gravedad alta y media según los criterios de entrada, y priorizará los defectos de menor gravedad para su futura corrección según los lineamientos de gestión y seguimiento de defectos.

Los objetivos finales de la prueba son:

• Los componentes descritos en la arquitectura estén listos para producción e integrarse con la aplicación SPIN.

• Un conjunto de pruebas estables desarrolladas por medio de la automatización que puedan ser reutilizadas para la ejecución de pruebas funcionales en el ambiente de QA de SPIN, se requiere lograr llegar a ambientes previos a producción.

Supuestos

• Se requieren datos similares a los de producción para el ambiente de QA SPIN y estarán disponibles en el sistema antes de iniciar las pruebas funcionales. (userId, Tokens generado por la aplicación SPIN).

• Se iniciará un tercer ciclo de pruebas en caso tal que se identifique una taza alta de defectos en el segundo ciclo de pruebas.

Generalidades

• Las pruebas exploratorias se llevarán a cabo una vez que la construcción esté lista para las pruebas

• Las pruebas de rendimiento y pruebas automatizadas se tendrán en cuenta en esta estimación.

• Todos los defectos vendrán acompañados de una instantánea en formato JPEG.

• El equipo de pruebas (QA) tendrá acceso al entorno de pruebas a través de una conexión VPN.

• El equipo de pruebas (QA) asume que todas las entradas necesarias requeridas durante el diseño y la ejecución de las pruebas serán apoyadas por el equipo de desarrollo.

• Las actividades de diseño, carga, actualización y ejecucióm de casos de prueba serán realizadas por el equipo de QA.

• Se socializarán los casos de prueba preparados por el equipo de pruebas con los desarrolladores antes de iniciar la ejecución de las mismas.

• Cualquier corrección de defectos planificada se compartirá con el equipo de pruebas antes de aplicar las correcciones en el ambiente de QA.

• El equipo de pruebas de SPIN proporcionará apoyo a la planificación, diseño y ejecución de las pruebas.

• No se producirá ningún tiempo de inactividad del entorno durante las pruebas debido a interrupciones o correcciones de defectos.

• El sistema se tratará como una caja negra; si la información se muestra correctamente en línea y en los informes, se asumirá que el proceso con HSM funciona correctamente.

• El ciclo 3 se iniciará si hay más defectos en el ciclo 2.

Pruebas a ejecutar

Pruebas automatizadas

• 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/2450194433/Transferencia+de+conocimiento+-+Token+Digital#Automatizaci%C3%B3n-de-pruebas-en-Token-Digital

Alcance

Ejecución de pruebas por ambiente

Pruebas performance

• 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/2450194433/Transferencia+de+conocimiento+-+Token+Digital#Automatizaci%C3%B3n-de-pruebas-en-Token-Digital

Alcance

Ejecución de pruebas por ambiente

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.

Herramientas

Criterios de aceptación

1. El documento de especificación funcional aprobado.

2. Los documentos de historias de usuario deben estar disponibles antes de comenzar la fase de diseño de las pruebas.

3. Desarrollo del sistema completado según alcance del sprint, pruebas unitarias con porcentaje de aprobación según definición de la herramienta de análisis de código estático y resultados compartidos con el equipo de pruebas para evitar escenarios de prueba y defectos duplicados.

4. Entorno de pruebas con los servicios desplegados, configurados y listos para su uso

1. Se debe generar un TOTP valido para realizar un enrolamiento

2. Se debe realizar un enrolamiento exitoso obteniendo un KeyId y el DeviceId

3. Para el endpoint enroll, todos los campos deberan ser obligatorios

4. Para el endpoint GenerateActivationKey, todos los campos seran obligatorios

1. Para el endpoint enableToken, debe generar una semilla valida

2. Para el endpoint disabletoken, debe poder eliminar las semillas generadas con relacion al KeyId

3. Para el endpoint refreshToken, debe poder actualizar la semilla con relacion al KeyId

4. Para el endpoint generateToken, debe poder generar un token valido

5. Para el endpoint validateToken, debe poder validar el token generado en el endpoint generateToken

6. Todos los endpoints, deberan solicitar todos los campos como obligatorios

Por definir

Principios de la prueba

Las pruebas se centrarán en el cumplimiento de los objetivos de negocio, la rentabilidad y la calidad.

• Habrá procedimientos comunes y coherentes para todos los equipos que apoyen las actividades de pruebas.

• Los procesos de prueba estarán bien definidos, pero serán flexibles, con la capacidad de cambiar según sea necesario.

• Las pruebas serán una actividad repetible, cuantificable y medible.

• Las pruebas se dividirán en distintas fases, cada una con objetivos y metas claramente definidos.

• Habrá criterios de entrada y salida.

Enfoque de los datos de prueba

Se tendrán en cuenta los siguientes enfoques para pruebas automatizadas y de performance, según sea el caso:

• Se requiere contar por parte de QA SPIN los datos de prueba pre cargados en el ambiente de QA SPIN, datos de prueba para los escenarios que se consideren que contienen información sensible y también darán las directrices para la correcta implementación de dichos datos.

• Algunos escenarios de pruebas automatizadas crearán en tiempo de ejecución sus propios datos de prueba.

• El equipo de QA será el responsable de la generación y mantenimiento de los datos de pruebas y se apoyará cada vez que sea necesario con los desarrolladores para garantizar la ejecución de dicha tarea.

• Se realizará la gestión de casos de pruebas de acuerdo con el framework y herramientas que disponibilce QA SPIN.

Entregables y actividades de pruebas

Como resultado de la ejecución de las pruebas, la documentación contemplada para la entrega a SPIN.

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.

1. Creación del bug.

2. Asignación y gravedad de issue.

3. Asignación a desarrollo.

4. Solución de defecto.

5. Pruebas de aceptación.

6. Captura de evidencia.

7. Cierre de defecto.