Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

« Previous Version 16 Next »

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

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:

  • Ayuda a lograr una mayor cobertura

  • Reducir tiempos de ejecución

  • Consistencia en ejecución de las pruebas

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

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

  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

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

Estrategia de Pruebas - Token Digital

Casos de pruebas (Tags)

Casos de Pruebas

Evidencia de resultados de prueba

Ejecuciones de Pruebas QA

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. Cierre de defecto.