¿El desarrollo y la prueba de una función se realizan al mismo tiempo en Scrum?

Supongamos que un equipo Scrum necesita implementar una nueva característica.

¿Los ingenieros de control de calidad escriben pruebas automatizadas para la función al mismo tiempo que los desarrolladores escriben el código para la función? En otras palabras, los ingenieros de control de calidad aún no tienen nada que probar, pero ¿ya están escribiendo pruebas automatizadas? Entonces, es como la práctica de TDD (donde primero creamos una prueba y luego escribimos el código), ¿verdad?

Respuestas (3)

¿Los ingenieros de control de calidad escriben pruebas automatizadas para la función al mismo tiempo que los desarrolladores escriben el código de la función?

Idealmente si. Necesita que las dos actividades sean realizadas por una colaboración entre desarrolladores y probadores. TDD es otra técnica que se puede utilizar. La idea es alejarse del comportamiento al que muchos están acostumbrados, que es que los desarrolladores escriban el código y luego lo pasen a los probadores, en etapas.

Si no puede lograr la colaboración que mencioné anteriormente desde el principio, o probar primero, o usar TDD, y todavía se encuentra en una fase de transición del enfoque anterior, al menos debe intentar reducir tanto como sea posible el tiempo entre escribir el código y probarlo y evitar que las pruebas se acumulen al final del sprint .

¡Gracias! Pero si los ingenieros de control de calidad agregan nuevas pruebas antes de que se implemente la función, CI rechaza todas las compilaciones de los demás desarrolladores (porque falta la función). ¿Bien? ¿Qué hacemos con esto?
Creo que todavía lo piensas a la antigua. Los desarrolladores y probadores no trabajan al mismo tiempo en una implementación, sino por separado. Es una colaboración. Escriben pruebas e implementación juntas en un ciclo cerrado, por lo que hay pruebas que ejercitan algo de código, luego más pruebas y más código, y así sucesivamente. Van juntos. Como tal, no debería haber casos en los que las pruebas se envíen a la rama de CI sin su implementación correspondiente.
¿Quieres decir que comparten la misma rama de git?
Sí. En última instancia, en Scrum, es el equipo quien decide cómo organiza el trabajo, incluidas las ramas que usa, etc. Pero realmente no veo la ventaja de tener diferentes ramas para la implementación y las pruebas. Normalmente deberías tener una Definición de Listo que debe ser respetada. Si tiene pruebas, es muy probable que esas pruebas sean parte de esa Definición de Listo, por lo que una rama sin la otra no refleja una función "Listo".
@Daniel En las operaciones más exitosas en las que participé, usando una forma de BDD, los escenarios de prueba se desarrollaron de manera suficientemente específica (en inglés) antes de la implementación para que los desarrolladores no tuvieran ambigüedad al traducirlos a código, e incluso no tenía Las partes interesadas técnicas revisan directamente los casos de prueba en PR para confirmar que el software hizo lo que querían.
@Daniel Al igual que con el desarrollo de funciones, las pruebas automatizadas no deben enviarse hasta que se hayan probado localmente y/o en una sucursal y estén funcionando (y pasan, y pasarán a maestro/principal cuando se presionen). Si los ingenieros de control de calidad están impulsando las pruebas de una manera que afecta a todas las ramas, solo para poder probar una sola rama, algo salió muy mal. Los ingenieros de control de calidad probablemente no necesiten trabajar en la misma rama en la que ocurre el desarrollo antes de que el ticket llegue a la fase de control de calidad (aunque hacerlo puede funcionar mejor para ciertos equipos e individuos con ciertas configuraciones).
@NotThatGuy No quise decir que los ingenieros de control de calidad están impulsando sus pruebas en el tronco y rompiendo todas las demás ramas. Pero los ingenieros de control de calidad pueden realizar sus pruebas en la rama de funciones (donde se está desarrollando la función), ¿verdad?
@Daniel No recomendaría que un ingeniero de control de calidad realice pruebas que hagan que la compilación falle en una rama en la que un desarrollador está trabajando actualmente. Eso puede dificultar la vida del desarrollador porque ver si la compilación funciona puede ser una señal valiosa y una compilación fallida puede dificultar las pruebas de los cambios por parte del desarrollador (incluso en algunos casos en los que simplemente falla debido a las pruebas). También podría hacer que la revisión sea más engorrosa y causar conflictos de fusión. Pueden trabajar en la misma rama con la que el desarrollador/equipo está de acuerdo, idealmente mientras evitan los problemas anteriores.

En el marco de Scrum, depende del equipo decidir cómo entregar los elementos del backlog. Muchos equipos adoptan un enfoque de estilo TDD/BDD, aunque esto suele ir acompañado de pruebas exploratorias y UAT también.

Cuando se trata de administrar TDD con integración continua, la respuesta a su pregunta es la ramificación . Normalmente se espera que los desarrolladores creen una nueva rama para el código que se va a incrementar y luego una solicitud de extracción para el código probado (incluidas las pruebas) para la revisión por pares. Todo depende de cómo trabaje su equipo, por lo que, en última instancia, esta es una pregunta que debe resolver su equipo de desarrollo.

¡Gracias! Pero, ¿qué pasa si los desarrolladores y los ingenieros de control de calidad trabajan en diferentes repositorios (el código está en un repositorio, las pruebas están en otro repositorio)? ¿Cómo gestionamos el CI en este caso?
Debe ignorar las pruebas fallidas en la rama de control de calidad relevante hasta que se envíe la rama de implementación correspondiente.

La respuesta a esto dependerá de la historia y la definición de hecho para su organización. Podría desarrollar la prueba para una función en un sprint y la función en otro. Del mismo modo, si su definición de hecho no incluye una prueba, se puede agregar o no una prueba más adelante.

Recomendaría que se concentre en lo que quiere hacer y use scrum para ayudarlo a lograrlo, en lugar de concentrarse en lo que scrum permite o no.

¿El desarrollo y la prueba de una función se realizan al mismo tiempo en Scrum?
RespuestasAquíPolítica de privacidad1y, 0v