Pages Menu
Categories Menu

Posted by on Mar 30, 2016 in General | 3 comments

¿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.

Javier Garzás

Javier Garzás

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.
Javier Garzás

3 Comments

  1. Hola. Me gusta mucho este sitio web.

    Para elaborar la memoria, mi Ph.D. tutor (del trabajo de fin de grado de mi universidad, me dice:

    ” Debes seguir las fases propias de la ingeniería del software: especificación y análisis, diseño, implementación y pruebas. ”

    Me gustaría, por favor, saber cuales son las actuales fases propias de la ingeniería del software. Si en el orden correcto.

    Muchas Gracias. Felicidades por el sitio.

    • Largo de contar en un comentario, mira un post que se llama “ciclo de vida iterativo” y el agil

  2. Hola Javier, ¡excelente post!

    Agregaría otras causas más relacionadas a otros artefactos, no solo el código. O sea, si hay una arquitectura, un diseño, cualquier documento, cualquiera de ellos podrá ser mejorado, y tal como comentabas, esto ayudará a que todos entiendan lo mismo, y que todo se construya para facilitar las pruebas (lo cual facilita el mantenibilidad, por ejemplo).

    También se podrían involucrar otros tipos de prueba desde el inicio con grandes ahorros de dolores de cabeza. Si el primer prototipo ejecutable puede ser puesto bajo pruebas de performance, que validen la arquitectura, será mucho mejor a esperar a que el producto esté terminado y recién ahí darse cuenta que hay un cambio grande que se necesita para poder soportar la carga esperada. Lo mismo con cuestiones de seguridad, usabilidad, etc.

    ¿Qué dices?

    Saludos!

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This