Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

La técnica del Test Driven Development (TDD) es bastante prometedora y ha demostrado dar resultados, sin embargo presenta importantes cambios de paradigmas y retos para su implementación exitosa. En este artículo se abordan 9 retos en la implementación del TDD y algunas ideas de cómo hacerles frente: curva de aprendizaje, cambio del enfoque de desarrollo a las pruebas, apoyo de la gerencia y dirección, dificultades con sistemas legados (Legacy), dependencias de aplicaciones externas, sesgo del desarrollador, relajarse cuando no se identificar muchos errores inicialmente, constantes iteraciones, refactorizaciones y alto costo de errores no identificados.

El Test Driven Development (TDD), es una técnica de desarrollo de software invierte el orden tradicional de las actividades de desarrollo y pruebas, de tal forma que primero se diseñan y ejecutan las pruebas, para luego a partir de los resultados desarrollar la funcionalidad. Se caracteriza por la ejecución constante de: Pruebas, definición de nuevos casos, refactorizaciones, iteraciones, integraciones y pruebas de regresión. Implica cambios de paradigmas importantes, desde el equipo de desarrollo (los programadores), hasta la gerencia y dirección de la organización.

Presentamos a continuación los 9 retos para poner en práctica el TDD y algunas ideas de cómo enfrentarlos:

1.- La curva de aprendizaje

TDD es una técnica valiosa que produce frutos, sin embargo es difícil de aprender, pudiendo tomar entre 2 y 4 meses. Los beneficios que promete son muy buenos, pero la clave está en cómo llegar hasta allí.

La técnica requiere de entrenamiento adecuado, situación que es retadora dado que la literatura existente tiende a enfocarse en problemas más fáciles de resolver que los de la vida real. Su implementación requiere de tiempo para experimentar y probar, lo cual puede resultar contraproducente de cara a los compromisos con las áreas de negocio de la organización.

Técnicas propias del TDD, como por ejemplo la refactorización de código legado, aislamiento de pruebas unitarias y aislamiento de pruebas integrales son difíciles de dominar.

El reto de la curva de aprendizaje debe enfrentarse brindando suficiente tiempo al equipo para la adopción, por lo cual debería estar libre de mayor presión para realizar sus entregas. Asimismo, los miembros más experimentados de la organización pueden hacer mentoreo, el cual se percibe como más efectivo. Para grandes compañías en las cuales el mentoreo podría no escalar muy bien por escasez de suficientes personas con la experiencia y conocimientos en TDD, se puede optar por la contratación de consultores expertos en el tema.

2.- Cambiar en énfasis del desarrollo a las pruebas

TDD implica un cambio de paradigmas en los analistas programadores, quienes deben pasar de tener un foco de constante programación de códigos de programa, a mayor énfasis en el diseño de casos, pruebas de los mismos para posterior codificación. De hecho, se estima que el 60% del esfuerzo se consume en pruebas y 40% en el código cuando se trabaja con TDD.

Esto implica lograr acuerdo en que los desarrolladores apliquen TDD, que puedan repensar la forma en que aprenden, diseñan y trabajan. Asimismo, el entrenamiento en TDD para desarrolladores es un reto dado que no está especializado en técnicas de prueba, diseño y refactorización.

Para enfrentar este reto es necesario incorporar desarrolladores con experiencia, que puedan explorar y explicar a los demás los aspectos relacionados con diseño de software y refactorización constante. Asimismo, se pueden incorporar analistas de pruebas para que trabajen con los desarrolladores y les transfieran conocimientos en pruebas de software.

3.- Obtener el apoyo de la organización

Cuando se explora un nuevo enfoque como el de TDD, se puede estar tentado a aplicarlo sin informar a la alta gerencia, pero cuidado, la adopción de TDD puede reducir temporalmente la productividad, ocasionando compromisos incumplidos y un rechazo de la técnica por parte de la organización sin siquiera haberla experimentado.

Es buscar su apoyo de la gerencia, en especial de las áreas de negocio para reprogramar los compromisos de entregas, todos los involucrados en la organización deben estar alineados con esa idea. Este apoyo es crucial, si la organización completa no cree que TDD mejorará el producto podría no tenerse éxito.

Al igual que el equipo de desarrollo, la alta gerencia de la organización debe cambiar paradigmas, como por ejemplo, anti valores establecidos como que definir los casos de prueba antes es una pérdida de tiempo o la constante presión para entregar productos de software rápido sin que los integrantes del equipo puedan tomarse el tiempo necesario para mejorar.

4.- Dificultades para adaptar código de sistemas legados

El TDD es difícil de aplicar en situaciones en las cuales se está dando mantenimiento o evolucionando sistemas legados de alta complejidad (base de código Legacy). Está demostrado que refactorizar código legado para que pueda probarse adecuadamente toma más tiempo y esfuerzo.

Por lo general estas bases de códigos tienen décadas en la organización, el saber hacer (know how) está concentrado en pocas personas, muchos de los cuales hace tiempo dejaron de trabajar en la compañía y existe documentación insuficiente. Por lo general, los programadores experimentar el tener que lidiar con código de alto grado de acoplamiento y complejo.

No existe una buena recomendación para enfrentar esta situación, otra que considerar no aplicar TDD, o en todo caso, iniciar un proyecto para reemplazar el Legacy por un sistema desarrollado de acuerdo a prácticas actualizadas de orientación a objetos.

5.- Dificultad cuando se aplica a sistemas dependientes de aplicaciones externas

TDD puede ser difícil de aplicar cuando existan dependencias con otros sistemas externos, que no están bajo el control del equipo de desarrollo, por ejemplo un Servidor FTP, Sistemas intermedios, Servicios Web, lectura de sensores, otros dispositivos de hardware.

Adicionalmente, es difícil de aplicar cuando para poder probar el software se requieren pruebas de extremo a extremo, por ejemplo interfaces de usuario, programas que usan bases de datos, dependencias de configuraciones de red, etc.

Para enfrentar este reto, se puede optar por colocar la menor cantidad de código en esos módulos y maximizar la cantidad de código que se puede probar, utilizando artificios para representar el mundo exterior (cascaron, repuestas predefinidas, dummies). Esto implica aprender a construir objetos emuladores (Dummies) y falisificar las respuestas de sistemas colaborativos, para así permitir pruebas unitarias sencillas. Está técnica puede resultar difícil de dominar por los desarrolladores.

6.- Sesgo aplicado cuando los desarrolladores diseña sus propias pruebas

Si las pruebas son diseñadas por el mismo desarrollador, los casos no identificados en código y prueba tenderían a ser los mismos, no identificando todos los posibles errores en la primera iteración y peor, podrían existir casos de funcionalidad no contemplados. De hecho, ante cualquier mala interpretación, tanto el caso de prueba como el código estarán mal diseñados.

Se puede optar por, en lugar de desincorporar del equipo a los analistas de pruebas, incorporar a estos analistas a trabajar en pares con los programadores. Bajo este esquema el analista de pruebas no realiza la inspección después que se ha entregado el desarrollo sino durante y constantemente apoya al programador revisando su trabajo.

7.- Evitar perder foco en la ejecución de pruebas e identificación de errores (relajarse)

Cuando se inicia un desarrollo, se ha observado que si en las primeras iteraciones se identifican pocos defectos (los casos de prueba pasan), el equipo podría no hacer tanto énfasis en identificar casos de prueba adicionales o en hacer menos pruebas de integración y cumplimiento, es decir, tiende a relajarse.

Para afrontar esta situación, debe hacerse énfasis en la aplicación disciplinada de una metodología única para identificar los casos de prueba, independiente de resultados iníciales positivos, revisar los casos de prueba. Aquí puede jugar un papel importante el líder de QA, quien bajo este esquema ágil pasa de ser un responsable director a ser actividades de acompañamiento y coaching a todos los programadores y analistas de pruebas.

8.- Constantes iteraciones y refactorizaciones

Una de las características del desarrollo bajo TDD, es que al estarse constantemente y elaborando programas, las constantes iteraciones y refactorizaciones son comunes. Está situación de no manejarse con cuidado implica alta posibilidad que funcionalidad que había sido probada falle.

Las respuestas que TDD recomienda para este reto es el diseño e implementación de software con el mayor grado de desacoplamiento posible, donde cada pieza de código debe cumplir una responsabilidad única. Además, los controles de versiones deben ser automatizados y aplicarse de forma disciplinada.

Otro aspecto importante es la automatización de las pruebas de regresión, pues sólo así sería posible refactorizar, probar que lo certificado funcione adecuadamente y luego seguir refactorizando. Para ello existen herramientas que permiten ejecutar pruebas automatizadas rápidamente sin mayor esfuerzo para el equipo.

9.- Alto costo de errores no identificados

El costo de errores no identificados es más alto, dado que si una condición no es identificada hasta el final, podrían requerirse modificaciones que obliguen a repetir casos de pruebas, y al haber trabajado de forma iterativa, repetir el proceso tiende a ser muy costoso.

Para minimizar este tipo de situaciones se puede optar por lo siguiente:

Incorporar a analistas de prueba especializados desde el principio.
Identificar la mayor cantidad de casos de prueba en la primera iteración.
Revisiones del diseño de pruebas.
Revisiones de los casos de prueba en iteraciones posteriores para asegurar que la identificación temprana de todos los casos.

Conclusión

El camino para adoptar TDD puede ser costoso y largo, pero la mayoría de los expertos opinan que vale la pena los beneficios que se logran, en términos del incremento de la productividad del equipo, minimización del retrabajo por errores identificados de forma tardía y la posibilidad de entregar productos de software con una menor cantidad de errores.

<< Artículo anterior: TDD Desarrollo Guiado por Pruebas

>> Siguiente Artículo: TDD Ventajas y Desventajas

¿Y tú?, ¿Qué opinas?

¿Cuáles son los retos que has tenido que enfrentar al aplicar TDD?, ¿Cómo los manejaste?, ¿Produjo buenos resultados?.

¿Buscas más información de metodologías ágiles?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de proyectos y metodologías ágiles?, entonces presiona "suscríbete" a continuación.

Tambíen puedes seguirnos al Twitter @PMOInformatica o página de Facebook

¿Estás interesado en productos amazon sobre “Test Driven Development” (TDD)?


Kanban Autor: David J. Anderson >> España (amazon.es) >> Latinoamérica (amazon.com)	Código Limpio Autor: Robert C. Martin >> España (amazon.es) >> Latinoamérica (amazon.com)	Métodos ágiles y Scrum Autor: Alonso Alvarez García y otros >> España (amazon.es) >> Latinoamérica (amazon.com)	Diseño Ágil con TDD Autor: Carlos Ble Jurado >> España (amazon.es) >> Latinoamérica (amazon.com)