Como buen Scrum Master, debes conocer qué significa TDD y sus principios, pues Scrum nació para el desarrollo de software, y por tanto, has de conocer las posibilidades que tienes a tu alcance, los distintos enfoques existentes y las numerosas técnicas que se pueden usar para conseguirlo adecuadamente.

En el mundo Agile, la técnica TDD viene incluida en la metodología XP. Puedes indagar más sobre el término si ahondas en esta metodología.

TDD es una técnica de programación en la que se evita posibles problemas futuros que pudieran surgir durante el ciclo de vida del software en desarrollo. Básicamente, las pruebas se escriben antes de programar la funcionalidad, garantizando la calidad y la estabilidad máxima.

La técnica TDD está formada por dos procesos principales:

  1. Escribir primero las pruebas   (Test First Development)
  2. Refactorización de código (Refactoring)

Haciendo uso de la técnica TDD, buscamos un solo objetivo: tener un código limpio y reutilizable.

Refactorizando nuestro código, alteraremos su estructura, pero no su comportamiento cara al usuario final, es decir, durante la refactorización, no se arreglarán errores ni se añadirán o modificarán funcionalidades ya existentes, sino que se reestructurará el código por limpieza, exclusivamente por limpieza. No se trata pues de debuguear, si no de anticiparse a los posibles fallos que pudieran surgir a futuro.

En vez de hacer ponerse primero a escribir código a ciegas, TDD propone el hacerlo a la inversa: primero diseña las pruebas, y luego, se escribe el código.

Escribiendo primero las pruebas unitarias y desarrollando el código a medida después, para que dicha prueba sea pasada, tendremos una mayor probabilidad de obtener un software final que cumpla en mayor medida los requisitos establecidos a priori y que tenga mayor calidad en su conjunto.

El proceso sería el siguiente:

  1. Seleccionar requisito a programar.
  2. Escribir una prueba a medida para dicho requisito.
  3. Testear la prueba para forzar el fallo.
  4. Crear código ajustado a la prueba.
  5. Volver a testear la prueba con el nuevo código.
  6. Si la pasa, refactorizar el código escrito para su limpieza y reestructuración.

Output: un requerimiento finalizado con un código testado, limpio y de calidad.

Con TDD trabajamos en pequeños ciclos de tiempo para poder realizar pruebas válidas a todo el código. De esta forma, desarrollando en pequeños pasos, conseguiremos en el futuro, algo más firme y robusto.

A la hora de implementar, recuerda que: menos es más, y por tanto, el código debe ser lo suficientemente simple y liviano como para pasar la prueba que teníamos prediseñada para él. En muchas ocasiones, en la simpleza se encuentra la belleza, y en programación no podía ser diferente. Por lo que TDD sigue el principio KISS: vete a lo simple, a lo básico, a lo trivial…y deja a un lado la complejidad.

El desarrollo guiado por pruebas (TDD) proporciona mucha confianza, tanto al equipo desarrollo como a los actores implicados, ya que podrán observar de manera controlada el comportamiento que va teniendo el software conforme se le vayan incorporando nuevas funcionalidades. El propio equipo se dará cuenta, que con el paso del tiempo, sirve un código más limpio, totalmente testado, de mayor calidad y, en definitiva, con valor, con mucho más valor añadido.

Desde el punto de vista del desarrollador, TDD incrementa su productividad, hace su jornada más amena y le sube la moral profesional al irse a casa con la sensación del trabajo bien hecho.

Es importante tener en cuenta, que si se hace uso de TDD, se generarán muchas pruebas, y ese código, de una forma u otra, deberá tener un mantenimiento mínimo, por lo que ahí existe un coste de esfuerzo elevado, pues no es lo mismo mantener aseado el código de 5 pruebas, que de 500. Y por tanto, hay que intentar por todos los medios que el proceso de verificación de pruebas sea automático. Si no es así, lógicamente, las pruebas consumirán un tiempo muy valioso.

También apuntar que es complicado el hacer uso de TDD en proyectos que no nacieron bajo el paraguas de esta técnica de programación, así que existen puntos de no retorno en los ciclos de vida de proyectos en los que ya es imposible virar a TDD. Es otro dato a tener en cuenta.

A parte de la técnica TDD, podemos encontrar otras formas de enfoque a la hora de abordar el desarrollo de software. Por ejemplo, tenemos el desarrollo guiado por el Diseño (D3), el desarrollo guiado por la Funcionalidad (FDD) y el diseño guiado por el Dominio (DDD), etc… distintas formas de trabajar el software desde diferentes puntos de vista de diseño e implementación, todos ellos muy interesantes. Os invito a investigar y leer sobre ellos, pues los encuentro curiosos y a tener en cuenta. 

En cualquiera de los casos, el desarrollar software bajo criterios y estructuras prácticas existentes y probadas, garantizará una mejoría notable en los incrementos que el equipo de desarrollo vaya consiguiendo durante los ciclos, ya sea haciendo uso de TDD, de DDD, o D3. Un buen Scrum Master, deberá conocerlos todos, y cuanto más, mejor.

 

En Solving Ad Hoc te ofrecemos una experiencia a medida de tus necesidades reales de cambio y adaptación, con la Agilidad como compañera de viaje en tu Transformación Digital: