Introducción
En el segundo capitulo vimos cómo aplicábamos la estrategia Prevention & Reaction en tiempo de producción. En el último post de la serie, vamos a ver un ejemplo de organización de equipos QA que garantizan la estrategia en todas sus fases y contextos.
Equipos de trabajo
Para poder garantizar la calidad del software siguiendo la estrategia se crea una estructura grupal en la que cada grupo de trabajo se dedica o toma la responsabilidad de áreas concretas de la calidad del software.
La importancia de la estructura grupal planteada reside en la necesidad de cohesión de los grupos de trabajo, debido a que las tareas realizadas por un equipo son necesarias para otro.
Esto genera la posibilidad de disponer de personas multidisciplinares, es decir, personas que puedan participar en distintos grupo de trabajo a la vez, o permitir la rotación grupal.
La imagen muestra la cohesión de la que estamos hablando, así como la cobertura de cada grupo.
De forma general, se puede apreciar que el grupo strategy abarca los demás grupos, debido a que sus decisiones afectan a todos los grupos.
Otro ejemplo es el equipo de Testing, el cual abarca las células de desarrollo dado que tiene que dar servicio y soporte de testing.
Vamos a ver la responsabilidad de cada grupo.
Equipo de estrategia
De forma general, el equipo de estrategia debe procurar mantener la estrategia y tomar decisiones importantes sobre la misma, debiendo corregir el rumbo cuando no se siga el camino previsto.
Las responsabilidades más importantes son:
- Diseñar la estrategia: Este equipo debe tener siempre presentes las necesidades en cuanto a la calidad del software se refiere y desarrollar una estrategia de calidad que las cubra.
- Definir KPIs: Los KPIs servirán para ver si la estrategia sigue el buen camino. En el caso de que los KPIs nos muestren indicios de que no se cumplen los objetivos preestablecidos, se podrán tomar decisiones con antelación para así poder pivotar la estrategia.
- Integrar la calidad en el CI: Hemos visto en las diferentes fases que la estrategia requiere estar presente en el flujo de la integración continua; es, precisamente, el equipo de estrategia el que deberá garantizarlo.
Equipo de datos
Durante el análisis que hemos hecho de la estrategia, hemos recalcado la importancia de obtener los datos de los resultados de las pruebas, de los datos de producción y de disponer de un sistema de predicción de bugs.
Las responsabilidades más importantes son:
- Obtención de datos de pruebas: Se deberán desarrollar las herramientas necesarias para obtener los datos de los resultados de las pruebas. Como hemos ido diciendo durante la serie de posts, los datos obtenidos nos servirán para alimentar la heurística del sistema de predicción de bugs, así como para mantener un histórico de resultados.
- Obtención de datos de producción: Los datos de producción van a servirnos para disponer de datos objetivos que nos ayuden a crear un mapa de calor de acciones, o bien como datos de entrada para las pruebas. Si nos fijamos en los logs de producción, podremos localizar trazas de errores y adelantarnos a solucionarlos o a reportarlos.
- Obtención de datos para KPIs: Los KPIs son indicadores o métricas que nos aportan conocimiento del estado de las acciones que estamos realizando. Mediante los KPIs seremos capaces de detectar defectos en nuestra estrategia o, por el contrario, ver el éxito de la misma. El equipo de datos debe desarrollar las herramientas necesarias para poder obtenerlos.
- Análisis y reporte de los datos: El análisis de los datos es de las acciones más importantes que debe realizar el equipo, dado que los resultados de los análisis son decisivos para la estrategia.
El equipo de datos tiene que trabajar estrechamente con los demás equipos de QA, debido a que va a necesitar extraer datos de todas las pruebas, así como de los resultados de la validación de las RCs o de la gestión de bugs. Estos datos serán analizados junto con el equipo de estrategia.
Equipo de automatización
El equipo de automatización deberá desarrollar los proyectos o herramientas necesarias para la ejecución de las pruebas automáticas. Los proyectos no tienen por qué ser únicamente desarrollo de pruebas automáticas; el equipo de automatización también se encargará de desarrollar los frameworks necesarios para el desarrollo de las mismas.
Las responsabilidades más importantes son:
- Framework de desarrollo de pruebas: Para muchos casos es necesario desarrollar, adaptar o mejorar un framework de testing. El equipo de automatización tiene que proveer ese framework a los equipos que desarrollen pruebas automáticas, ya sean ellos mismos o los desarrolladores.
- Desarrollo de pruebas funcionales: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, es posible que el equipo de automatización necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.
Es necesario que el equipo de automatización trabaje estrechamente con los departamentos de producto y de desarrollo, debido a que las pruebas que se desarrollen van a depender mucho de las conversaciones entre los diferentes departamentos.
Equipo de Rendimiento y Seguridad
El rendimiento y la seguridad de nuestra aplicación son unos de los valores más importantes que tenemos que garantizar, pero no siempre son los más sencillos. El equipo de rendimiento y seguridad se deberá encargar de desarrollar las pruebas necesarias que garanticen la calidad de ambos aspectos.
Las responsabilidades más importantes son:
- Pruebas de rendimiento: Disponer de una suite de pruebas de rendimiento (pruebas de carga, estrés, estabilidad, etc.).
- Pruebas de seguridad: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, el equipo de automatización es posible que necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.
El equipo de rendimiento y seguridad debe trabajar estrechamente con el departamento de sistemas o sysop, debido a que sus pruebas van a tener impacto en los entornos y en la aplicación.
Equipo de Testing
Dentro de las tareas más importantes se encuentra el validar o rechazar la RC y para ello es necesario que el equipo de testing realice las pruebas correspondientes. Por otro lado, el tratamiento de bugs y las pruebas bajo demanda también son tareas del equipo de testing.
Las responsabilidades más importantes son:
- Validación de RCs: Sacar la RC adelante es la finalidad de todos (desarrolladores, sys, QA, producto etc.), por lo que es la tarea más importante del equipo de testing. En caso de que en tiempo de RC en la fase de prevención todo haya ido bien, en fase de reacción los testers deberán buscar cualquier fallo crítico y, en caso de localizarlo, rechazar la RC.
- Pruebas bajo demanda: En ocasiones es necesario realizar pruebas bajo demanda sobre una tarea en concreto. Se suele hacer cuando la tarea es compleja o crítica. De esta forma, nos podremos asegurar que no vamos a meter fallos en la RC.
- Diseño de casos de prueba: Sin casos de pruebas no se sabe qué probar. El equipo de testing deberá diseñar los casos de prueba necesarios para la validación de la RC, o para el testing bajo demanda.
- Tratamiento de bugs: Cuando en producción se localiza un fallo o un bug es necesario reportarlo. El equipo de testing tiene que reproducirlo y aportar la información necesaria al equipo de desarrollo para que lo solucionen. Un aspecto, en mi opinión, importante y a veces olvidado es que disponer del conocimiento suficiente para entender el código de la aplicación ayudará al tester a obtener más información del error. De este modo, el desarrollador invertirá menos tiempo en solucionarlo.
El equipo de testing tendrá que trabajar estrechamente con el equipo de producto y desarrollo para obtener la información necesaria que permita preparar los casos de prueba frente a posibles bugs.
Conclusión final
Durante la serie de posts, hemos visto en qué se basa la estrategia de “Prevention & Reaction”. Es una estrategia teórica, basada en mi experiencia como QA, en lo que he aprendido estos años y en cómo hoy en día enfocaría el trabajo para garantizar la calidad en un entorno de desarrollo ágil.
La finalidad de la estrategia es garantizar la calidad desde una etapa temprana. Su base principal son los datos y el análisis de los mismos, pero también puede ser su punto débil, debido a que al comienzo de la implementación de la estrategia no disponemos de los datos suficientes. No obstante, como suele ocurrir, su punto débil también es su punto fuerte.
A medida que dispongamos de más datos, la heurística de nuestro sistema de predicción de bugs será mejor y, por lo tanto, nos ayudará a reducir el riesgo de dejar pasar fallos a producción.
