Cómo ven que a los productos de software desarrollado por un equipo Agile sean probado (testeado) por un equipo no Agile (tradicional)?

No es una locura, pasa bastante seguido. Piensen en un cliente que contrata una empresa de desarrollo Agile o varias de ellas para distintos productos y los pre-releases son enviados a otra organización diferente para el testing de sistema donde se corren exaustivamente distintos tipos de pruebas, como usabilidad, bases de datos, performance, seguridad (autenticación/ autentificación), etc.

Esta discusión la abrí hace 20 días en el grupo ScrumMaster de Linkedin y aún tiene una interesante participación, con variadas opiniones expuestas por los distintos miembros del grupo.

Lo primero que pude notar es que este planteo del testing realizado por un equipo NO AGILE a un producto desarrollado por un equipo AGILE, es algo que en realidad no viene a ser muy común en el mundo del desarrollo del software. Al menos puedo tomar esta deducción en base a que no muchos se animaron (en relación con otros debates) a participar y a su vez, los que participaron, no ofrecieron muchas variantes, desde el punto de vista de experiencias reales con este formato que propuse.

Desde una perspectiva defensiva hacia el equipo Scrum pareciera ser importante evitar a toda costa la irrupción de parte del equipo de testing al equipo de desarrollo y es entonces cuando el verdadero desafío tiene que ver en como resolver situaciones en la que se detectan errores de severidad alta, que tienen estrecha relación con el trabajo “ya finalizado” y requiere modificaciones importantes o cambios en las características originales desarrolladas en Sprints anteriores.

Dicho de manera gráfica, si el equipo independiente de testing detecta issues debe tener en claro que bajo Agile, lo que el equipo de desarrollo ya liberó, no puede ser modificado y cualquier mejora o cambio, requerirá de la introducción de nuevos elementos al backlog del producto y la gestión correspondiente.
Entonces una solución podría ser que el pre-release existente se transforma en un pre-release con issues conocidos y se refleja en las notas del incremento.

Pero que sucede en escenarios en los que el cliente entrega la potestad al equipo de testing independiente, de determinar si el producto se puede liberar o no.

Es sabido que hay organizaciones que exigen que sus productos críticos sean evaluados para la superación de ciertos criterios de calidad a los cuales llaman “Portales de Calidad”, los cuales solo pueden ser superados por el equipo de testing siguiendo los tradicionales planes de calidad y testing de proyectos también tradicionales. Esta situación sin duda pone en una posición precaria al equipo de desarrollo Agile, políticamente hablando.

Desde el punto de vista de Agile, se podría plantear también que mientras el equipo de testing se concentra en registrar issues de iteraciones pasadas, el equipo de desarrollo se concentra en generar un nuevo incremento funcional de valor para el cliente y cabe la posibilidad de que la resolución de la mayoría de los issues detectados por testing, carezcan de algún valor para cliente en Sprint posteriores.

Diferencias metodológicas

Un punto muy importante a considerar es la gran diferencia metodológica del proceso de testing entre un equipo de Testing-Agile y un equipo de Testing-Tradicional. Mientras que los primeros cobran vida y sentido en las mismas fases del desarrollo del producto (para este ejemplo en particular) los segundos tienen sentido cuando el producto ya existe y debe ser evaluado.
Metodológicamente hablando, el Testing-Agile no sería tan exigente en cuanto a la documentación requerida para realizar las pruebas de software, no exigiría un plan detallado, ni evidencias basadas en casos de pruebas del tipo script ejecutadas en determinados ciclos, ni pedirá métricas del testing.
En contraposición, el Testing-Tradicional sería exigente en todos esos aspectos y muchos más para determinar la cobertura de pruebas y calidad para el productos. También habría un plan detallado y varios puntos de control a respetar exaustivamente.

Variaciones de esta naturaleza, exige la comunicación entre ambos equipos y la consiguiente negociación para facilitar los hitos de liberación.
Dicho de otra forma, la colaboración del equipo Agile puede no ser una responsabilidad contractual, pero si es una necesidad imperiosa que el equipo Agile proporciones principalmente su know-how del dominio.

Y por otro lado considero una gran responsabilidad para con el mismo equipo de desarrollo, favorecer que sus creaciones sean correctamente interpretadas y evaluadas. No cabe la posibilidad de un desentendimiento o el mismo trabajo ya “hecho” fracasará por la sola falta de colaboración entre equipos.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s