menu_superior

¿Automatizar las pruebas? ¡Siempre!

automatiza_siempreEste post está motivado por uno que he leído yo previamente. La verdad es que desconozco por qué apareció una notificación de la publicación de este post en en mi linkedin, pero lo leí y desde entonces he sentido la necesidad de rebatir los puntos en los que él se apoya por que me parece que el enfoque de la automatización del que habla Xavier está superado y el concepto de las pruebas automatizadas actualmente es totalmente distinto.

Los argumentos de la polémica

Son estos tres que transcribo a continuación:

  1. No automatizar las funcionalidades inestables. Estoy profundamente en desacuerdo porque creo que las pruebas automáticas pueden existir incluso antes que el código de la funcionalidad. Precisamente TDD (Test Driven Development) se basa en esto. Este tipo de enfoques garantizan que las pruebas, ademas de descubrir defectos o garantizar que una determinada funcionalidad no cambia, deben servir como “especificación” funcional del código. No quiero entrar en profundidad en la Specification by Example o “especificación por ejemplos” pero de lo que se trataría es de enriquecer las pruebas para que sirvan como una especie de requisitos que nos permitan deducir cual es la funcionalidad de un determinado producto software.
  2. No automatizar si el coste de la automatización es mayor que el aporte que va a proporcionar. Esto es muy evidente, lo que sucede es que Xavier menciona aplicaciones con 3 versiones al año y un coste de automatización de 18 horas frente a 2.  Las cuentas sobre el esfuerzo de automatización no me terminan de convencer, aunque podemos suponer que se puedan dar estos desequilibrios. Lo que no me convence de ninguna de las maneras, es que salvo firmware o software embebido en dispositivos físicos es muy infrecuente que un sistema genere 3 versiones al año. Hay ejemplos extremos de varias versiones en producción al día, incluso sin irnos tan lejos, en la mayoría de proyectos en los que he trabajado podemos tener dos versiones al mes. Quitando periodos sensibles en los que los cambios se congelen (Navidad, Rebajas, Semana Santa, etc.) eso pueden ser entre 15 y 20 versiones. ¡Al año! Obviamente con este volumen está más que justificada la automatización.
  3. No automatizar si existe mucha complejidad técnica. Éste es el que más me duele por que considero el testing como una disciplina creativa, innovadora, que debe “pensar diferente” y esto de no automatizar por la complejidad técnica es asumir que no se puede hacer, que hay un límite que no debemos intentar superar… Si no se puede automatizar, pero es necesario, hay que encontrar la manera. Para muestra, un botón

La motivación de fondo: las pruebas como algo externo

Pensando en los motivos que da Xavier para justificar los reparos a la automatización de casos de prueba yo llego a la conclusión de que considera las pruebas, automatizadas en este caso, como algo que no forma parte del desarrollo de software, como una actividad externa, que puede estar muy vinculada al desarrollo, incluso correr en paralelo, pero claramente diferenciada. Y esto está bien, es un enfoque, pero no es EL enfoque, es uno más. Yo creo que las pruebas deben tender a salir del esquema de Verificación y Validación, deben formar parte del desarrollo del producto, estar en su ciclo de vida.

El riesgo de considerar las pruebas como algo externo es volver a “la calidad es como añadir azúcar al café”, a las propuestas de proyecto con calidad y sin calidad, a las pruebas como la última fase y con el tiempo que ha sobrado después de construir el producto.

Un ejemplo muy claro: imaginemos el diseño como una actividad externa, ligada al desarrollo, pero que no forma parte de él. Tendríamos proyectos a la antigua usanza: te pones a picar con una especificación indefinida… Seguro que los que llevamos más años en esto recordamos lo que pasaba cuando las cosas funcionaban así: horas de retrabajo, mantenimientos correctivos frecuentes, defectos graves en producción, despliegues a toda velocidad que provocaban, a su vez, nuevos problemas…

En definitiva, maduremos en el testing: pensemos en las pruebas como algo intrínseco al desarrollo del producto software, hagamos los productos testeables para poder automatizar su ejecución por que es la única manera de incrementar el valor añadido, de que los productos software tengan su propia ingeniería y nos alejemos de los conceptos de industrialización e ingeniería civil que tan útiles fueron al principio y que tanto daño nos están haciendo después.

, ,

Comments are closed.