Testing en un mundo Agile

El mundo está cambiando, cada vez más rápido. Ya te he hablado de ello cuando planteaba si ser o no ser agile. Las reglas de juego cambian, las empresas quieren reducir el time-to-market y sus clientes cada vez están más habituados a la gratificación instantánea. Quiero eso, y lo quiero ahora. Éste es el contexto: testing en un mundo Agile. Suena interesante, ¿verdad?

Tabla de contenidos

1. Desarrollo tradicional vs. Desarrollo Agile
2. Qué es el Agile Testing
3. El “Agile Testing” Manifesto
4. El agile tester
5. Resumen y conclusiones

No seguir el ritmo de tus competidores te puede dejar fuera del mercado, pero cambiar un producto rápidamente no puede ser a costa de la calidad. Eso tampoco se perdona.

Todo esto tiene profundas implicaciones en el desarrollo software. Calidad y testing van de la mano, no puede ser de otra manera.

Si un equipo cree que es ágil, pero no han cambiado nada respecto a su forma de probar, todavía queda mucho por aprender.

Desarrollo tradicional vs. Desarrollo Agile

En los proyectos software tradicionales era muy común el ciclo de vida en cascada o waterfall. Replicando los procesos del mundo de la ingeniería civil, la ingeniería del software abrazó sus dogmas. Análisis, Diseño, Programación, Pruebas, Implantación y periodos de Post-implantación y Garantía. ¿Te suena de algo?

Pero hacer software no es lo mismo que hacer casas. Cambiar la estructura de un edificio cuando ya estamos alicatando, difícilmente lo puedes hacer sin tirar todo abajo. En el mundo de software podríamos replicar el edificio, toquetear su estructura, ver cómo afectan estos cambios y decidir si tirar adelante o volver al diseño original. No es gratis, pero podemos hacer cosas muy muy diferentes.

En el desarrollo ágil, generalmente utilizamos un enfoque iterativo e incremental. Podemos ir construyendo el producto y evolucionarlo con el feedback que recibimos de sus usuarios. Claro, si estamos hablando de software productivo, hay que hacerlo con cuidado. No olvidarnos de la calidad. Porque estamos entregando software cada 15 días, o cada semana, o incluso múltiples veces al día.

Por eso debemos ir más allá del testing tradicional. Las pruebas las tenemos a múltiples niveles y no solo en una fase, como veremos más adelante. Así que, ¿cómo definirías el agile testing?

Qué es el Agile Testing

Cuando te hablo de Agile Testing, hay una serie de características que para mí van implícitas en el concepto:

• Es una actividad colaborativa que ocurre continuamente, desde el nacimiento de un producto hasta la entrega y más allá.
• Es un factor clave para la entrega frecuente de valor a nuestros clientes.
• Está enfocado en construir un producto de calidad, utilizando bucles de feedback cortos para validar nuestras hipótesis (aprendizaje validado).
• Guía el desarrollo con ejemplos concretos.
• Las prácticas refuerzan la idea de que la calidad es responsabilidad de todo el equipo.

Como ves, se requiere de un cambio de mindset, el cual te explicaré en el siguiente punto.

El “Agile Testing” Manifesto

Samantha Laing y Karen Greaves crearon en 2013 el siguiente manifesto sobre el testing. En base a dicho trabajo te cuento mi interpretación personal (hay ligeras variaciones respecto a su propuesta).

Valoramos:

• Testing durante todo el proceso sobre testing al final.
• Prevenir bugs sobre encontrar bugs.
• El entendimiento funcional sobre chequear funcionalidad.
• Construir el mejor sistema sobre romper el sistema.
• La responsabilidad del equipo por la calidad sobre la responsabilidad del tester.

Es importante aclarar que, al igual que con el agile manifesto, una de las palabras clave (y muchas veces pasada por alto) es “sobre”. Aunque se valora más lo indicado a la izquierda de dicha palabra, también hay que tener en cuenta la parte de la derecha. Veamos ahora algunas de las implicaciones de cada uno de los cinco puntos.

1. Testing durante todo el proceso sobre probar al final

Es testing es una actividad, no una fase. Por tanto, hay actividades de testing durante todo el proceso. Dan Ashby lo expone muy claramente cuando habla de continuous testing dentro del bucle de DevOps.

Y ¡ojo!, no se trata de hacer el waterfall de siempre en ciclos más cortos (sprints) y que el tester se quede feliz solo cuando “tenga mi columna en el panel Kanban”. Cada actividad dentro del flujo de trabajo requerirá distintas tareas de testing para construir con calidad, incluyendo el propio desarrollo (que es recomendable hacer utilizando TDD).

Dicho todo esto, probar al final también aporta valor y ayuda a incrementar la calidad final del producto.

Los testers no pueden trabajar hasta que el desarrollo ha finalizado, ¿de verdad?

2. Prevenir bugs sobre encontrar bugs

“Tenemos bugs porque los de QA no han probado bien”. ¿Lo has escuchado alguna vez? Así empiezan los “bailes de culpabilidad”. Vamos a centrarnos mejor en prevenir bugs, construyendo con calidad, teniendo una buena batería de pruebas (desde unitarias a pruebas de aceptación), automatizando pruebas de regresión, planteando buenos escenarios para los programadores… ¿Seguimos?

Si encontramos bugs, perfecto. Las pruebas exploratorias también tienen su lugar. Pero mejor antes de que el código esté en producción. De hecho, prefiero usar un lenguaje diferente (que ayuda a evitar malentendidos con Negocio entre otros):

• Bugs o incidencias para las anomalías funcionales o técnicas detectadas en los entornos productivos.
• Defectos para las detectadas en los entornos previos.

3. Entendimiento funcional sobre chequear funcionalidad

En los proyectos tradicionales es común trabajar con Especificaciones de Requisitos muy extensas. Se da gran importancia a tener trazabilidad y cobertura de los requisitos con las funcionalidades del sistema, lo cual se evidencia con los casos de prueba. Y esto es algo que recae normalmente en los testers.

¿Y con un enfoque agile? Todo está más difuso, queremos tener más flexibilidad y que, en definitiva, no nos ciñamos a un pliego sino que aportemos verdadero valor a nuestros clientes. Para ello, el testing debe ir mucho más que meramente chequear funcionalidad. Por medio del testing, entenderemos mejor el sistema, porque realmente estamos concretando cómo queremos que se comporte. Es decir, ¡el equipo co-crea con el cliente colaborativamente para construir el mejor producto posible! La misión del tester debe cambiar de ser un “checker” funcional a ser alguien con una gran visión funcional, muy transversal y que ayuda a su Negocio. Y lo ayuda concretando, encontrando ejemplos sobre los que luego poder construir la funcionalidad adecuada con la calidad adecuada.

4. Construir el mejor sistema sobre romper el sistema

El foco de las pruebas es construir el mejor sistema posible. Porque las pruebas enfocan el producto, alinean a Negocio y Desarrollo, fijan límites y restricciones y, por último pero no menos importante, ayudan a crear un producto de calidad.

También podemos intentar “romper el sistema”: a nivel funcional, a nivel de seguridad, a nivel de rendimiento… es necesario, pero teniendo claro lo hacemos para construir el mejor sistema posible. Ah, y no encasillemos al tester como “el que me pone piedras en el camino”.

5. Responsabilidad del equipo por la calidad sobre responsabilidad del tester

El último punto del testing manifesto va en línea con el collective ownership, no solo del código, sino de la calidad. Es algo que debemos ir interiorizando todas las personas involucradas en la ideación, diseño, desarrollo y mantenimiento de los productos. La calidad del producto es responsabilidad del equipo, empezando por la calidad del trabajo individual de cada uno de nosotros.

Calidad somos todos.

No echemos balones fuera. Cada uno que se haga cargo de sus responsabilidades y recordemos que la calidad es cosa de todo el equipo.

El agile tester

El perfil de un tester en un mundo agile tiene que evolucionar. ¡Y es algo genial! Creo que hace dicho trabajo mucho más interesante, con un rol más polivalente que el necesario para los “testers tradicionales”. Destacaría tres puntos clave para el agile tester que remarcan su importancia:

• Ayuda en la definición del producto. Haciendo las preguntas adecuadas a Negocio y/o al Product Owner, lograremos pasar de criterios de aceptación más amplios al mundo de lo concreto con escenarios, ejemplos y juegos de prueba.
• Enfoca el desarrollo. Utilizando métodos como BDD o Specification by Example sienta las bases para el entendimiento del sistema y sus pruebas funcionales.
• Ayuda en la automatización. El agile tester ayuda a automatizar las pruebas funcionales, colaborando con los desarrolladores en su implementación y en la preparación de los datos para las mismas.

Como ves, estos puntos pueden servir de guía para seguir evolucionando las competencias de un buen tester.

Resumen y conclusiones

El testing tradicional, una fase más dentro del desarrollo waterfall, ya no tiene sentido en un mundo agile. Ahora es más necesario que nunca probar continuamente, porque es una de las claves para mantener la calidad de los productos, que evolucionan a una velocidad vertiginosa.

Para ello, es necesaria una evolución hacia el “agile testing” con su consecuente cambio de mindset. Este cambio de paradigma queda reflejado en el agile testing manifesto que te he explicado en este artículo.

El agile tester, puede ser una figura que aporte mucho valor a un equipo: ayudando en la definición del producto, enfocando el desarrollo y ayudando a la automatización de pruebas funcionales. Definición, ejecución y automatización de pruebas, para construir un producto de calidad.

Ahora te toca poner a prueba este artículo. ¿Le has encontrado algún bug? Todo feedback es bienvenido así que ¡anímate y deja tus comentarios! Y si te ha gustado el artículo, compártelo en redes sociales.

Be agile, my friend!