Novena entrega de la revista “Agile Record”, esta vez titulada “Testing challenges for distributed team“. Entre muchos otros he encontrado interesante el artículo de “Chetan Giridhar & Vishal Kanaujia” sobre “Understanding Test Driven Development with Python“, o lo que es lo mismo TDD. Lo encuentro interesante porque últimamente se está hablando mucho sobre esta técnica de testing, técnica empleada por los equipos de desarrollo y que muchas veces la gente la interpretar como: “hacemos TDD, así que no necesitamos a un tester en nuestro equipo”. Pues bien, este artículo no profundiza sobre si el TDD excluye cualquier otra actividad de testing, pero al menos encontraréis un ejemplo gráfico de como debería de hacerse TDD con Python. Por otro lado este artículo no tiene nada que ver con el tema principal de la revista, pero bueno, eso ya es otro tema.

No me he podido leer todos los artículos, pero me gustaría destacar dos artículos más, el primero para los amantes de las herramientas…escrito por Éva Takács & István Forgács, titulado “Continuous integration to test large distributed systems“(por fin un artículo que habla sobre equipos distribuidos) que habla sobre la herramienta open source “ETICS” (eInfrastructure for Testing, Integration and Configuration of Software).

El otro artículo que quería destacar es el escrito por mi amigo “Toni Robres” sobre como ha cambiado el role del tester con las metodologías ágiles, pasando de ser un role destructivo en las metodologías Waterfall o con el modelo en V a pasar a ser un role contructivo en equipos con metodologías ágiles. Afirmación de la que estoy totalmente en desacuerdo. Un tester que trabaja con el modelo en V puede ser igualmente constructivo que uno que trabaje con SCRUM. Un Tester/SQA puede aportar valor en todas y cada una de las fases del ciclo de vida de desarrollo, desde la fase de elicitación hasta que se hace el roll-out. Puede aportar valor en la demanda, en la toma de requisito, instaurando herramientas de gestión de la configuración, haciendo seguimiento de las pruebas unitarias(cobertura) o haciendo revisiones de código…puede automatizar las regresiones, hacer pruebas de rendimiento o de seguridad, continuous quality improvements, etc, etc, etc…en fin, mil y una actividades totalmente constructivas. Ni las metodologías ágiles son la solución a todos los problemas del desarrollo de software ni el modelo Waterfall o en V son lo peor. Cada uno tiene sus cosas buenas y malas, todo depende de la tipología del proyecto y del sector, pero ambas pueden ser perfectamente constructivas.

Be Sociable, Share!