¿Por qué es mejor empezar el testing antes que el desarrollo?

Aún hoy hay gente, generalmente aquellos que han vivido mucho tiempo bajo el “patrón” cascada, que se sorprenden cuando les digo:
-Las pruebas, cuanto antes empiecen… mejor, a ser posible que empiecen antes que el desarrollo, que empiecen desde el mismo momento que se están definiendo las necesidades. Y, desde ese momento, las pruebas acompañan casi en paralelo al desarrollo.
Hay un viejo principio, que se ha tomado mucho al aplicar estrategias ágiles, que dice que aquello que más duele debes hacerlo con mayor frecuencia. Se puede aplicar a muchos ámbitos, desde los pasos a pre o producción hasta el testing.
Quien ha vivido mucho tiempo bajo el modelo, que se recita casi de memoria, como cuando te hacían aprender la tabla de multiplicar, de requisititos, diseño, codificación y pruebas, ven como algo antinatural colocar precisamente la última fase, el Testing, en primer lugar, o, más correctamente, comenzando a la vez que la primera y continuando hasta el final.
En el blog hay un montón de post sobre este tema, desde muchos puntos de vista, quizá más “operativos”, como aquellos de “Utilizamos la novedosa técnica de TDD”… ¿Cómo? ¿Novedosa? ¿Seguro? o los de ¿ATDD? ¿BDD?… ¿Cómo? Aclarando el lío de siglas en Testing
Siempre suelo decir que el PRIMER paso para empezar a implantar y mejorar es tener claro “por qué”, por qué es bueno que use tal práctica o cualquier cosa. Esto te evita caer en “dogmatismos” en aplicar algo por moda sin saber muy bien la razón.
Es por ello, que en alguna charla, curso, etc., cuando sale este tema, hago un ejercicio de reflexión de las razones por las que es mejor empezar el Testing cuantos antes. Y estás son las razones que expongo:
– Acompañar a una necesidad (mal llamado requisito), o a una historia de usuario, de su prueba de aceptación incrementa muchísimo que todo el mundo entienda lo mismo sobre lo que se espera de ella. Esto reduce mucho, pero mucho, que al terminar su desarrollo aquello “no era lo esperado”.
– Empezar las pruebas antes del desarrollo, hablamos del ATDD/BDD/TDD, hace que el software que se construirá estará pensado para ser Testeado. Como supongo bien sabes, mucho software se construye sin pensar en su Testeo, lo que hace que haya software que no se puede Testear (más allá de las pruebas funcionales). Por ejemplo, las pruebas unitarias en mucho software son impracticables, porque el diseño lo impide, y su refactorización es altamente dolorosa, lo que lleva a las siguientes dos razones.
– Asegurar un buen diseño, derivado de lo anterior. Ejemplo claro el de antes, Testing unitario sin estructuras tipo “Inversión of Control” es prácticamente imposible. Si haces las pruebas antes te aseguras un buen diseño.
– Tener bien las pruebas hace que se pierda el miedo al cambio, a “refactorizar”, a quitar deuda técnica, a dejarlo como está “si total funciona”. Lo que tiene a medio largo plazo un efecto destructivo, el que ejemplifica el concepto de deuda técnica.
Así, resumidamente, estás son las grandes razones, en mi opinión, de peso, por las que se hace imprescindible empezar el Testing desde el primer minuto. Si se me ha pasado alguna que tu sabes, sería de gran interés que la compartas con todos en los comentarios.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023