La mejor manera de mantener sincronizados el desarrollo y las pruebas

Un enfoque que podría intentar es hacer que el control de calidad trabaje antes que los desarrolladores.

Funcionaría algo como esto:

• Los desarrolladores de back-end escriben llamadas a la API que imitan el comportamiento de la funcionalidad terminada
• Los desarrolladores de UI crean un front-end de placa de caldera que llama a la API (obteniendo resultados devueltos de los stubs)
• En esta etapa no hay código de implementación escrito, solo código de marco
• Esto debería ser rápido de hacer
• El control de calidad comienza a trabajar en la escritura de sus pruebas de integración y de extremo a extremo, utilizando el front-end de la placa de caldera y la API stub.
• Los desarrolladores se dispusieron a hacer la implementación real
• QA termina sus pruebas antes de que los desarrolladores completen
• Los desarrolladores ahora no dependen del control de calidad; pueden usar las pruebas existentes para confirmar que su código funciona como se espera.

Esto requerirá algo de coordinación y tendrá que planificar las cosas con cuidado. En efecto, es un desarrollo basado en pruebas realizado a nivel de características.

TLDR: Optimice el rendimiento y su gente se volverá en forma de T.

En primer lugar, debo abordar

¿Es este el enfoque correcto?

A lo que mi respuesta es "No preguntes a extraños en Internet. Pruébalo y verás". Agile incorpora dos conceptos que son relevantes aquí:

1. Ciclos de intento-inspección-iteración
2. Equipos autogestionados

Respecto a lo primero... pruébalo y verás. Asegúrese de tener una línea de base medible, como el rendimiento (el tiempo que lleva obtener un ticket individual de 'En progreso' a 'Terminado'). Luego pruebe el cambio sugerido durante una semana o tres. Luego mida nuevamente e inspeccione.

Sin embargo, debido a lo segundo, recomendaría encarecidamente no imponer esto al equipo. El enfoque de 'probar y ver' debería ayudar un poco en esto, pero aún deberá abordar sus inquietudes. Lo que me lleva a...

Los desarrolladores necesitan que su código se fusione con la rama de desarrollo lo antes posible para que su próxima característica [...]

A lo que mi sugerencia sería ... no salte inmediatamente a la siguiente función. La función que acaba de "terminar" puede estar lista, ¡pero aún no está terminada! En lugar de saltar a algo nuevo y acumular más trabajo en progreso, concéntrese en obtener ese boleto hasta el final primero.

Ahora, sí, los desarrolladores que no son de control de calidad no tienen experiencia con

integración de microservicios y pruebas e2e

¿pero entonces? Pueden aprender. Uno de ellos puede emparejarse con el control de calidad mientras que otro investiga por su cuenta y el tercero puede trabajar en un proyecto favorito no relacionado (por ejemplo). Al incluir el tiempo de inactividad ( optimización para el rendimiento en lugar de la utilización ), se enfoca en completar los tickets individuales mientras permite que los miembros de su equipo afilen sus sierras . De esta manera, con el tiempo, sus desarrolladores obtendrán nuevas habilidades (se volverán en forma de T) y podrán asumir algunas de las tareas de control de calidad por sí mismos, lo que permitirá al equipo obtener tickets de En progreso a Listo lo más rápido posible.

Que al final es lo que quieres, ¿no?

Una posible solución técnica aquí podría consistir en pedirles que creen una segunda rama de control de versiones. Cuando los desarrolladores creen que han terminado su trabajo, pasan a una rama de "prueba de control de calidad pendiente". Las fusiones finales en producción tienen lugar solo desde esa rama.

Esta es una estrategia que funciona muy bien para mí, como gerente de proyectos que también tiene una larga historia en el desarrollo de software puro: "que hay dos manifestaciones distintas de la idea de 'pruebas de software'". Aunque se usa el mismo término , son de hecho actividades disjuntas. Cada uno se aplica en un momento diferente, con un fin igualmente legítimo.

(1) "Desarrollo basado en pruebas" se refiere a la noción de que el desarrollador de software individual no puede "cerrar el ticket" y "aceptar su cambio" hasta que proporcione el cambio de código fuente y una prueba que demuestre no solo que su cambio funciono pero que no rompio nada. (Estas pruebas se convertirán en parte de una biblioteca cada vez mayor de pruebas que se pueden aplicar de forma automática y continua mediante "el proceso de construcción".) Esto se lleva a cabo a un nivel "bastante microscópico" la mayor parte del tiempo.

(2) El "control de calidad clásico" (a falta de un término mejor...) es una actividad independiente y más centrada en el negocio, también frecuentemente automatizada, pero de una manera diferente, que debe ser realizada por un equipo completamente separado. . Esto busca especialmente problemas visibles para el cliente y con impacto comercial "que no tienen nada que ver per se con 'el código fuente' o 'el último cambio'".

Y existe, y se pretende que exista, una relación sinérgica entre los dos. Si lo desea, "uno se enfoca en 'cómo', mientras que el otro se enfoca en 'qué'". Si ese pez equivocado va a "salir al río y causar problemas", tendrá que pasar dos redes de pesca diferentes !