¿Cuál es la importancia de las metodologías ágiles para Shift Left Testing? ¿Cuáles son los beneficios que aporta Scrum en este camino?

¿Es posible lograr los cometidos del Shift Left Testing con metodologías tradicionales en proyectos de ingeniería de software? Antes que nada, quiero detenerme por un momento en el concepto de Shift Left, para lograr una comprensión cabal de la temática.

Tal como explicó Matías Fornara en este artículo, Shift Left Testing es el enfoque de expandir las actividades de testing hacia la izquierda del proceso de desarrollo, entendiendo el mismo como una línea temporal. La etimología de esta idea proviene de que en metodologías más tradicionales como waterfall, las actividades de calidad quedan más “a la derecha”, es decir, al final.

“La idea del Shift Left Testing es incluir actividades de calidad desde el principio, incluso desde que se planifican las funcionalidades, con el fin de mitigar riesgos y tener un mejor análisis de calidad en cada una de las etapas de este proceso”, puntualizó Matías.

Entonces, ¿es viable concretar estos objetivos con metodologías tradicionales? Cuando se utilizan procesos diferentes a los que proponen las metodologías ágiles de hoy día, los proyectos pueden durar meses y a veces años.

Imaginemos por un momento un proyecto de 12 meses, con etapas secuenciales y en cascada. Aquí las iteraciones se hacen en función de la construcción de software en fases, tales como: relevar requerimientos, analizar, diseñar, desarrollar, testear y poner en producción. Como resultado de esta filosofía de trabajo, posiblemente, el testing se comience a realizar recién en la fase número 8 o incluso más tarde.

En ese marco, a veces se encuentran grandes errores en fases de desarrollo avanzadas, bugs que podrían haberse evitado fácilmente en etapas más tempranas. El efecto de esto se puede visualizar sin ser un experto en el tema: incremento del tiempo necesario para la entrega del producto, con sus consecuentes perjuicios económicos, insatisfacción del cliente y también del equipo de testing y desarrollo dado el agotamiento que puede provocar esta situación.

Entonces, cuando un equipo de ingeniería software cambia esa forma tradicional de desarrollar tecnología por una ágil, se genera un cambio muy importante, radical. Implica la existencia de un Shift Left Testing de hecho. ¿Por qué? La respuesta es directa: el agilismo, y particularmente Scrum, permite trabajar en detalle para lograr consecuentes entregas de incrementos de valor, y mitigar así una importante cantidad de riesgos.

Para figurarlo, un sprint, que es el nombre que tiene la iteración en el marco de trabajo Scrum, debe durar menos de un mes. Usualmente, dura dos semanas, en las cuales el equipo debe entregar software útil, funcionando. Para ello, en ese lapso, el equipo necesita aplicar todas las fases de construcción de software, incluido el testing.

Scrum es un framework, y como tal no garantiza el resultado del trabajo. Destaco esto porque me defino hoy día como Agile Enabler: una persona que promueve que los equipos y las empresas “sean ágiles” en vez de que “usen métodos ágiles”.

Scrum: oportunidades de mejora continua

En mi experiencia, sigo viendo que hay una gran oportunidad de mejora en aquellos proyectos donde se usa el framework de Scrum, pero no se ponen en práctica los principios ágiles, la mentalidad adecuada. Fundamentaré lo anterior con base en un ejemplo concreto.

Un equipo puede utilizar Scrum, pero quedarse en el método, es decir en los eventos, artefactos y roles. ¿Qué implica esto? Que cuando tiene que generar acuerdos de trabajo de forma autoorganizada y enfocándose en agregar valor de negocio en cada sprint, trabaja de una forma en que los desarrolladores escriben código durante la mayor parte del sprint, para recién más adelante, probablemente los últimos días del sprint, pasárselos a los testers, para que ellos se encarguen en encontrar errores.

Esta situación, en definitiva, conlleva seguir aplicando lo desarrollado de modo secuencial y en cascada, pero en un periodo de tiempo más corto.

Entonces: ¿Scrum no resuelve esto? No. Absolutamente que no lo resuelve. Se necesita generar un equipo. Scrum no reconoce etiquetas de ningún tipo en los integrantes de un equipo Scrum. Por ello, cada una de las personas que lo integran deben ser responsables de construir relaciones de confianza, para luego ser “accountable” del delivery de su trabajo.

Scrum no lo resuelve, pero es un gran apoyo en ese camino

No hay fórmulas mágicas, se precisa madurez profesional, poner en práctica los 12 principios que están de Manifiesto Ágil, y los 5 valores de Scrum: respeto, compromiso, apertura, foco y coraje.

“Scrum se vincula desde el análisis e inclusión de validaciones de calidad en cada etapa. Muchas veces, esto se traduce en utilización de historias de usuario con criterios de aceptación claros que permitan entender cómo tiene que funcionar una funcionalidad o incremento de software y, por ende, cómo debemos probarlo”, esbozó Matías Fornara. “Otro artefacto de Scrum que ayuda que las práctias de shift-left permeen es el Definition of Done (DoD), es decir, que tiene que cumplir una tarea para ser considerada lista por mi equipo”, continuó.

Sé que muchos estarán buscando recetas para lograr estos objetivos y, aunque no exista una forma única de realizarlo, a veces pueden ayudar. Una receta que les puedo dar es la siguiente:

Sprint Planning

Es el momento en el cual un equipo Scrum debe entender qué valor aportará en el Sprint (Sprint Goal), qué ítems del Product Backlog están asociados a ese valor, y cómo el equipo que construye el producto va a organizar su trabajo para lograr ese Sprint Goal.

Con esto en mente, el equipo debe aprender a diseñar la estrategia constructiva de cada ítem que, haciendo una analogía con la elaboración de una torta o pastel, en vez de elaborarla por capas debe aprender a hacerlo por rodajas, tajadas (slice). Cada trozo precisa contener relleno: capa superior, inferior, etc. Con esto en el radar, el equipo va a generar su plan de trabajo, llamado Sprint Backlog.

Daily Scrum

Aquí existe la oportunidad de identificar si están “construyendo” ese pastel como planificaron. Si no lo están, deben corregir el plan, y ser críticos acerca de si están generando “porciones de pastel” que pueda ser deleitado por algún paladar.

Algunos aspectos aún más tácticos que pueden ayudar a los equipos a poner en práctica esto es que comiencen a diseñar la solución técnica en pares: un desarrollador y un tester, cada uno aportando su conocimiento, Además de poder emplear conceptos como Test Driven Development (TDD), una técnica de diseño que implica comenzar a desarrollar escribiendo primero el test unitario.

Quizás estarán pensando si eso es eficaz y eficiente. Puedo asegurar que sí, lo es, ya que permite generar relaciones entre cada integrante. Por eso es importante el trabajo en pares. Antes de pedirle eficiencia a un equipo, es necesario construir un equipo.

Backlog Refinement

Otra actividad que promueve Scrum en pos de acercar el testing al comienzo de la construcción se llama Backlog Refinement. No es un evento como el Sprint Planning, el equipo Scrum organiza dicha actividad pensando en como particionar los ítems del Product Backlog para que en el Sprint siguiente estén listos para ser planificados y accionados.

En otras palabras, identifican algunas porciones de la torta que son muy grandes, y buscan estrategia para dejarlas en un tamaño que el paladar pueda disfrutar.

Sprint Retrospective

Por último, el equipo puede centrar el Sprint Retrospective en generar nuevas hipótesis de trabajo, en consideración de ir hacia el “Shift Left Testing” o, lo que sería mejor aún, “Shift Left Relationship” entre los integrantes de un equipo de ingeniería, sea cual sea su experticia.

¿Qué opinas al respecto? ¿Coincides en que Scrum trae oportunidades de mejora continua para las actividades de prueba y QA? ¡Cuéntanos en los comentarios!

Síguenos en LinkedIn, Twitter, Facebook, Instagram y Youtube para ser parte de nuestra comunidad, y enterarte de más novedades respecto a las mejores prácticas de Scrum y shift left testing.

Otros contenidos relacionados

¿Cómo ayuda Scrum en tiempos de incertidumbre?

Scrum, un cambio de paradigma para el Testing de Software

Los 8 desperdicios de la Metodología Scrum