INTRODUCCIÓN
Ya hemos hablado anteriormente en este blog sobre la estrategia Prevention & Reaction (P&R) y cómo aplicarla en el equipo con un rol como el QDev.
Ya comentamos de la importancia de que fuera una estrategia viva y adaptable, es decir, que fuéramos capaces de pivotar sin ver afectada la calidad ni la productividad del equipo.
Pero, ¿Cómo la controlamos o monitorizamos su estado?
Donde trabajo actualmente llevo unos meses intentando crear la cultura y la estrategia de calidad. Al principio hemos tenido que definir unos KPIs muy generales y monitorizar la estrategia de forma manual.
Como comienzo para ir aplicando e iterando en la estrategia no era una mala opción, pero hemos evolucionado. Se ha conseguido que los equipos sean más autónomos aplicando la estrategia definida, por lo que ya no nos vale monitorizar así.
Contaré mi experiencia sobre cómo aplico el de rol de Head of QA en otro post 😛
P&R se apoya mucho sobre el concepto de smart testing, por lo que tenemos que hacer una monitorización inteligente y con decisiones automáticas basadas en datos.
En esta serie de posts hablaremos de dos conceptos importantes dentro de la estrategia P&R:
- Balancear la red de seguridad de calidad y la productividad del equipo
- KPIs y monitorización de la estrategia
Empezaremos por el primer concepto.
¿Qué tiene que ver la productividad con la calidad?
Bajo mi punto de vista y en nuestra estrategia, mucho. P&R se basa principalmente en la prevención, y las técnicas preventivas operan en la etapa de definición y desarrollo, por lo que tienen impacto directo sobre la productividad del equipo.
La técnicas de testing que apliquemos no solo van a ayudar a “garantizar la calidad” del producto, si no, que van a ayudar a desarrollar con más seguridad y por tanto de una forma más eficiente.
Si abogamos por una responsabilidad compartida de la calidad en el equipo, no va a existir un rol (Tester, QA, QE, Test Engineer etc.) que sea el único en aplicar las técnicas de testing o en automatizar las pruebas y gestionar bugs.
Todo el equipo tendrá que aplicarlas y desarrollar las pruebas junto con el QDev, quien se hará cargo de la estrategia de calidad del equipo o del producto.
Muchos conocemos la discusión en la comunidad sobre externalizar el testing fuera de la empresa o incluso tener un equipo de calidad dentro y trabajar en un equipo multidisciplinar, pero de lo que no se habla tanto es de que también se externaliza el testing dentro de un equipo multidisciplinar.
Veamos un ejemplo:
Tenemos un equipo compuesto por 1 QA vs 4 Devs, y en la que la responsabilidad del testing (salvo los code review y unit/integration testing) es del QA. Entre sus tareas está la de gestionar los bugs, diseñar y automatizar pruebas, validar las issues, hacer testing exploratorio etc.
La velocidad de desarrollo siempre será mayor que la del QA, generando un cuello de botella y como resultado:
- Mala eficiencia
- Pérdida de calidad en el producto.
- Mayor frustración.
Podemos decir, metemos más personas de QA y por tanto reducimos el cuello de botella, todos sabemos que la matemática no es perfecta en estos casos.
¿Cómo balanceamos la productividad con el desarrollo de la red de seguridad?
¿Los desarrolladores tienen que hacer testing? Es una de las preguntas que pueden surgir en debate.
Bajo mi opinión, la respuesta es, sí. Si creemos que el desarrollador tiene que hacerse cargo de la tarea desde que la comienza hasta que está en producción, tendrá que cerciorarse de que sale con calidad.
Es decir, desarrollar la funcionalidad, diseño y desarrollo de las pruebas necesarias (unitarias, integración, funcionales, performance etc) y validar la issue etc, forma parte de la tarea y es responsabilidad del desarrollador y el code reviewer.
Esto no quiere decir que el QDev (en este caso) no tenga que hacer testing, claro que tiene que hacerlo. Su responsabilidad recae en crear la red de seguridad, para la que desarrollará herramientas y utilidades (las pruebas son consideradas herramientas) así como liderar la estrategia y la cultura de calidad dentro del equipo.
Lógicamente esto tiene un coste en lo que la estimación de la tarea se refiere, ya no solo es desarrollar la funcionalidad, por lo que una tarea que tuviera un coste subjetivo de talla M, tendría una talla objetiva de L.
¿Porqué hablo de coste subjetivo? Veamos:
Coste subjetivo en la estimación
Lo normal es estimar cuánto se tarda en desarrollar, y en el mejor de los casos también se asume el coste del CR y el despliegue a prod. Pero el problema viene en que no asumimos el coste del testing muchas veces al no estar integrado en el trabajo del desarrollador, por lo que el coste estimado de la issue no se acercará a la realidad.
Como vemos en la imagen, es prácticamente imposible estimar de forma objetiva si no se integra el testing en la fase de desarrollo, ya que se depende de la finalización de una tarea de la que es totalmente dependiente.
Si nos fijamos, esa dependencia causa un cuello de botella cada vez mayor, esto es debido a que el desarrollador necesita que se valide su issue, una vez ya la ha desarrollado, haya pasado el CR y haya desplegado en un entorno de pruebas.
En caso de un feedback negativo, deberá volver a la fase de desarrollo, CR, deploy a pruebas y volver a repetir el proceso. Un coste productivo bastante alto.
Yo siempre digo que para mí, el “fracaso” no está sólo en encontrar un error o un bug en producción, si no en el entorno de pruebas, debido a que solucionarlo tiene un coste alto, menor que el de producción, claro está.
Es por eso que creo en la necesidad de invertir en técnicas preventivas.
Coste objetivo en la estimación
Por el contrario, si se ve la tarea como el conjunto del desarrollo de la funcionalidad y el diseño, desarrollo y ejecución de las pruebas, a cargo del desarrollador, mejoraremos la eficiencia y nos acercaremos más al coste objetivo de la tarea.
Lo más importante de seguir esta metodología en cuanto al testing, es que vamos a tener un feedback temprano en fase de desarrollo, y no en fases posteriores.
Las pruebas dejan de ser jueces y pasan a ser la red de seguridad de calidad. Incluso los desarrolladores pueden trabajar con TDD, BDD etc.
La probabilidad de encontrar un fallo o un bug en fases de pruebas posteriores se verá reducida ya que se habrán detectado y arreglado en fase de desarrollo, siendo el coste productivo mucho más bajo.
El o la QDev intentará equilibrar el coste productivo y la calidad mediante el desarrollo de herramientas de testing y la estrategia de calidad del equipo.
El equipo
Para poder llegar a trabajar con este modelo, es necesario que exista una cultura de calidad dentro del equipo. Los integrantes deberán tener unos conocimientos mínimos de testing.
¿Esto quiere decir, que hay contratar desarrolladores con conocimientos de testing? No necesariamente.
El QDev tiene la responsabilidad de crear la cultura de testing, y por tanto de formar al equipo.
Cuando la responsabilidad del testing no es compartida, hemos visto cómo puede ocurrir que la productividad del equipo se vea mermada y por tanto la calidad se vea comprometida.
Vamos a ver dos gráficos donde se muestra la tendencia del valor de calidad-productividad frente al coste de desarrollo de calidad. Es decir, cuánto cuesta invertir en desarrollo de calidad, frente al valor que nos aporta.
La línea verde muestra el coste de desarrollo de calidad del equipo.
La línea morada muestra el valor de calidad-productividad del equipo.
El primero muestra la tendencia en un equipo donde la responsabilidad no es compartida. El coste de inversión se mantendrá estático, y debido a que es probable que se formen cuellos de botella, el valor de calidad-productividad llegará un momento en el que irá descendiendo.
El segundo muestra la tendencia en un equipo donde la responsabilidad es compartida y gestionada por un QDev. El coste de inversión será alto hasta que el equipo coja la dinámica y esté formado. A medida que aumenten las skills de calidad del equipo, el coste de desarrollo será menor, y el valor de calidad-productividad irá aumentando.
El trabajo del QDev consiste en ayudar a reducir el coste de desarrollo de calidad y una vez el equipo sea más autosuficiente, potenciar el valor de calidad-productividad.
Conclusiones
Cuando trabajamos en la estrategia P&R es muy importante balancear la productividad del equipo y la inversión del desarrollo de calidad.
Crear una cultura y responsabilidad compartida de la calidad dentro del equipo ayuda a trabajar de forma más eficiente, pero requiere de uno skills de testing que es probable que el equipo no lo tenga en fases iniciales.
La labor del QDev es velar por ello. Diseñar una estrategia de calidad que sirva como red de seguridad al equipo, ayudándoles a que trabajar de una forma más eficiente.
P&R es una estrategia viva y cambiante, por lo que es necesario monitorizar para ver en qué punto estamos en cada momento. Para ello será necesario definir unos KPIs que nos sirvan como punto de control.
En el siguiente capítulo veremos cuáles son los KPIs más importantes y cómo monitorizar la estrategia.
