De desarrollador a QA Manager – Primera parte

Por Abel Meriño

Desde hace algún tiempo los temas de Aseguramiento de la calidad en el proceso de desarrollo de Software venían motivando mi interés y al final he decidido “cambiar” y dejar de ser programador y comenzar mi desarrollo como Quality Assurance.

No hay duda de que más de 15 años de experiencia vinculado a todo este ámbito de la tecnología donde me he desempeñado en: la enseñanza, la gestión de áreas de servicios tecnológicos y el desarrollo de Software me están ayudando a que este proceso sea asumible.

Si me preguntas que es lo primero que debemos hacer al comenzar el proceso de crecimiento como QA, aunque suene a tópico, diría que estudiar y leer mucho, máxime si te estrenas en este ámbito como QA Manager.

Aunque en Internet hay mucha información sobre todos los temas de testing, comento algunas lecturas, eventos y enlaces que hoy en día percibo que me han ayudado mucho.

Lecturas y comunidades

• Blog de QAMakers
• Introducción a las Pruebas de Sistemas de Información por Federico Toledo
• Specflow máster class (https://specflow.org/school/bdd-masterclass/)
• Blog de Federico Toledo (https://www.federico-toledo.com/category/blog/)

Eventos:

• Quality Summit
• VLC Testing
• TestingUy

Cursos:

• QAMakers Academy con su Bootcamp de QA
• Pluralsight
• ISTQB® Foundation: Getting Started
• Creating Automated Browser Tests with Selenium 3 in C#

Al estrenarme como QA Manager de los primeros retos fue: ¿Cómo transitar de las validaciones manuales “documentadas” en Excel y ajenas al proceso de desarrollo a tener un procesos de calidad integrado en los equipos y automatizados?

La metodología de trabajo

Una de las primeras acciones que hicimos fue definir que el equipo cada miembro del equipo de QA estuviera integrado como parte de los equipos de desarrollo, participando en todas las ceremonias del Sprint como un miembro más del equipo.

Como parte de los equipos de desarrollo se definieron las tareas que su rol debe realizar durante el Sprint. En este sentido hemos establecido dos acciones fundamentales:

• En la primera parte del Sprint crear un Plan de pruebas en Azure para definir a cada requerimiento los casos de prueba que se consideren oportunos. Teniendo en cuenta casos de pruebas de regresión si el requerimiento lo necesita.
• En la segunda parte del Sprint ejecutar el Plan de pruebas.

A nivel de desarrollo en los repositorios de códigos se crearon sendos proyectos de pruebas automatizadas.

- Proyecto de pruebas unitarias

- Proyecto de pruebas de Extremo a Extremo (E2E)

- Se estableció aprobación de Pull Request (PR):

- Integración con Sonar Cloud

- Obligatoriedad de relacionar la PR con un requerimiento o error.

- Aprobación de la PR por el miembro de QA del equipo. Con esta acción de forma expresa y controlada el QA del equipo sabe cuándo un desarrollo se pretende subir al repositorio y pueda terminar su proceso de validación.

Los procesos de validación manual de requerimientos y errores

Para los procesos de validación manual de requerimientos y errores, los miembros del equipo de QA creamos entornos de pruebas, el esquema es el siguiente:

Para no ser estrictos en el esquema anterior y según considere el QA del equipo, así como el tipo de desarrollo se permite primero aprobar la PR a master y desplegarse dicha rama en su entorno de validación para inmediatamente probar los desarrollos.

Esta forma de trabajar nos permite tener estabilidad en la rama máster ya que cada desarrollo que se acepta entra validado por los casos de pruebas del requerimiento y en caso de ser necesario con casos de pruebas de regresión. De esta forma cuando vamos al listado de PRs todas deben tener un requerimiento (PBL) o un error (Bug) asociado y validado por el QA del equipo.

El desarrollo del equipo de QA

En el ámbito de los modelos de desarrollo profesional hemos planteado como primer hito un desarrollo profesional en T

Para el desarrollo profesional del equipo estamos desarrollando planes de formación para dar cumplimiento a este modelo de desarrollo.

Un modelo en T contempla competencias básicas y una especialización, en este sentido entendemos como competencias básicas:

• Análisis de requerimientos

• Historias de usuarios

• Criterios de aceptación

• Creación de casos de pruebas

• Fundamentos del testing en entornos ágiles

• Testing exploratorio con Azure

• Testing de aplicaciones móviles

Por otra parte, teniendo en cuenta los intereses personales y las habilidades de cada uno de los miembros del equipo de QA identificamos tres competencias específicas:

• Automatización de pruebas

• Pruebas de rendimiento

• Gestión de procesos de QA, reportes y testing ágil

La automatización de casos de pruebas

Un aspecto estratégico en el cual estamos volcados es en los procesos de automatización de pruebas.

La pirámide de testing la nombró por primera vez Mike Cohn en su libro 'Succeeding with Agile' de 2009, de esta fecha a la actualidad las herramientas de testing, programación y despliegue de aplicaciones han evolucionado mucho. Si bien no pretendo cuestionar esta pirámide al menos si me he permitido adaptarla a mis necesidades y al tipo de aplicación que desarrollamos. Por ejemplo:

El código desarrollado para acciones tipo CRUD representan una parte importante de nuestra aplicación y en este escenario las pruebas E2E queremos que jueguen un papel importante a un coste que hoy en día es asumible.

En cambio, y manteniendo que la idea de que las pruebas unitarias son la base de los procesos de calidad automatizados en módulos donde la lógica de cálculo es lo fundamental, las pruebas unitarias son claves.

Es por ello por lo que en cada repositorio hemos creado sendos proyectos de pruebas:

• Proyecto de pruebas unitarias

• Proyecto de pruebas de Extremo a Extremo (E2E)

El proyecto de pruebas E2E está enfocado hacia la regresión de los procesos claves de la aplicación. Además, tenemos creado un proceso de despliegue automático y programado de la rama máster.

Sobre este código desplegado se ejecutan las pruebas E2E de aquellas funcionalidades que se van definiendo como críticas dentro de la aplicación. Estas pruebas:

• Están basadas en entornos para testing E2E con una base de datos prácticamente vacía

• Utilizamos la API para:

o La creación de datos necesarios para las pruebas

o La comprobación de datos creados a través de las pruebas E2E

Este proyecto de pruebas de E2E está basado en el siguiente stack tecnológico:

• .NET como lenguaje base de programación

• SpecFlow, para organizar los casos de pruebas como parte del código y como documentación de los requerimientos.

• Selenium o Playwright como Automates browsers

• Specflow y LinvingDoc como dashboard de publicación de resultados de la ejecución de los casos de pruebas

• Dashboard de Azure para mostrar el seguimiento de indicadores de calidad tales como:

o Quality Gate de Sonar Cloud

o Número de errores activos

o Evolución de la ejecución de pruebas unitarias

o Evolución de la ejecución de pruebas E2E

o Trazabilidad de las pruebas E2E con los requerimientos que intenta asegurar

 

Este proceso de automatización exige:

• Incluir dentro de la metodología de trabajo que los QAs de los equipos escriban en lenguaje Gherkin los casos de pruebas que se quieren automatizar vinculándolos a los requerimientos funcionales del Sprint y de este modo al menos generamos documentación “viva” dentro del código y de fácil localización, así como los casos de prueba automatizados vinculados a un requerimiento funcional.

• Coordinación con el Product Owner para identificar requerimientos y escenarios claves.

• Programar las pruebas E2E

• Cubrir un déficit de pruebas E2E de requerimientos funcionales que ya están en producción.

Algunos pasos futuros

Tenemos que saber que nunca sabemos todo, y siempre hay personas que ya han recorrido el camino que estás iniciando, aprovechar la experiencia de otros equipos es siempre de gran utilidad, por ello es esencial para continuar el proceso de crecimiento como equipo, realizar un proceso de evaluación (assesment) con equipos con una importante experiencia en todos los procesos de aseguramiento de la calidad en el desarrollo de software.

Después del proceso de Evaluación se abren nuevos retos, alguno de ellos:

• Un proceso de refinamiento estratégico, donde aspiramos a ir transformado del QA como puesto al QA como rol, implicar a todo el equipo en el aseguramiento de la calidad.

• Aún no hemos comenzado a abordar, temas como: Monitorización y pruebas de rendimientos.

• Cubrir el déficit de pruebas E2E de aquellos requerimientos que ya están en producción.

• Crecer de la forma más rápida y sostenible las pruebas E2E de los nuevos requerimientos claves que se continúan desarrollando, sin perder el aseguramiento de la calidad que hacemos a través de los procesos de testing manual (Creación y ejecución de casos de pruebas y testing exploratorio).