El año pasado, en el contexto de un proyecto de grado donde estaba colaborando, vivencié muy de cerca uno de los problemas del trabajo en cascada, en un aspecto que no lo había pensado nunca. Yo hacía las de cliente, y los alumnos hacían las de equipo de desarrollo. Si bien el asunto tenía que ver con el diseño e implementación, terminé pensando cómo esto sucede también en el testing, viendo las diferencias de un enfoque de pruebas en cascada y ágil.
Al comienzo del desarrollo, los alumnos comenzaron, por decisión propia, costumbre de trabajo, o no sé por qué, a diseñar la base de datos que tendría el sistema. Estuvieron mucho tiempo dedicándose a pensar todas las formas en las que podía llegar a evolucionar el sistema a futuro, pensando así un modelo de base de datos súper complejo, y que en teoría podría almacenar todos los datos de la realidad, con suficiente flexibilidad para extenderlo a futuro.
Al final de proyecto, por miles de situaciones, el sistema se recortó muchísimo, y se llegaron a implementar funcionalidades que utilizaban muy pocas tablas en realidad.
Mi aprendizaje con esto fue que si nos ponemos a entender toda la realidad, diseñar el modelo de datos perfecto, que contempla todas las posibles vueltas de la vida. El problema es que así vamos a demorar mucho para obtener una primera versión, que tal vez podría haberse hecho simplemente con un par de tablas, brindando una funcionalidad que permitiera obtener feedback, analizar qué aspectos sirven más o menos. Lo peor, es que una vez hechas esas dos tablas, tal vez nos damos cuenta que el resto del sistema es inútil de la forma que lo veníamos pensando.
Es interesante leer técnicas de diseño de bases de datos en forma ágil, donde plantean un modelado evolutivo (como en este post, de donde tomé la siguiente imagen).
Con el testing veo algo similar. El enfoque “guionado”, en el que la tarea del tester gira alrededor del caso de prueba, tiene un problema similar. Tal vez invertimos mucho tiempo al inicio pensando todas las cosas que queremos probar, o que podríamos llegar a probar. Cuando tenemos el sistema enfrente, y comenzamos a ejecutar esos casos de prueba, tal vez no los ejecutemos todos, o tal vez nos damos cuenta que algunos de ellos tienen más valor que otros, entonces hubiese convenido darle otro foco, etc.
Por esto es que se dice que el testing exploratorio es ágil ya en su concepción (palabras de Lisa Crispin y Janet Gregory en el libro “Agile Testing”). Uno no piensa las pruebas hasta estar frente al sistema, y a medida se van pensando las pruebas, obteniendo los primeros resultados, y así evaluando qué pruebas dan más resultado que otras, uno va decidiendo cómo seguir, hacia qué lado profundizar.
Impressive posts! My blog 59N about Airport Transfer also has a lot of exclusive content I created myself, I am sure you won’t leave empty-handed if you drop by my page.