De desarrollador a QA Manager

Víctor Gómez Adán



 Por Abel Meriño Ibarra

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: 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

 

Eventos


 

Cursos

  • Pluralsight
  • ISTQB® Foundation: Getting Started
  • Creating Automated Browser Tests with Selenium 3 in C#
  • QA Lovers Academy

¿Cómo transitar de las validaciones manuales “documentadas” en Excel a procesos de calidad integrados y automatizados? 

 

La metodología de trabajo

Una
de las primeras acciones que hicimos fue definir que el equipo de QA
cada miembro de este estuviera integrado como parte de los equipos de
desarrollo, participando en 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: 

  1. 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.
  2. 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.

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


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

Otro 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, 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:
  • La creación de datos necesarios para las pruebas
  • 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:
  • Quality Gate de Sonar Cloud
  • Número de errores activos
  • Evolución de la ejecución de pruebas unitarias
  • Evolución de la ejecución de pruebas E2E
  • Trazabilidad de las pruebas E2E con los requerimientos que intenta asegurar

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 
  • Abordar temas como mapas conceptuales como punto de partida para el testing exploratorio.

 
   








0 Comentarios