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
Propósito | Consiste en el uso de una herramienta de software para controlar y configurar las condiciones previas a las pruebas, ejecución de pruebas y comparaciónde resultados reales contra resultados esperados. Beneficios:
|
|---|---|
Ejecutor | Equipo de pruebas. |
Protocolo | Rest y gRPC |
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 |
Ejecución de pruebas por ambiente
Interfaz | QA | Staggin |
|---|---|---|
REST | Se ejecutara | Se ejecutara |
gRPC | Se ejecutara | Se ejecutara |
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
Propósito | Las pruebas de performance, identifica si hay alguna vulnerabilidad en cuanto a los recursos cuando los servicios tienen un alto consumo, adicional se verifica si los componentes desarrollados se encuentran adecuados para resistir la volumetría esperada. |
|---|---|
Ejecutor | Equipo de pruebas. |
Protocolo | Rest y gRPC |
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 |
Ejecución de pruebas por ambiente
Interfaz | QA | STAGGIN |
|---|---|---|
REST | No aplica | Se ejecutara |
gRPC | No aplica | Se ejecutara |
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.
Criterios de aceptación
El documento de Especificación Funcional aprobado.
Los documentos de historias de usuario deben estar disponibles antes de comenzar la fase de diseño de las pruebas.
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.
Entorno de pruebas con los servicios desplegados, configurados y listos para su uso
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.
Resultado de las pruebas
Documentación | URL |
|---|---|
Estructura de la ejecución de pruebas | |
Casos de pruebas (Tags) | |
Evidencia de resultados de prueba |
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
Cierre de defecto.
Add Comment