En este artículo de se hace una muy breve descripción a cerca del tipo de operaciones que típicamente realizan los "equipos integradores de sistemas", y como impacta su función dentro de entornos Agile.
Ya en uno de mis antiguos artículos menciono la particularidad de este tipo de equipos y sus miembros, ubicados en distintos roles, pero todos colaborando en el 'Big Picture Testing'.Detrás de grandes desarrollos existe una gran complejidad en relación a la integración y aunque es una ventaja gestionar este tipo de trabajo desde el inicio, no siempre puede ser realizado "derecho" ni en poco tiempo o sin esfuerzos enfocados en la actividad.
....analizandolo desde un punto de vista XP o Scrum purista, cualquier actividad extra que se realizare fuera del Sprint es una actividad tercerizada, es decir que bajo estos preceptos el Testing de Releases por un equipo diferente al de desarrollo, sería una forma de trabajo que en términos de Lean se consideraría DESPERDICIO (Waste).
Tiempo atrás supe reflexionar ... y darme cuenta que es posible que la idea de "Ultimate Test" como WASTE, sea válida únicamente si se piensa y organiza el trabajo de manera "tradicionalista". Es posible que el traspaso de trabajo de un equipo a otro sea provechoso utilizando algunos enfoques diferentes en la gestión en toda la cadena de desarrollo, evitando el trabajo desacoplado típico del trabajo en cascada.
Por ejemplo, utilizando un enfoque ATDD un equipo de pruebas de Releases puede participar desde las fases iniciales en la generación/validación de las Pruebas de Aceptación para satisfacer los Criteria Mínimos de Viabilidad y Calidad de las User Stories. Así se unifican los criterios y se estandariza el conocimiento acerca del producto con enfoques y conocimientos complementario. Una consecuencia valiosa sería el fenómeno de Irradiación de la Información desde el momento en que se genera, por cuanto se amplificaría la interacción de los equipos de pruebas de releases con los equipos de desarrollo.
Por su lado, hay un enorme beneficio obtenido por el solo hecho de traer tempranamente a la mesa la discusión de "como lo probamos", lo que implica obtener respuestas a niveles de pruebas unitarias y de funcionalidad en base a salidas esperadas para satisfacer los criterios de aceptación. A este mismo conjunto de pruebas iniciales debemos sumar las pruebas para integración, lo cual muy irracionalmente suele dejarse de lado hasta el final desaprovechando oportunidades valiosas en los momentos en que se desarrollan los productos.
Deben ser discutidos desde un inicio muchos elementos claves con el propósito de integración, como virtualizaciones de entornos de pruebas y conjunto de datos, políticas de respaldo y restauración, métodos, técnicas y procedimientos para instaladores manuales o automáticos, distintos escenarios posibles, etc. También pruebas de conectividad a bases de datos e interacción entre distintos sistemas y subsistemas.
... la dificultad podría residir en que debe existir el compromiso de los equipos de desarrollos en aprender sobre la actividad del Testing en sí, facilitando el enfoque de pruebas exploratorias en un principio y por ejemplo su consiguiente generación de test-charters, los cuales para un equipo de pruebas de releases serían documentos vivos de las pruebas ejecutadas, defectos encontrados, problemas y riesgos detectados, como también soluciones obtenidas.
Me alegra saber que tanto Janet Gregory como Lisa Crispin, comparten la idea de que no todo lo que se desarrolla en los Sprint puede ser validado por únicamente pruebas unitarias, ni únicamente por baterías de pruebas funcionales automáticas, ni únicamente por los equipos Scrum.
Artículo original en Continuous integration testing: Challenges and solutions
No hay comentarios:
Publicar un comentario