Estrategia de Pruebas - Spin - Token Digital

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.

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 la prueba: 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 la prueba
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 al ambiente de Staging, en caso de que SPIN no lo requiera o solo permita hasta QA, se dejará programada la automatización de pruebas para que se pueda ejecutar en cualquier ambiente.

Supuestos de las pruebas

• 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 tendrá acceso al entorno de pruebas a través de una conexión VPN.

• El Equipo de Pruebas 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 de PALO-IT.

• Las actividades de diseño de casos de prueba serán realizadas por el QA.

• El equipo de desarrollo proporcionará planes de corrección de defectos basados en las reuniones de defectos durante cada ciclo de planificación. Lo mismo se informará al equipo de pruebas antes de iniciar los ciclos de corrección de defectos.

• Se socializarán los casos de prueba preparados por el equipo de pruebas con el DevTeam 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 proyecto 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 funcionales

• Durante las pruebas funcionales, el equipo de pruebas utilizará los datos proporcionados por el equipo de desarrollo de PALO-IT o de SPIN (userId, Tokens).

• El equipo de pruebas realizará las pruebas funcionales solo en el ambiente de QA- SPIN, lo ideal sería hacer pruebas hasta el ambiente de Staging, sin embargo en caso de que SPIN no lo requiera o no lo permita, se dejará las pruebas automatizadas para ejecutar en cualquier ambiente.
  

QA-SPIN
La ejecución de las pruebas será realizada por el equipo de QA y se generará un resultado de las pruebas que será mostradas al cliente que en este caso es SPIN

Pruebas Automatizadas

• Se realizará la automatización de Pruebas bajo el framework definido por SPIN, debido a que ya tienen pruebas automatizadas bajo ese mismo framework.

• El equipo de pruebas realizará la automatización para poderse ejecutar en cualquier ambiente.

• El equipo de pruebas realizará la automatización para escenarios individuales de cada servicio y de escenarios integrales.

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 de SPIN (se solicitará por medio de correo al señor Mario Mendez de SPIN)

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.

• El entorno y los datos de las pruebas emularán un entorno de producción en la medida de lo posible.

• 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 funcionales, automatizadas y de Performance, según sea el caso:

• Se garantizará datos de prueba pre cargados en el ambiente de QA SPIN.

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

• El proyecto proporcionará 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.

• 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 en el DevTeam para garantizar la ejecución de dicha tarea.

• Se realizará la gestión de casos de pruebas mediante el Excel, debido a las indicaciones por Javier Guevara quien es el encargado del área de QA por parte de SPIN (correo confirmado con titulo Herramienta Gestión de casos - SPIN el día 27/04/2023)
  

Alcance y tipos de pruebas

Pruebas Exploratorias

• PROPÓSITO: el propósito de esta prueba es asegurarse de que se eliminan los defectos críticos antes de que puedan comenzar los siguientes niveles de prueba.

• ALCANCE: Navegación de primer nivel, módulos de concesionario y de administración.

• EJECUTOR: Equipo de pruebas.

• MÉTODO: esta prueba exploratoria se lleva a cabo en los servicios sin ningún tipo de scripts de prueba ni documentación.

• TIEMPO: al principio de cada ciclo.

Pruebas funcionales

• PROPÓSITO: Las pruebas funcionales se realizarán para comprobar la correcta funcionalidad de los servicios basada en el diseño funcional del sistema (objeto de prueba). La prueba funcional se lleva a cabo mediante la alimentación de la entrada y validación de la salida de los servicios.
  Nota: El alcance es de alto nivel debido a los cambios en los requisitos.

• EJECUTOR: Equipo de pruebas.

• MÉTODO: La prueba se realizará con la ejecución de la automatización desarrollada para estos casos de prueba.

• TIEMPO: después de la prueba exploratoria.

Automatización de Pruebas

• PROPÓSITO: Las pruebas automatizadas reducen el tiempo de pruebas de regresión, permitiendo así tener la posibilidad de ejecutar flujos automatizados, verificando si todo se encuentra bien, ayudando a mermar el tiempo de las pruebas después de una corrección de defectos.

• EJECUTOR: Equipo de pruebas.

• MÉTODO: La prueba se realizará creando flujos end to end para la verificación de varios servicios.

• HERRAMIENTA: Se utilizará el Framework definido por SPIN, permitiendo realizar la automatización y pueda ser ejecutada en cualquier ambiente.

• TIEMPO: después de las pruebas funcionales.

Pruebas de Performance

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

• MÉTODO: La prueba se realizará creando flujos end to end para la verificación de varios servicios.

• HERRAMIENTA: la herramienta que se utilizará es K6, permitiendo la ejecución de las pruebas de performance.

• TIEMPO: después de las pruebas funcionales.

CRITERIOS DE ACEPTACIÓN DE LA PRUEBA

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

Resultado de las pruebas