FLUJO DE TRABAJO para QA MANUAL:

1. 🧪 Análisis de los Requerimientos de la Funcionalidad:

   • Revisar detalladamente la Historia de Usuario en Jira, enfocándose en los objetivos, criterios de aceptación y cualquier documentación relevante. Usar XRay para acceder a detalles específicos del testeo relacionados con la Historia.

2. 🧪 Estimación de las Horas de Trabajo en la Subtask Asignada para QA:

   • Utilizar Jira para crear y estimar subtasks de QA, incluyendo actividades de preparación, diseño, ejecución y reporte de pruebas. Incorporar consideraciones del VCR para futuras actividades de automatización.

3. 🧪 [Planning] Creación del Test Set para Análisis Técnico y Aplicación del VCR:

   • Definir el conjunto de pruebas en XRay, asegurándose de cubrir todos los criterios de aceptación. Aplicar el análisis VCR para evaluar la candidatura de estas pruebas para automatización, considerando su Valor, Costo y Riesgo.

4. 🧪 [Designing] Derivación de la Cobertura de Pruebas:

   • Diseñar detalladamente la cobertura de pruebas en XRay, especificando casos de prueba para validar cada criterio de aceptación y explorar escenarios adicionales relevantes.

5. 🧪 [Scripting] Diseño de Todos los Test Cases de la Cobertura:

   • Documentar cada caso de prueba en XRay, detallando pasos, condiciones previas, datos necesarios y el resultado esperado para cada prueba.

6. 🧪 [Setup] Creación del Test Execution para la Cobertura y Configuración del Test Environment:

   • Configurar el entorno de pruebas adecuado, utilizando XRay para planificar y preparar las ejecuciones de prueba según sea necesario para la Historia de Usuario.

7. 🧪 [Execution] Ejecución de las Pruebas para Validar la Funcionalidad:

   • Ejecutar manualmente los casos de prueba documentados en XRay, registrando los resultados y cualquier hallazgo en la plataforma.

8. 🧪 [Report] Cierre de la Ejecución y Reporte de los Resultados de Pruebas en la US:

   • Utilizar XRay para documentar un resumen de los resultados de las pruebas, incluyendo cualquier defecto encontrado, y vincular esta información de vuelta a la Historia de Usuario en Jira.

9. 🧬 Transitar la Historia de Usuario al Estado "Verified":

   • Actualizar el estado de la Historia de Usuario en Jira a "Verified" utilizando XRay para reflejar que todas las pruebas han pasado exitosamente, indicando así que la funcionalidad ha sido validada por QA.

10. 🧬 Revisión y Cierre Definitivo de la Historia por el Analista de Negocio:

    • El Analista de Negocio revisa el cumplimiento de los criterios de aceptación y los resultados de las pruebas documentados en XRay.

    • Si está satisfecho, actualiza el estado de la Historia de Usuario a "Done" en Jira, marcando el cierre definitivo de la misma.

FLUJO DE TRABAJO para QA Automation:

1. 🧪 Análisis de la Deuda Técnica: Revisar la tarea asignada en Jira que representa la deuda técnica para automatización. Analizar los requerimientos y la cobertura de pruebas manual previa para entender las funcionalidades y escenarios que deben automatizarse.

2. 🧪 Revisión de Cobertura de Prueba Existente: Examinar la cobertura de prueba y los casos de prueba manuales existentes. Identificar los casos de prueba candidatos para la automatización basándose en criterios como la frecuencia de ejecución, su criticidad, y el esfuerzo versus el beneficio de su automatización.

3. 🧪 Creación de la Rama de Automatización: Basado en el ID de la tarea de deuda técnica en Jira, crear una nueva rama en el sistema de control de versiones (ejemplo: git) para desarrollar los scripts de automatización.

4. 🧪 Implementación del Modelo de Objetos de Página (POM):

   • Para funcionalidades nuevas: Crear un nuevo Page Object Model que represente la estructura y el comportamiento de la interfaz de usuario de la funcionalidad.

   • Para funcionalidades existentes: Revisar y actualizar el Page Object Model existente para asegurar que refleje los cambios en la interfaz de usuario o en la funcionalidad.

5. 🧪 Diseño y Desarrollo de Scripts de Prueba Automatizados: Desarrollar los scripts de prueba automatizados utilizando el Page Object Model. Los scripts deben cubrir los casos de prueba identificados como candidatos para automatización.

6. 🧪 Ejecución y Debugging de los Scripts de Prueba: Ejecutar los scripts de prueba en el entorno de prueba configurado. Realizar debugging de los scripts según sea necesario para asegurar su correcta ejecución y la detección efectiva de defectos.

7. 🧪 Versionado con Git: Durante el desarrollo, guardar los cambios regularmente y realizar commits en la rama de automatización. Esto incluye tanto los nuevos scripts de prueba como las actualizaciones a los Page Object Models.

8. 🧪 Configuración del Archivo YAML para CI: Antes de hacer push de los cambios, actualizar el archivo .yml correspondiente al proceso de CI, específicamente en la sección de sanity checks o pruebas de regresión, para incluir las nuevas pruebas automatizadas. Esto asegura que las nuevas pruebas se ejecuten como parte del proceso de Integración Continua, permitiendo su validación en el entorno de CI.

9. 🧪 Push y Creación de Pull Request (PR): Realizar un git pull para actualizar la rama con los últimos cambios del repositorio remoto, seguido de un push de la rama de automatización. Crear un Pull Request hacia la rama QA incluyendo una descripción detallada de los cambios realizados, los resultados de las pruebas, y la configuración de CI actualizada.

10. 🧪 Code Review y Merge: Esperar a que el Pull Request sea revisado por el equipo. Abordar cualquier feedback recibido y hacer las correcciones necesarias. Una vez aprobado, mergear los cambios a la rama QA.

11. 🧪 Cierre de la Deuda Técnica: Reportar el trabajo realizado y los resultados obtenidos en la tarea de deuda técnica asignada en Jira. Cambiar el estado de la tarea a "Waiting For Review". Una vez revisado y aprobado el trabajo, cerrar la tarea de deuda técnica, indicando que la automatización ha sido completada y los scripts de prueba están en funcionamiento junto con la configuración de CI para futuras ejecuciones.

Aprende sobre las “Deudas Técnicas” a diferencia de las Historias de Usuario para así entender el trabajo del Tester Automation:

Las deudas técnicas en el contexto de QA Automation refieren a aquellos aspectos del testing que, por diversas razones, no se automatizan en el momento inicial de su implementación o identificación. Esta situación puede originarse por limitaciones de tiempo, recursos, o priorización de tareas en el ciclo de desarrollo de software. Utilizar el concepto de deuda técnica permite a los equipos reconocer y registrar formalmente la necesidad de futuras automatizaciones o mejoras que, aunque no críticas en el momento, deben abordarse para mantener la calidad y eficiencia del testing a largo plazo.

Origen de las Deudas Técnicas

El término "deuda técnica" fue acuñado por Ward Cunningham, uno de los autores del Manifiesto Ágil, para describir el compromiso consciente de adoptar soluciones no óptimas a corto plazo con el entendimiento de que estas soluciones requerirán revisión o mejora en el futuro. En el ámbito de QA Automation, la deuda técnica se refiere específicamente a las pruebas que se reconocen como candidatas para automatización pero que, por el momento, permanecen manuales por las razones ya mencionadas.

Deudas Técnicas en QA Automation

Para los Testers de Automatización, las tareas de deuda técnica son un reconocimiento de que, aunque algunas pruebas pueden realizarse manualmente en las etapas iniciales de desarrollo de una funcionalidad, su automatización eventual es crucial para:

• Mejorar la eficiencia del proceso de pruebas, reduciendo el tiempo y esfuerzo requeridos en ejecuciones futuras.

• Aumentar la cobertura de pruebas de manera más consistente y confiable.

• Facilitar la integración con procesos de Integración Continua (CI) y Despliegue Continuo (CD), mejorando así la calidad del software de manera continua.

Diferencia con las Historias de Usuario

Las Historias de Usuario son empleadas principalmente por Testers Manuales y equipos de desarrollo para entender y planificar el trabajo en nuevas funcionalidades desde la perspectiva del usuario final. Estas historias permiten a los equipos obtener feedback temprano sobre las funcionalidades en desarrollo, asegurando que el software cumpla con las expectativas y necesidades del usuario.

En contraste, las deudas técnicas en QA Automation no se centran directamente en nuevas funcionalidades desde la perspectiva del usuario, sino en la necesidad de mejorar el proceso de pruebas a través de la automatización. Mientras que las Historias de Usuario buscan garantizar la adecuación y satisfacción del producto final, las deudas técnicas se enfocan en optimizar y asegurar la sostenibilidad del proceso de desarrollo y testing en sí.

Conclusión

Las deudas técnicas son un componente crucial en la estrategia de QA Automation, permitiendo a los equipos de desarrollo y testing mantener un balance entre las demandas inmediatas del desarrollo de software y la necesidad de una base sólida y sostenible para el testing automatizado. Su gestión efectiva es clave para asegurar que el proceso de automatización de pruebas evolucione y se mantenga alineado con los objetivos de calidad y eficiencia del desarrollo de software.