La revisión del código se retrasa con respecto al ciclo de entrega / prueba

14

En nuestro proceso Agile tenemos Sprints de 2 semanas. Las tareas se entregan diariamente (compilaciones diarias), y el equipo de pruebas completa sus pruebas inmediatamente al día siguiente o incluso al mismo día.

También tenemos revisiones de códigos de desarrollo, que requieren algo de tiempo (1-2 horas), por lo que están programadas 3 veces a la semana: de lunes a viernes. Los desarrolladores se reúnen y sugieren cómo mejorar / refactorizar el código.

Nuestro problema es que, cuando los elementos de acción aparecen después de una revisión del código, la mayoría de las tareas ya se han probado. Los evaluadores no quieren volver a probar lo que ya pasó sus pruebas. No les importan los cambios internos de desarrollo.

¿Estamos malinterpretando el proceso Agile? ¿Las revisiones de código son incompatibles con un ciclo diario de lanzamiento / prueba? No podemos realizar revisiones de códigos todos los días, ya que ocupan el tiempo de todos.

    
pregunta gene b. 06.08.2015 - 22:27
fuente

5 respuestas

8

Los evaluadores no quieren volver a realizar la prueba es como decir "los codificadores no quieren refactorizar". Es parte del trabajo. El proceso se puede replantear como algo así: se crean tareas. Se genera código. Se prueba el código. Se revisa el código. Las imperfecciones se encuentran en el código. Se crean nuevas tareas para abordar estas imperfecciones (por ejemplo, el código se refacta). Estas nuevas tareas requieren nuevas pruebas.

    
respondido por el John 06.08.2015 - 22:55
fuente
7

Si va a revisar el código en algún momento, no es más caro hacer la revisión antes de tiempo. Y parece que tienes un proceso de prueba costoso, por lo que no quieres probar dos veces. Por lo tanto, es más barato revisar el código antes de realizar la prueba. Revisar el código después de las pruebas no hace que el trabajo sea más rápido. Lo hace más lento y lo tienta a entregar un código mal escrito pero probado con éxito. Con el tiempo, todo este código no revisado hará que el trabajo sea cada vez más lento. Luego, un competidor más eficiente entrega un mejor producto a menos costo y se termina el juego.

También, automatice las pruebas. La prueba manual es tan 1970.

    
respondido por el kevin cline 07.08.2015 - 03:55
fuente
5

Si le resulta difícil que las revisiones de código se realicen en el tiempo que tiene actualmente antes del control de calidad, debería considerar hacer que las revisiones de código sean más ligeras, como Code Review en Agile Teams, Parte II que @Dukeling publicó discusiones.

Descubrí que incluso la cosa más simple que podría llamarse una revisión de código brindaba beneficios: antes de ingresar un código (o insertar un DVCS), llame a otro desarrollador y repáselo. Esto puede llevar cinco o diez minutos. El objetivo de esta revisión de código es "¿Tiene esto sentido para el otro desarrollador?" El objetivo no era conocer las implementaciones de diseño o ajustarse completamente a las ideas personales del revisor sobre cómo deberían haberse escrito. Dio estos beneficios:

  • Conocimiento compartido mejorado de cómo funcionaba el código
  • Se detectó un código confuso o potencialmente erróneo porque el hecho de explicar el código fue suficiente para que el autor repensara las cosas
  • Ayudó a evolucionar gradualmente los modismos y el estilo del equipo, porque facilitó la explicación de las cosas
  • Muy pocas quejas del equipo

Las revisiones de código más profundas funcionan mejor para encontrar problemas. Pero tienes que ser capaz de hacerlos y actuar sobre ellos para obtener el valor. Un proceso ligero que puede hacer todo el tiempo puede ser más útil que un proceso pesado que se postergue, o simplemente agregue cosas a la acumulación.

    
respondido por el Alan Shutko 07.08.2015 - 05:17
fuente
1

Una solución para este problema es hacer una revisión rápida del código por parte de otro igual una vez que la historia del usuario haya finalizado, para que no haya errores básicos / obvios en el código.

Pero esto tiene que suceder antes del ciclo de prueba. Luego, habrá menos cambios en el código después de la prueba, cuando realice revisiones más amplias con todo el equipo.

    
respondido por el Low Flying Pelican 07.08.2015 - 05:40
fuente
1

Por lo que parece, los evaluadores no quieren volver a realizar pruebas porque las pruebas son un proceso doloroso / costoso.

La automatización de pruebas tanto de desarrolladores como de evaluadores es una gran ventaja para los equipos que intentan trabajar de forma ágil. Cuanto más baratas, fáciles y reproducibles sean sus pruebas, más podrá ejecutarlas, y menor será la resistencia a cambiar algo.

¿Ha hecho un refactor rápido en base a algunos comentarios de desarrolladores? Presione el botón rojo grande que ejecuta su conjunto de regresión / humo y haga un rápido repaso manual para detectar cualquier problema visual que pueda haber surgido. ¡Fácil!

Una vez que estés en un lugar como ese, volver a probar no será una tarea, será una segunda naturaleza.

    
respondido por el f1dave 10.08.2015 - 08:19
fuente

Lea otras preguntas en las etiquetas