De desarrollador a QA Manager. Segunda parte

Por Abel Meriño

La semana pasada descubristeis la primera parte de este artículo (De desarrollador a QA Manager. Primera parte) donde describo una primera aproximación a la gestión de los procesos de calidad. En esta segunda parte es una vuelta de tuerca más intentado cada vez ajustar los procesos de calidad a los estándares que marcan la teoría.

En este sentido uno de los primeros errores que he evitado cometer (me ha costado) en este proceso de coordinación de la estrategia de calidad ha sido el ir demasiado de prisa, y es que hay que entender que todo proceso de cambio lleva su tiempo y sus momentos y sobre todo debemos desarrollar la habilidad como QA de ir inoculando poco a poco los cambios.

Es por ello por lo que siempre es sabido desde el principio lo que debemos hacer, basta con leer y estudiar, lo complejo es saber adaptar e ir aproximando los procesos a lo que marca la teoría teniendo claro de donde partes y cuáles son tus “herramientas”.

Esta “nueva” estrategia continua por la senda de intentar cumplir con la máxima de que: la calidad es responsabilidad de todos.

Por ello teniendo conseguido las siguientes premisas:

• Un producto con mayor madurez y solidez

• Proceso de gestión de desarrollo del producto, estandarizados e interiorizado

• Un equipo de QA con sólidos conocimientos del producto

• Una batería de casos de pruebas por módulos, clasificados, actualizados y priorizado

• Un equipo de desarrollo que ha incorporado las pruebas unitarias como parte de su desarrollo, y en algunos casos aplicación de técnicas de desarrollo TDD

• Herramienta de análisis de código estático (Sonar Cloud) integrada en el proceso de desarrollo.

• Un equipo de QA con conocimientos y formación en:

o Creación de casos de pruebas.

o Testing en metodologías ágiles

o Utilización de leguaje Gherkin

o Pruebas de api con Postman

o Pruebas e2e

• Procesos de CI/CD para la ejecución de pruebas unitarias, pruebas de API y pruebas e2e

Proponemos los siguientes roles dentro del equipo de QA:

• Quality Assurance por cada equipo de desarrollo.

• Quality Engeneer Automation transversal a los equipos de desarrollo

• Tester transversal a los equipos de desarrollo.

• Quality Assurance Manager

Las siguientes metas u objetivos globales:

• A nivel de cada miembro del equipo de QA integrado en los equipos de desarrollo, consolidar el rol de Quality Assurance, cuyo objetivo es: Velar por el proceso de calidad en el desarrollo del producto

• Consolidar dentro del equipo las labores de calidad. Es decir que todos los miembros del equipo tengan algún impacto en las tareas de calidad.

• Consolidar las sesiones de testing exploratorio de forma sistemática.

• Consolidar los procesos de testing automatizado.

Para dar cumplimiento a estas metas generales se mantiene la misma idea de que cada miembro del equipo de QA con el rol de Quality Assurenace esté integrado dentro del equipo de desarrollo ajustando su metodología de trabajo.

Metodología de trabajo del rol Quality Assurance

Este rol al estar integrado en los equipos de desarrollo se desempeña según el sprint del equipo que se desarrolla en iteraciones de tres semanas.

A nivel de Sprint se incorporan las sesiones de Backlog Grooming. Sesiones que se desarrollan por tres roles: Product Owner (PO), TeachLead (TL) y Quliaty Asserunce (QA). Esta sesión tiene las siguientes características:

• Se llega en la tercera semana del sprint en curso con una primera versión de las historias de usuarios del próximo sprint que incluye los criterios de aceptación.

o Entre los participantes se debe conseguir:

 Entendimiento de las historias de usuarios.

 Se define el objetivo del sprint

 Se contribuye a la mejora de las historias de usuarios (Criterios INVEST)

 Se identifican casos de pruebas existentes que pueden verse afectados y/o serán necesarios actualizar y ejecutar.

o El resultado de la sesión para QA es: Incorporar en la tercera semana del sprint en curso tareas del próximo sprint:

 Crear los casos de pruebas para satisfacer los criterios de aceptación

 Escribir en Gherkin (dentro del proyecto) los casos de pruebas a automatizar

 Identificar casos de pruebas automatizados que puedan verse afectados por las nuevas historias de usuarios.

 Identificar casos de pruebas automatizados que sea necesario realizar algún mantenimiento, actualización o mejora.

• En la primera semana del sprint se inicia con la Planing:

o Con las historias de usuario ya refinadas en el sprint anterior

o Un test plan que incluye

 Testing manual

 Testing automatizado

o En esta sesión QA distribuye entre los miembros del equipo (incluido el propio QA) las tareas de testing manual de forma que:

 Entre los miembros del equipo exista una validación cruzada

 Al ser el QA el miembro del equipo con más experiencia en validación podría quedarse con aquellos PBL o bugs más críticos del sprint.

 QA planifica una sesión de testing exploratorio para el final del sprint

• La primera y segunda semana del sprint QA estaría centrado en la automatización de casos de pruebas y en recabar evidencias de la validación cruzada. 

• Durante la tercera semana del sprint QA se centra en la creación de casos de pruebas del próximo sprint en la ejecución de la sesión de testing exploratorio para dar a conocer sus resultados en la sesión de Sprint Review.

Áreas de trabajo, tareas y distribución del tiempo

Gestión del proceso. Aproximadamente 20 horas que se distribuye fundamentalmente en:

• Participar en las sesiones de refinamiento del Sprint.

• Participar en la Sprint planing.

• Exigir y velar por evidencias de pruebas de las historias de usuarios

Testing manual. Aproximadamente 40 horas que se distribuye fundamentalmente en:

• Creación de los casos de pruebas asociados a los PBL que se analizaron en la sesión de refinamiento.

• Creación de casos de pruebas a automatizar en Gherkin.

• Sesión de testing exploratorio Automatización, aproximadamente 40 horas

• Automatización de los casos de pruebas analizados en la sesión de refinamiento. De esta forma el esquema general del sprint es el siguiente:

El objetivo de esta metodología de trabajo está dirigido a:

• Involucrar a todo el equipo en las labores de testing ya sean automatizados (unitarios, api testing y e2e) o manuales.

• Consolidar el testing exploratorio como herramienta de cierre del sprint valorando el cumplimiento del objetivo del mismo

• Potenciar la automatización de casos de pruebas.

 

La salida del sprint por parte de QA es:

• El control de la ejecución por los miembros del equipo de los casos de pruebas de los casos de pruebas asociados a los PBL del Sprint.

• Casos de pruebas automatizados

• Un informe de resultado del testing exploratorio donde se valora el cumplimiento del objetivo del sprint

• Un test plan del próximo sprint

Si la carga de trabajo en temas de automatización sigue estando dentro del equipo y como parte del desarrollo del sprint. ¿Qué sentido tiene un rol transversal que se dedica a este tema?

El rol de QA Automation que se propone incluir y con un enfoque transversal, es decir, fuera de los equipos de desarrollo se justifica por la propia pirámide de automatización de pruebas. Este rol trabaja fundamentalmente en:

1. Apoyo técnico en las pruebas de aceptación que se desarrollan dentro del equipo

2. En el desarrollo de pruebas e2e a más alto nivel.

a. Workflow tests

b. System tests

Las pruebas a nivel de producto se desarrollan en un repositorio independiente de los equipos de desarrollo y tendrán su evolución independiente, pero siempre automatizando procesos que involucran a más de un módulo y/o más de un equipo de desarrollo.

 

Principales funciones del rol QA Automation

Este rol al ser un rol transversal su desempeño se realizará por metodología Kanban y sus principales funciones son:

• Seguimiento de todas las pruebas E2E que se están realizando en todos los equipos

o Apoyar el desarrollo en cada módulo

o Dar sugerencias y buenas prácticas para el desarrollo de las pruebas e2e

• Desarrollar pruebas e2e

o Desarrollar pruebas e2e para aumentar la batería de pruebas de los módulos.

o Atender las pruebas inestables (Flaky Test)

o Desarrollar pruebas e2e para aplicación móvil

• API testing

• Desarrollar pruebas e2e del proyecto SmokeTest

• Inclusión de visual testing en las pruebas e2e

• Desarrollar pruebas e2e a nivel de producto, en un repositorio diferente a los módulos

• Integración CI/CD de las pruebas automatizadas

o Monitorizar las pipelines de test e2e

o Desarrollar nuevas funcionalidades de integración de los test automatizados en los procesos de CI/CD

Muy de la mano con este rol se desempeña el rol de QA tester que también trabaja por metodología Kanban independiente a los equipos de desarrollo y sus principales funciones son:

• Creación y mantenimiento de interrelaciones entre módulos.

o Casos de pruebas transversales a nivel de producto

o Creación y mantenimiento de mapas conceptuales

• Monitorización funcional de clientes

o Realización de testing exploratorio a nivel de producto tanto en master como en release

 Valoración general del producto

 Errores detectados

 Mejoras propuestas

 Casos de pruebas creados

 Informe de usabilidad de la aplicación.

• Monitorización de logs de producción

• Sesiones de testing exploratorio

• Refinamiento de casos de pruebas existentes en módulos

• Testing de accesibilidad.

 

Se puede percibir que con este enfoque se pretende aproximarnos a este modelo de pipeline de despliegue continuo.

Algunos pasos a futuro

Del pipeline anterior queda la deuda de como introducir el Performance testing. No es objetivo en esta segunda iteración, pero se puede ir perfilando algunos aspectos.

• Incluir el perfomance testing y la monitorización desde el propio proceso de desarrollo, por lo que es necesario acercar este testing al equipo de desarrollo.

o Crear en cada módulo un proyecto de Permormance testing con k6.

o Integrar los resultados de k6 en los procesos de CI/CD y con Grafana

o Incluir en los dashboard de métricas de QA en AzureDevops acceso a la monitorización de los test de performance

• Incluir el performance testing a nivel de producto y de forma transversal utilizando JMeter y AzureLoadTesting