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.
No quería entrar en polémica, pero tenia que contestar :p
Si que es cierto que en ningún sitio del modelo en V o Waterfall se diga claramente que el tester es “destructivo”, pero en el 99 % de los casos es así.
Hay que distinguir muy bien en esos modelos el rol del QA y el rol del tester… en ese caso el rol del QA si que tiene una parte más constructiva, pero el rol del tester es puramente destructivo…
Porque digo esto cuando realmente si que se participa en las etapas de requerimientos, diseño funcional, diseño técnico…? Porque en el modelo en V “alguien” genera el requisito, y la gente de testing mediante inspecciones o revisiones le dice que esta mal del requisito o de la especificación, por lo tanto esta destruyendo ese requisito.
Porque esto no se ve así en Agile? Porque el equipo de desarrollo y de testing participan en la construcción del requisito. Es decir, el Product Owner da una idea de lo que quiere con unos criterios de aceptación, y el equipo entero incluyendo los testers, lo construyen, hasta que todos están conformes con el. Todo el equipo participa en la generación del requisito, y no solo se dedican a revisar o inspeccionar un documento con cientos de requisitos… Para en este caso reside una diferencia muy clara entre ambas metodologías.
Yo no defiendo a capa y espada las metodologías ágiles, ya que como todo tienen sus defectos, y si que es cierto que en según que contextos es más útil utilizar otros modelos. He trabajado durante años con el modelo en V y ha sido muy eficiente también, ya que tiene muchas ventajas a la hora de gestionar el ciclo de vida del proyecto, pero hay que saber ver cual puede encajar mejor en cada uno de los contextos…
No hay polémicas hombre, son diferentes puntos de vista, lo cual enriquece el debate. Seguro que muchas cosas que escribo que hay mucha gente q no comparte mi opinión.
Bueno, no pasa nada…de todos modos, creo q no se puede generalizar ya que comentas: “Si que es cierto que en ningún sitio del modelo en V o Waterfall se diga claramente que el tester es “destructivo”, pero en el 99 % de los casos es así”…¿entonces, si no lo dice en ningún sitio como es que el 99% de los proyectos son así? ¿en que te basas? es como si yo conozco dos tíos gordos que trabajan como testers en proyectos agiles y digo: “el 99% de todos los tester “agile” son gordos” no hombre, hay miles de proyectos “agile” y en algunos serán gordos y en otros no
Bromas a parte, creo q te centras demasiado en los requisitos y el modelo en V es mucho más que eso…pero bueno, yo creo q si un tester revisa los requisitos y da su feedback al usuario porque ha identificado algo en los requisitos q no tiene sentido, eso no es ser destructivo, es ser totalmente constructivo, ya que en muchos casos el requisito puede cambiar. Y por otro lado, yo he vivido como tester los proyectos “agile”, y recuerdo que lo que sería nuestro “Product Owner” nos daba los requisitos y los teníamos que implementar…no había construcción alguna, se hacía lo que el quería y punto, que para eso pagaba. Lo que quiero decir, una vez más….ni con el modelo en V los tester son destructivos y con los metodologías ágiles los testers son los salvadores del proyecto. Es complicado generalizar.
P.D: si Toni, si defiendes a capa y espada las metodologías ágiles, q se te ve el plumero
Tambien se puede ver como que el tester o el QA son “destructivo” con el objetivo de “contruir” una buena definicion del requerimiento con el objetivo de hacer una buena “defect prevention”. Ya conoceis la famosa grafica que relaciona lo que nos cuesta arreglar un defecto depende en la fase del proyecto que se encuentre …