Seleccionar página

Aplicar Agile Testing en proyectos grandes y complejos.

Insights -> Tendencias y Actualidad

En este artículo compartimos nuestras conclusiones para la aplicación de prácticas Agile Testing en grandes proyectos. Agile Testing es un sabor más de los fundamentos de la filosofía Agile, en el que la esencia de las funciones de Testing no cambia; sólo los métodos y roles para lograr un mismo objetivo: contribuir a asegurar la calidad desde el inicio.

Según su definición, el Agile Testing involucra a todo el equipo de desarrollo ágil de forma temprana, continua y sostenible. Se trabaja con una perspectiva de aportar calidad (valor) desde el principio, probando y analizando código (o especificaciones) desde que están disponibles y suficientemente estables.

Así, nuestra interpretación de algunos de los principios del Manifiesto Ágil («Agile Manifesto», 2001) para escenarios de Certificación y Testing clásico es:

  • Los cambios en los requerimientos no son excepcionales.
  • Entrega temprana y continua de Software con valor.
  • La comunicación directa es la forma más efectiva.
  • El Cliente está integrado en el equipo de delivery.
  • Ciclos de vida de los entregables cortos.
  • Aproximación al producto final por iteración.

Sin embargo, una de las principales críticas que se hacen a las prácticas Agile Testing es que no son aplicables en proyectos grandes o complejos (o que no producen los mismos resultados). Por ejemplo, en entornos tradicionales, el grupo de Testing suele ser una unidad independiente dentro del ciclo de vida, tanto en función como en dependencia organizativa. Por contra, una concepción orientada a Agile Testing requiere una mayor integración de las pruebas en las fases de Desarrollo, con serios retos de cultura y organización en la composición de equipos de trabajo grandes o con roles pre-establecidos.

Es por ello que para proyectos de desarrollo de software complejos y con cierto peso de los inevitables sistemas legacy, se está consolidando el recurrir a metodologías enriquecidas mediante la adaptación de prácticas Agile.

En particular destacamos el esfuerzo de Ericsson AB con Streamline Development (SD) (libro, 2007), una metodología iterativa en la que los requisitos se establecen bajo un modelo de matriz de taxonomías o de anatomías, junto con la premisa de que todos los equipos tienen responsabilidad end to end en el proyecto … ambicioso sin duda. O como la que nos recomendaba Javier Garzás en este artículo del 2012: Feature Driven Development (FDD), una meta-metodología que incluye también un ciclo de vida iterativo e incremental como Scrum, pero orientada a equipos grandes, que contempla por ejemplo la figura del jefe de proyecto y una fase de arquitectura.

Esta deriva quedó patente durante las sesiones de la » IX Semana del CMMi y la Mejora de la Calidad TIC», organizadas por Caelum y que podéis consultar en este brillante resumen: «Algo pasa con CMMi…»

Pasarela de Holzarte

Pasarela de Holzarte

En cualquier caso, antes de incorporar prácticas de Agile Testing en nuestro proyecto, hay que cuidar algunos aspectos habitualmente ya delicados en un proceso de desarrollo y pruebas tradicional (secuencial):
  • Eliminar ambigüedades y clarificar suposiciones en los requisitos, de forma recurrente y permanente. Como al volumen de requisitos sumamos la mayor velocidad en la entrega de valor, se requerirá de un gran esmero en su gestión para no alimentar la tendencia a generar deuda técnica de estos proyectos.
  • Apoyar al usuario en la formulación de los tests de Aceptación, contribuyendo en lo posible a descubrir requerimientos nuevos, desde el conocimiento funcional de los equipos de Pruebas. (¿He oído conversación BDD?)
  • Dar más apoyo a Desarrollo en la definición, localización y cierre de una incidencia.
  • Cuidar los ratios de automatización, especialmente en las regresiones. Con las pruebas de regresión buscamos asegurar calidad y precisión sobre el comportamiento del sistema. En particular, recomendamos automatizar las pruebas de aceptación que aseguren al cliente las funcionalidades clave deseadas.
Consideramos un factor clave de éxito en Agile Testing saber ecualizar el esfuerzo en automatización de pruebas

Visualmente podemos recurrir, por ejemplo, a los cuadrantes de Agile Testing para ayudarnos a definir nuestras estrategias de pruebas.

Que es agile testing

Agile Testing Quadrants

Sin embargo, no todo es tan fácil. En @PanelSistemas sabemos por experiencia que existen algunos factores de riesgo que es necesario mimar en la aplicación de este tipo de metodologías sobre grandes sistemas:

  • Gestión de la anatomía de requisitos. Conviene prestar especial cuidado a la definición detallada de la matriz de requisitos cuando se necesita establecer interdependencias entre componentes o subsistemas.
  • Estabilidad de requisitos. Un clásico. Al manejarse un mayor volumen de requisitos es más complejo controlar el alcance de los cambios y su gestión. Además, en proyectos de larga duración (meses/años), acompasar los ciclos de requisios adquiere carácter crítico.
  • Visión global de la Arquitectura. Aplicando ciclos iterativos debemos velar por asegurar el alineamiento con la visión global de la funcionalidad y de la arquitectura del sistema. Si se pierde la visión integrada del sistema, se incrementa el riesgo de carencias de arquitectura.
  • Peso de los Legacy. Suele ser complejo aplicar ciertas prácticas Ágiles, como la Integración Continua (IC), en los sistemas heredados («Legacy») con los que deben convivir estos proyectos. Por tanto, deberemos controlar la proporción de sistemas Legacy para poder aspirar a mantener un ritmo sostenible de Agile Testing.
  • Valor de los Planes de Prueba. Si llegaran a combinarse los riesgos de requisitos (tanto en anatomía como en estabildiad), los riesgos de visión integrada del sistema o carencias de Arquitectura y un alto peso de los sistemas Legacy, la conclusión más directa es que tendremos graves problemas en la definición de los Planes de Prueba y la predictibilidad de sus resultados. Trabajemos primero en paliar estos riesgos.
«Si hay que probar, se prueba. Pero, probar ‘pa ná’ es tontería.
  • Priorización de la actividad. Los beneficios de establecer una organización con un fuerte foco en la visión extremo a extremo («e2e») conllevan una intensidad equivalente en la gestión de prioridades y expectativas. En caso contrario es fácil caer en dinámicas en las que todo pasa a ser urgente, todo el mundo está muy ocupado y el valor añadido pasa a negativo (¡Sí! ¡Desperdicio!).
  • Gestión de equipos. Al potenciar la versatilidad de los equipos, fomentando «células autogestionadas» de tamaño reducido, hemos constatado que la rotación de personas es un riesgo con un alcance potencial más delicado que en una visión tradicional.
  • Automatizar es necesario. En automatización -en general- el riesgo principal nace de una inadecuada estrategia. Incorporar prácticas de Agile Testing conduce de forma natural a no cuestionarse la necesidad de automatizar (pruebas). Sin embargo, una estrategia de pruebas equivocada puede llevarnos a escenarios en los que el esfuerzo de mantenimiento de las pruebas sea excesivo, arriesgando así el retorno de esta inversión (ROI).
Elegir adecuadamente los niveles de pruebas sobre los que
se invierte en automatización de pruebas es determinante.
«Por favor,
no realicen esta actividad en sus casas,

llamen a un profesional.»

En cualquier caso, como señala Rubén González en el blog Think Big, «...en otros casos, los métodos ágiles pueden servir de guía. Pero siempre que se apliquen de una forma explícita, se deberían adaptar de acuerdo a los skills y a la naturaleza del equipo, y nunca forzarlos de forma imperativa. Muchas veces se aplican métodos y prácticas ágiles religiosamente, perdiendo de vista lo que es verdaderamente importante: llevar a cabo una gestión adaptativa de la incertidumbre inherente al desarrollo de software, sea con un método o sin él.»

No podemos estar más de acuerdo con esta afirmación :-).

En este artículo hemos intentado compartir con vosotros conclusiones relevantes de nuestra experiencia en la aplicación de prácticas Agile Testing en grandes proyectos, aunque sabemos que el tratamiento no ha sido exhaustivo. No os quepa duda, nuestros expertos del Centro de Excelencia en SQA & Testing ya se han encargado de puntualizar: «es un tema muy extenso (toca gestión de requerimientos, gestión de incertidumbre, organización de equipos, estrategia de automatización, gestión de reporte, gestión de prioridades, visión E2E, etcétera) como para comprimirlo en tan pocas palabras».  Tenemos el compromiso de redimir esta deuda (¡a OGMA pongo por testigo…!).

Para terminar,
¿no os habéis preguntado dónde estará el Agile Test Manifesto?
Estar está, pero ¡en revisión!

 

 

Panel Testing - Centro de Excelencia

Panel Testing - Centro de Excelencia

Nuestro Centro de Excelencia en SQA & Testing (CEST) es responsable de asegurar la Calidad del Software en los proyectos que desarrollamos, así como de evolucionar nuestro Know How en esta actividad. Si quieres conocernos mejor, visítanos en esta página, o contacta con nosotros vía e-mail en esta dirección.

Comentarios

0 comentarios

Share This