“Continuous Delivery is about building Quality in !!”
MadridQA_Continuous_Delivery_Start_n
¿Qué retos plantea para el testing entrega continua?
- La velocidad en la entrega. ¿Cómo hacemos para probarlo todo?
- Enfatizamos la automatización. Tenemos procesos manuales ¿quién se encarga de toda esa automatización?
- ¿Cómo hacemos las pruebas de regresión?
El punto de partida
El punto de partida que nos presenta es el clásico gran proyecto (cientos de personas, decenas de equipos, meses de trabajo hasta La Entrega) sometido a la presión de construir un nuevo producto de referencia.
Algunos de los problemas que debían resolver desde el punto de vista de las pruebas eran:
- La mayor parte del equipo de pruebas tenía sus bases en el desarrollo sofware tradicional.
- Cada equipo de pruebas, en cada fase, tenía que volver a analizar los requisitos, ¡y así para 9 fases!
- La configuración en cada entorno de pruebas era diferente.
- Los gestores del equipo de pruebas se oponían al cambio.
- Bucles de retroalimentación entre desarrollo y pruebas muy, muy largos.
“Very long feedback loops between dev. and test”
En su conjunto la organización estaba haciendo un esfuerzo enorme para cambiar de cultura: de “gestionar muchas cosas simultáneamente” a “gestionar solo unas pocas cosas a la vez“. No sin pelea (ni sangre).
Durante más de un año la lucha estuvo igualada. Desde los primeros intentos de buscar ciclos de producción semanales (incluyendo Aceptación ¡guau!), finalmente se llegó al consenso en ciclos de 4 semanas, pasando primero por pruebas de Integración y Funcionales para acabar en las pruebas de Aceptación.
¡Duro con ello!
Pude intuir a Peter en plena acción: “esquiva, baila, esquiva, derecha, gancho, cubre, esquiva, ¡abraza!“
¿Cómo conseguir el cambio?
Su receta para esta pelea es rocosa: enfoque en el equipo como conjunto (“Whole team approach”):
- Reduciendo el número de funcionalidades que se mueven por el proceso de entrega.
- Incluyendo en cada entrega (“build process”) tantas pruebas como sea posible.
- Sacando a los probadores (“tester”) de pensar solo en documentación y casos de prueba para elevar su perspectiva hacia el producto, siguiendo los principios del “Context driven testing“.
- Adelantando al máximo las fases de pruebas previstas para después de la entrega.
- Implicando a todo el equipo en las pruebas, todos pueden aportar ¡Organiza una buena piñata de bugs! (“Bug bash“).
- Invirtiendo intensamente en gestión de la configuración y provisión de entornos (en su caso: Docker).
- Acercando a los responsables del negocio a los equipos (¡hacer piña!).
- Formación y entrenamiento en pensamiento Agile e ingeniería Lean.
¿Cuál fue el resultado?
¡Éxito! Sin duda, tras 18 meses de transformación, reajustes de equipos/procesos y “pruebas de vida”.
Así nos resume el proyecto lo que hemos hecho:
- Cambio de la cultura.
- Cambiado la percepción de lo que significa probar.
- Minimizado las pruebas tradicionales (diseño y ejecución de casos de prueba). Con ello hemos disminuido el tamaño de los equipos de prueba, reforzando los equipos de desarrollo.
- Implicado responsablemente en la calidad del resultado a todo el mundo.
- Funcionamos como un equipo, en lugar de como un conjunto de silos distribuidos por la organización.
Los números cantan: software en producción cada 4 semanas, mayor productividad del equipo y un importante descenso en los errores críticos (nos dió el dato exacto). Es decir, entrega satisfactoria del valor esperado.
En suma:
Quality is the responsability of everybody!!
Team responsibility
Fin de fiesta
La sesión se cerró con un divertido concurso, un interesante debate y un excelente “networking”.
Os destaco:
- Nos llevó 18 meses conseguir el equilibrio y el compromiso de todos. Sigue funcionando.
- ¿Habéis aplicado Scrum o Kanban? De todo. Lo más importante es que todo tiene que ser alcanzable en el ciclo. Hemos usado muy diversos ciclos.
- Tener equipos multidisciplinares (“crossfunctional”) ha sido determinante para poder involucrar a todos en diversos papeles.
- Entrega continua es pruebas de regresión, lo lleva implícito.
- ¿Qué hacía el equipo de testers tras los ajustes? Hacían testing, siempre se necesita que un ser humano interactue con la aplicacion.
Si queréis saber algo más sobre Peter, estas son sus coordenadas: @petemar5hall y Lean Software Servicies (cuando publique esta presentación, la incluiremos encantados).
¿Alguien da más?
¡Claro! ¡ El Blog de @PanelSistemas ! 🙂
