Sobre la deuda técnica, las pruebas de software y su automatización

Siempre aprendo muchísimo cuando contacto por primera vez o visito empresas de desarrollo de software. En ocasiones me maravillan con una versión propia de Scrum en la que, respetando los fundamentos, hacen adaptaciones imaginativas que nunca se me habrían ocurrido y a ellos les funcionan. Algunas desarrollan magníficos productos para miles de clientes y trabajan animosamente día a día sin haber necesitado nunca hacer documentación. Cuando puedo, me encanta revisar con calma los tableros Kanban y las historias de usuario. En algunos casos te llaman preocupados porque no están seguros de estar produciendo software con la suficiente calidad, porque han detectado un incremento en los reportes de fallos que empiezan a desbordarles o porque temen lo que pueda suceder ante un importante cambio de diseño.

Cuando existen problemas, éstos se pueden interpretar muchas veces en términos de acumulación de deuda técnica: la consecuencia de decisiones de ingeniería que permitieron resolver problemas en el pasado a corto y medio plazo, pero que pueden repercutir negativamente en el coste de desarrollo y la calidad del producto a largo plazo. Ante el impacto de la deuda técnica en la calidad del software que se desarrolla, una respuesta lógica en las empresas que se encuentran en esa situación es que deben implantarse medidas a corto plazo para mejorar los procesos de prueba del producto. Típicamente, una de las primeras medidas que se consideran suele ser la implantación de una herramienta que permita automatizar la realización de pruebas.

Pero ¿se logra mejorar la calidad del software desarrollado al utilizar herramientas automatizadas de pruebas? Puede que sí, claro, pero también es posible que sólo acabemos con una deuda técnica mayor. Porque al fin y al cabo, tengamos herramienta o no, los ingenieros serán quienes apliquen las técnicas para diseñar las pruebas. Si las pruebas están mal diseñadas y no se tiene en cuenta toda la posible casuística de la aplicación, con una herramienta automatizada sólo obtendremos… malas pruebas automatizadas.

Si consideramos que la implantación de una herramienta podría ser adecuada, uno de los primeros retos a considerar será la elección del tipo de herramienta a utilizar. Habrá que analizar cuidadosamente las causas de los problemas detectados porque puede que terminemos intentando remediarlos con una herramienta inadecuada:

¿Puede ayudarnos una herramienta de comprobación estática de código? ¿implantamos una herramienta de pruebas unitarias? ¿necesitamos un sistema de integración continua? ¿automatizamos la gestión de las incidencias?

Para tomar una buena decisión habrá que tener en cuenta la situación de partida y la capacidad del equipo para adoptar el cambio en los procesos de desarrollo:

¿Ya estamos haciendo revisiones de código? ¿cómo se realizaban hasta ahora las pruebas unitarias, la integración y las pruebas funcionales? ¿no es suficiente con tener un pasillo más en el Kanban para gestionar las incidencias?

A veces la solución del problema vendrá de revisar y adaptar las técnicas de ingeniería que estamos utilizando para, posteriormente, introducir la automatización.

Y es que, lógicamente, la herramienta no va a realizar el trabajo por si sola y por tanto habrá un coste asociado a la implantación y posterior utilización de la herramienta. Lo ideal sería que se amortizara dicho coste con un coste de desarrollo o mantenimiento menor pero ¿cómo mediremos esos costes y el beneficio que obtendremos con la implantación de la herramienta? ¿en qué plazo se conseguirá el retorno de la inversión? Este es un aspecto crítico a la hora de conseguir que la gerencia dé el visto bueno para el cambio.

A largo plazo y si tenemos un problema de deuda técnica, la solución debe pasar por la elaboración y ejecución de un plan para identificar detalladamente y «pagar» dicha deuda. La automatización de procesos y concretamente la de las pruebas puede ayudarnos pero a priori debe contemplarse como una parte de la solución y no como «la solución».

Referencias:

Jeff Sutherland: «Technical Debt: Every Company Needs a Technical Debt Remediation Program». http://scrum.jeffsutherland.com/2012/10/technical-debt-every-company-needs.html

Joaquín Oriente: «10 preguntas que te debes hacer antes de implantar una nueva herramienta en tu organización». http://formandobits.com/2013/08/10-preguntas-a-hacerse-antes-de-implantar-una-nueva-herramienta-en-tu-organizacion/

Más información:

José García-Fanjul

Profesor de la Universidad de Oviedo

Email: jgfanjul@uniovi.es

Twitter: @jgfanjul