Estrategia de Pruebas – Mirror Strategy

Objetivo  

Esta estrategia de pruebas tiene como objetivo principal establecer un enfoque claro para las pruebas automatizadas. En este sentido, se incluirán detalles sobre la estrategia de ejecución de las pruebas, el alcance de las mismas, los recursos requeridos, los ambientes de pruebas, las herramientas a utilizar y los supuestos pertinentes. Asimismo, se abordarán los posibles riesgos y se presentará un plan de mitigación correspondiente.  

Objetivos de las pruebas 

• Verificación de la 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. 

• 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. Las pruebas permiten que los equipos trabajen de manera independiente, 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. 

Estos objetivos se aplican a todos los componentes descritos en la arquitectura del proyecto Mirror Strategy, 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. 

Pruebas Automatizadas 

El proceso de automatización de pruebas se llevará a cabo siguiendo los lineamientos, herramientas, nomenclaturas y estructuras definidos por el equipo de SPIN.  

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

Ciclo de ejecución de pruebas 

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

• DISEÑO DE CASOS DE PRUEBA:  

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. 

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

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

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

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

• RETESTING: 

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 o para lanzar el software al mercado. Es importante destacar que el ciclo de pruebas puede ser adaptado y ajustado según las necesidades y características específicas del proyecto. 

Generalidades 

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. 

Precondiciones para las actividades de prueba 

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. 

Alcance y tipos de pruebas 

 {Pendiente}

Entregables y actividades de prueba