Mejores prácticas sobre la estrategia de prueba para un equipo Scrum

Scrum menos el plan de prueba es igual a POC con esteroides.

Hoy en día, la mayoría de los proyectos exitosos comienzan con una Prueba de concepto (POC), una evaluación de tamaño relativamente pequeño de una idea, donde la tecnología elegida y el paquete de características se verificarán primero, se evaluará el impacto potencial en los usuarios comerciales y luego, una vez probado. digno de inversión, se asigna un equipo de proyecto de tamaño completo para diseñar y entregar el producto con todas las funciones e implementarlo en producción.

Este es el caso perfecto para un equipo Scrum. El equipo puede desarrollar rápidamente el prototipo, agregando características nuevas sustanciales en cada sprint, mientras que los usuarios comerciales pueden ver en tiempo real el progreso rápido y cómo se construye la idea desde cero en solo 10 sprints. Deja una fuerte impresión (que es el objetivo principal del POC de todos modos), pero también tiene una propiedad importante: actividades de prueba mínimas o nulas, e incluso pensar en el proceso de prueba sería una broma.

No es una actividad divertida dentro de un equipo Scrum, y a la gente le gustará la idea de desarrollar sin procesos que los ralenticen. Esto es básicamente lo que cualquier actividad de prueba hará implícitamente. ¿Y quién quiere una lentitud innecesaria durante el tiempo que más necesitamos para impresionar al usuario final?

El estado que sucede si el equipo del proyecto continúa de la misma manera después de que finaliza el período de POC es algo que suelo llamar POC con esteroides : un sistema de producción que crece en tamaño y características, pero que aún se comporta como un POC: un aspirante a producto completo con defectos ocultos y casos de esquina sin explorar, solo esperando un accidente grave.

Pero antes de que se convierta allí, el equipo tendrá más dificultades de sprint a sprint para mantenerse al día con versiones estables, ya que solucionar los problemas continuos se volverá más complejo.

Aquí hay algunas técnicas que demostraron funcionar cuando estaba lidiando con problemas similares y que creo que pueden nombrarse como las mejores prácticas para implementar procesos de prueba sólidos, aún sin saturar demasiado el progreso del desarrollo, porque eso es lo que todos queremos ser. un equipo Scrum.

Distribuir el dolor

¿Dónde más deberíamos comenzar cuando se trata de molestias innecesarias que dividir el dolor :).

Y lo que quiero decir con esto es crear un plan que requerirá una pequeña actividad adicional de los desarrolladores aquí y allá, pero que contribuirá en gran medida al objetivo común con el tiempo, de manera incremental pero constante.

#1. Desarrollar código de prueba de unidad para cada pieza creada de código nuevo

Si logra convencer a sus equipos de scrum para que agreguen a su cláusula de definición de hecho el desarrollo de pruebas unitarias para cada nuevo código creado dentro del sprint, entonces, desde una perspectiva a largo plazo, será un gran logro.

Las razones son bastante obvias:

Obligará a los desarrolladores a pensar en varias rutas no estándar del código. –

• Dichas pruebas unitarias se pueden conectar a canalizaciones DevOps automatizadas y ejecutarse con cada implementación en el entorno de desarrollo o prueba. Además, las métricas de la tubería se pueden exportar fácilmente y luego usar para demostrar a los usuarios comerciales la cobertura porcentual de los casos de prueba directamente vinculados al código fuente.

Lo más importante es empezar muy pronto. Cuanto más tarde comiencen a desarrollarse las pruebas unitarias, más distraído será para los desarrolladores agregarlas dentro de un sprint.

• Requerirá un esfuerzo significativo desarrollar pruebas unitarias hacia atrás para el código ya existente. Algunas partes del código pueden ser creadas por otro desarrollador y el conocimiento exacto de cómo debería funcionar en cada parte del código no está exactamente claro para el desarrollador actual. En algunos casos, puede llegar tan lejos que agregar una prueba unitaria al código modificado llevará más tiempo que desarrollar el cambio de función para el sprint (que es un estado que nadie calculó durante la planificación del sprint con seguridad).

#2. Cree una rutina para ejecutar todas las partes de las pruebas unitarias en el entorno de desarrollo

Incluso antes de crear una solicitud de incorporación de cambios para fusionar el nuevo código en la rama Maestra, será una actividad estándar probar tanto el código de característica como el código de prueba de unidad en el entorno de desarrollo. Al hacer esto se asegurará que:

• El código de prueba de unidad funciona realmente para cada parte (al final, es solo otro código que debe verificarse). Este paso muy a menudo se omite por completo. De alguna manera, se supone que si la prueba unitaria se conecta de todos modos a la canalización de DevOps, finalmente se ejecutará y probará en algún lugar de forma predeterminada. Sin embargo, esto no es más que llevar los problemas a los niveles superiores de las actividades de sprint, donde el equipo suele tener menos tiempo y más estrés para terminar cada historia comprometida.
• El desarrollador prueba el nuevo código de característica para la funcionalidad básica. Obviamente, no se puede esperar de esta prueba que la funcionalidad comercial se verifique por completo, pero al menos esta prueba confirmará que el código se comporta de la forma en que el desarrollador lo pretendió (ignorando, por ahora, el hecho de que la lógica comercial podría entenderse incorrectamente durante el desarrollo).

#3. Espere la ejecución de la prueba unitaria después de que el código se fusione con la rama maestra

Una cosa es tener un código funcional en la sucursal local (donde nadie más que el propietario de la sucursal está desarrollando una nueva función), pero otra completamente diferente es tener el mismo código funcionando después de la solicitud de incorporación de cambios y fusionarlo con la rama maestra.

La rama maestra contiene cambios de otros miembros del equipo de Scrum, e incluso si los conflictos se resuelven y todo se ve bien, el código después de la fusión y la resolución de conflictos sigue siendo básicamente una pieza de código sin probar, y es arriesgado enviarlo más sin verificar primero. todavía funciona bien.

Entonces, lo que demostró ser efectivo aquí es simplemente solicitar ejecutar la misma prueba de unidad, ya realizada anteriormente en el entorno de desarrollo, también en el entorno, que se crea a partir de la versión del código de rama principal.

Para los desarrolladores, podría ser un paso adicional que deben incluir en su vida, pero no es un gran esfuerzo ya que, en este caso, no se debe inventar nada nuevo, solo volver a ejecutar lo que ya se hizo una vez.

Ahora, este paso podría omitirse en un caso particular:

• Las pruebas unitarias automatizadas en las canalizaciones de DevOps son tan completas que ya cubren todas las pruebas manuales ejecutadas además de eso.

Si bien lograr este estado es definitivamente factible, nunca experimenté tal estado en la vida real. Probablemente les llevaría demasiado tiempo a los desarrolladores crear pruebas de unidad automatizadas tan profundamente detalladas. Podría volverse fácilmente inaceptable para el propietario del producto dejar que el equipo dedique tanto tiempo a esta actividad, ya que tendría un impacto explícito en la cantidad de historias entregadas dentro de un sprint.

Sin embargo, la preferencia por el contenido de los sprints nunca será una excusa para no hacer las pruebas unitarias, o incluso minimizarlas. Al hacer esto, el equipo se convertirá nuevamente a un estado en el que el código carece de demasiada cobertura de prueba unitaria, y luego, para ponerse al día, es posible que ya sea demasiado tarde (nuevamente, el mayor esfuerzo para completar la prueba unitaria que el real cambio de código para un sprint).

Por todas esas razones, recomendaría volver a ejecutar las pruebas unitarias en la versión del código maestro sin dudarlo. Es un esfuerzo tan bajo en comparación con el valor que traerá.

Hará la verificación final de la preparación de la rama maestra para la fase de prueba de lanzamiento. Además, ayudará a encontrar la mayoría de los errores técnicos (por ejemplo, errores que impiden que el código fuente se ejecute con éxito hasta que finalice con éxito), dejando para la siguiente fase concentrarse únicamente en la verificación de la funcionalidad comercial.

Prepárese para las pruebas funcionales

Todas las actividades de prueba anteriores llevarán a una conclusión específica: el código maestro de la rama está libre de errores técnicos y se puede ejecutar sin problemas para los flujos funcionales de un extremo a otro.

Esta es una fase que puede ser cubierta fácilmente por una sola persona, y esta persona incluso no necesita tener conocimientos técnicos.

En realidad, es mucho mejor si esto lo ejecuta alguien desconectado de los desarrolladores pero con conocimiento funcional de cómo los usuarios comerciales esperan que se comporte el código. Hay dos actividades principales a realizar:

#1. Nuevas historias de sprint dirigidas a pruebas funcionales

Idealmente, cada sprint traerá alguna funcionalidad nueva (incremento de objetivo de sprint) que antes no existía, y por lo tanto se verificará. Es importante asegurarse de que la nueva pieza de software funcione de tal manera que los usuarios comerciales estén contentos de tenerlo ahora, ya que obviamente lo esperaban con ansias durante todo el último sprint como mínimo :).

Es una experiencia tan triste cuando finalmente se anuncia el lanzamiento de la funcionalidad prometida (durante mucho tiempo), solo para descubrir el otro día que en realidad no funciona bien.

Por lo tanto, probar correctamente la nueva funcionalidad de sprint es crucial. Para que esto sea un éxito, es una buena práctica recopilar casos de prueba importantes por adelantado y de las partes interesadas relevantes (ya sea del propietario del producto o incluso de los usuarios finales) y hacer una lista de todos los casos de prueba necesarios para el contenido dentro el sprint

Esto puede parecer abrumador a primera vista, pero según mi experiencia, nuevamente es totalmente manejable por una sola persona. Dado que los sprints son en su mayoría bastante cortos (como un período corto de dos semanas), casi nunca hay demasiado contenido nuevo de todos modos, ya que el sprint también contiene actividades adicionales como historias de deuda técnica, documentación, historias de diseño/pico, etc.

Luego se ejecutan casos de prueba con el objetivo de verificar principalmente la funcionalidad deseada. Si ocurre algún problema con los resultados, solo se contacta al desarrollador relevante (el propietario de los cambios relacionados con este defecto en particular) para resolver el problema con suerte rápidamente.

De esta forma, los desarrolladores dedicarán un tiempo mínimo a las pruebas funcionales y aún podrán concentrarse en las actividades que más les gustan.

#2. Ejecución de casos de prueba de regresión

La otra parte de las pruebas funcionales será garantizar que todo lo que funcionó hasta ahora también funcionará después de la próxima versión. Para eso están las pruebas de regresión.

Los casos de prueba para las pruebas de regresión son mejores si se mantienen y revisan regularmente antes de cada lanzamiento. En función de las especificaciones concretas del proyecto, es mejor mantenerlas simples y, al mismo tiempo, cubrir la mayoría de las funcionalidades básicas y los flujos importantes de extremo a extremo que se ejecutan en todo el sistema.

Por lo general, cada sistema tiene procesos que tocan muchas áreas diferentes, esos son los mejores candidatos para casos de prueba de regresión.

En algunos casos, las pruebas de regresión incluso cubren implícitamente nuevas características en el sprint, por ejemplo, si la nueva historia en el sprint está cambiando alguna parte particular del flujo existente.

Por lo tanto, en la mayoría de los casos, no es nada complejo completar las pruebas de regresión junto con las pruebas de funcionalidad de las nuevas historias de sprint, especialmente si esto se hace regularmente antes de cada lanzamiento de producción, y la periodicidad de los lanzamientos de producción no es demasiado pequeña.

Insista en ejecutar pruebas de control de calidad antes de cada lanzamiento de producción

La prueba de control de calidad (QA) es el paso final antes de lanzar la producción y, a menudo, esta prueba se omite por no ser importante. Especialmente si el equipo de scrum se gestiona agresivamente para contenido nuevo.

Incluso los usuarios comerciales dirán que están interesados ​​en las nuevas características y no tanto en preservar la funcionalidad o mantener bajo el número de defectos. Pero, de nuevo, con el tiempo, esta es la razón principal por la que el equipo de desarrollo tendrá que reducir la velocidad eventualmente y, de todos modos, los usuarios comerciales no obtendrán lo que piden.

La prueba de control de calidad debe ser ejecutada únicamente por personas ajenas al equipo Scrum, idealmente por los propios usuarios comerciales en un entorno dedicado, que esté lo más cerca posible de la producción futura. Alternativamente, el propietario del producto puede sustituir aquí a los usuarios finales.

En cualquier caso, esta debe ser una prueba limpia y funcional desde la perspectiva del usuario final, sin ninguna conexión con el equipo Scrum de desarrollo. Presentará una vista final del producto y se usará de una manera que posiblemente nadie del equipo Scrum anticipó (no es en absoluto un caso ideal, pero definitivamente puede suceder). Todavía hay tiempo para correcciones de última hora.

Alternativamente, podría quedar claro que el equipo de scrum no entendió bien las expectativas y, en tal caso, al menos podemos acordar un plan de seguimiento, aún mucho antes del lanzamiento de producción real. De nuevo, este no es un caso ideal, pero aún es mucho mejor que admitir la falla justo después de informar un lanzamiento de producción exitoso.

¿Adónde ir después de aquí?

La aplicación de esas prácticas al trabajo diario de scrum puede llevarte seriamente a hábitos de lanzamiento de sprint más estables y predecibles, sin retrasar los lanzamientos de producción o pasar todo el sprint preparándose para el próximo lanzamiento, o incluso sin obligar a todos en el equipo de scrum a hacer algo que no hacen. Realmente no me gusta o no sé cómo hacerlo de manera efectiva de todos modos durante la mayor parte del sprint, es decir.

Pero seguro que no hace falta que te detengas aquí.

La inclusión de pruebas de rendimiento es un tema para nombrar aquí. Esos a menudo se ignoran o se consideran innecesarios, raspando en la primera ronda de "optimización de actividades de scrum". Sin embargo, siempre tuve dudas sobre cómo se puede esperar que el sistema de producción evolucione con el tiempo si no se verifica regularmente su rendimiento.

Subir un nivel también significa la introducción de pruebas automatizadas.

Ya he cubierto un grupo de pruebas automatizadas (pruebas unitarias en proceso). Sin embargo, puede desarrollar pruebas de regresión de extremo a extremo completamente automatizadas y ejecutadas por ellos mismos después de cada implementación en el entorno de prueba. Esto liberaría aún más al equipo de desarrollo de scrum, pero requiere un equipo dedicado para desarrollar y mantener tales pruebas automatizadas. Se convertiría en un trabajo constante, ya que cada vez que cambia el código de producción, algunas pruebas automatizadas existentes pueden volverse inválidas y, por lo tanto, deben actualizarse para continuar trabajando en las canalizaciones. Es un esfuerzo por el que solo unos pocos están dispuestos a pagar; sin embargo, los beneficios para el equipo de desarrollo de scrum serían excelentes.

Esos son temas que van mucho más allá del alcance de este artículo y que determinan el cronograma y el momento correctos para cada tipo de prueba mencionado aquí, para que pueda hacerlo dentro de una ventana de sprint. ¡Estaré feliz de sumergirme la próxima vez!