TDD: Se acabó la necesidad de Testers?

Ya hablamos de Behavior Driven Development, pero qué pasa cuando los Tests guían el desarrollo?


Developer haciendo su trabajo.
TDD: Otra manera de ver el desarrollo

Buenas buenas! Cómo están? En este artículo voy a estar hablando de TDD, qué es, por qué se hace y qué significa su práctica para el tester como miembro de un equipo. Preparen un café, pónganse cómodos y vamos a eso!


TDD: Qué es?


Primero que nada, empecemos por algunas definiciones. Ustedes saben que ya hemos hablado de BDD (Behavior Driven Development), sus beneficios y uso en testing. Ahí estaba claro que el tester era uno de los "3 Amigos", junto al Business Analyst y el Developer, trabajando en conjunto para definir el criterio de aceptación y hacer el desarrollo con el testing asociado apropiadamente.


Bueno, en TDD la cosa cambia y bastante. Empezamos no por el comportamiento (behavior), sino por los tests! Así es! Es una metodología ágil de desarrollo que implica que éste comienza por la creación de tests que van a tener que hacer pasar creando la funcionalidad necesaria.


Es el famoso, rojo a verde a refactor. Esto se refiere a que, al crear los tests al principio, todos van a fallar (rojo) porque no hay nada desarrollado y luego, una vez se empieza a crear la solución, la idea es ir dejando esos tests en verde al crear lo necesario para que esto pase. Una vez todo está verde, se procede al refactor para limpiar y listo!


Pero pará...si los Devs hacen los tests, qué hace el Tester?


Ahh, esta es la gran pregunta, no? Déjenme decirles algo que leí una vez:


Los desarrolladores son muy buenos en lo que es la abstracción. Les das la mitad de un problema y ellos te van a dar una solución completa. Son tan buenos en abstraer, que de hecho ni se van a dar cuenta que solo tenían la mitad de un problema. Ellos tienen la mentalidad de construir, de solucionar. Es su trabajo resolver problemas.
Los testers, por otro lado, son más de la mentalidad de destruir. Son los que preguntan "qué onda esto?", "y aquello?", "se te ocurrió cubrir esto otro?". El tester sabe cómo romper el código antes de que siquiera se escriba. Es el trabajo del tester hacer la ingeniería inversa de los problemas.

Ahora...hay algo que no les dije. Hice un poco de trampita, lo admito. Los tests que hacen los devs trabajando con TDD son, prácticamente siempre, Unit Tests.


A ver, los frameworks de Unit Testing de hoy en día permiten hacer tests de integración o E2E tranquilamente, pero un desarrollador no tiene ni la mentalidad, ni el tiempo ni el conocimiento necesario para cubrir como se debe esos aspectos.


Así que si...TDD se refiere mayormente a Unit Testing automatizado y creado en primera instancia. Esto deja al tester en, podríamos argumentar, la mejor posición para empezar a trabajar. Con los Unit Tests hechos y pudiendo emplear su tiempo donde más valor hay: El testing exploratorio, E2E de la aplicación, complementando el profundo conocimiento técnico de desarrollador que crea los componentes con el conocimiento del sistema y el negocio que se está probando.


Conclusión


Como testers, hay obviamente espacio para nosotros en un equipo que se maneja con TDD. Diría que incluso es el mejor escenario para que podamos hacer nuestro trabajo en forma eficiente. Complementamos al Desarrollador y éste a nosotros para lograr unos parámetros de calidad altos y entregar la mejor versión posible de lo que se pidió.

82 visualizaciones0 comentarios

Entradas Recientes

Ver todo