La revisión del código va por detrás del ciclo de entrega / prueba

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

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

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

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

Los probadores no quieren volver a hacer la prueba es como decir "los codificadores no quieren refactorizar". Es parte del trabajo. El proceso puede reiniciarse de la siguiente manera: se crean tareas. Se genera el código. El código está probado. 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 refactoriza). Estas nuevas tareas requieren nuevas pruebas.

Si va a revisar el código en algún momento, no es más costoso hacer la revisión antes de tiempo. Y parece que tiene un proceso de prueba costoso, por lo que no desea realizar la prueba 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 la prueba no hace que el trabajo vaya más rápido. Hace que sea más lento y te tienta a entregar código mal escrito pero probado con éxito. Con el tiempo, todo este código no revisado hará que el trabajo vaya más y más lento. Luego, un competidor más eficiente ofrece un mejor producto a menor costo y se acabó el juego.

Además, automatice las pruebas. La prueba manual es tan 1970.

Si le resulta difícil realizar revisiones de código en el tiempo que tiene actualmente antes del control de calidad, debería considerar hacer que las revisiones de código sean más livianas, como lo comenta la Revisión de código en Agile Teams, Parte II que publicó @Dukeling.

Descubrí que incluso lo más simple que podría llamarse una revisión de código brindaba beneficios: antes de comprometer el código (o presionar un DVCS), llame a otro desarrollador y guíelos a través de su cambio. Esto puede tomar cinco o diez minutos. El objetivo de esta revisión de código es "¿Tiene sentido para el otro desarrollador?" El objetivo no era criticar las implementaciones de diseño o conformarse completamente con las ideas personales del revisor sobre cómo debería haber sido escrito. Le dio estos beneficios:

• Mejor conocimiento compartido de cómo funciona el código.
• Capturó código confuso o potencialmente erróneo porque el acto de explicar el código fue suficiente para que el autor reconsiderara las cosas
• Ayudó a evolucionar 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 absolutamente mejor para encontrar problemas. Pero tienes que poder hacerlas y actuar sobre ellas para obtener el valor. Un proceso liviano que puede hacer todo el tiempo puede ser más útil que un proceso pesado que se desanime o simplemente agregue cosas al trabajo atrasado.

Una solución para este problema es hacer una revisión rápida del código por parte de otro compañero 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 de código después de la prueba, cuando realice revisiones más grandes con todo el equipo.

Por lo que parece, los probadores no quieren volver a probar porque la prueba es un proceso doloroso / costoso.

La automatización de pruebas tanto por parte de desarrolladores como de evaluadores es una gran ventaja para los equipos que intentan trabajar de manera ágil. Cuanto más baratas, fáciles y reproducibles sean sus pruebas, más podrá ejecutarlas y menos resistencia tendrá para cambiar algo.

¿Has hecho un refactor rápido basado en algunos comentarios del desarrollador? Presione el botón rojo grande que ejecuta su paquete de regresión / humo y haga un manual rápido una vez más para verificar si hay problemas visuales que puedan haber surgido. ¡Fácil!

Una vez que esté en un lugar como ese, volver a realizar las pruebas no será una tarea difícil, será una segunda naturaleza.