Adoptar Scrum: ¿cuál es el impacto en la estrategia de pruebas?

Aunque hoy en día parece que todo el mundo comparte el interés de las pruebas de software, nos ha parecido útil insistir en ello porque la práctica de las pruebas se debe adaptar al modo ágil, sin lo cual perderemos todos los beneficios.

En relación a lo que se hace en los métodos tradicionales, la adopción de la agilidad introduce fuertes restricciones:

Se debe probar con frecuencia porque se deben entregar funcionalidades terminadas "que funcionen" al final de cada Sprint, cada 2, 3 o 4 semanas.
Como se debe probar con frecuencia, se debe probar rápidamente.
Se deben repetir sin pausa los juegos de pruebas (pruebas de no-regresión) que crecen a medida que crece el software.
Para hacer esto, la automatización es obligatoria (pero no se puede aplicar a todo).
Para tener retornos rápidos, se debe probar lo antes posible en el ciclo: el enfoque orientado a la calidad debe comenzar tan pronto como el desarrollo (a través de los UT: unit test, sobre los que volveremos más adelante). El buen desarrollador ágil también es un buen tester.

El enfoque tradicional consistente en probar cuando todo ha terminado (o se supone que lo está) no es eficaz y es un error que desafortunadamente sucede con demasiada frecuencia: se implementa un proceso de desarrollo llamado ágil (o se supone...

Tipologías de pruebas

Aunque no vamos a explorar todos los tipos de pruebas, a continuación se aborda una serie de conceptos que hay que entender.

1. Pruebas funcionales de validación

Como ya hemos visto en el capítulo dedicado a la escritura del Product Backlog, la necesidad se traduce en forma de User Stories. Cada User Story debe seguir los principios INVEST donde, como recordatorio, la última letra significa que la User Story debe ser testeable (se debe poder probar). De manera específica, es gracias a las pruebas funcionales de validación como podemos cumplir este último criterio.

Es importante recordar que una prueba de validación no es una prueba técnica.

Por lo tanto debe:

ser visible para el usuario,
no proponer una solución,
no ser interna a la función probada.

De esta manera, las pruebas que tienen como objetivo comprobar que los datos se insertan correctamente en las bases de datos, no se deben considerar como pruebas de validación, porque son internas a la función probada. La prueba debe, en resumen, centrarse en el aspecto funcional de la Story.

De manera habitual, estas pruebas se diseñan para o en colaboración con los Product Owners.

a. Criterios de validación

El primer elemento necesario para la creación de pruebas de validación es la definición de criterios de validación concretos, definidos como un formalismo que puede ser de la siguiente forma:

Condición previa (estado del sistema antes de la ejecución de la User Story) Cuando (Actor y comportamiento) Entonces (Resultado)

Este formalismo tiene su origen en el enfoque BDD (Behavior Driven Development), que defiende el uso de la sintaxis Given… When… Then.

De esta manera, imaginemos la User Story siguiente:

"Como usuario, puedo conectarme al portal de gestión de cuentas en línea para consultar el estado de mis cuentas".

De esto pueden resultar los siguientes criterios de validación:

"El usuario está desconectado. Cuando rellena su identificación, entonces accede al portal de gestión de cuentas".

"El usuario está desconectado. Cuando se rellena una pareja identificador/contraseña errónea, entonces se le rechaza el acceso al portal".

b. Los datos de prueba y escenarios

Leyendo el ejemplo anterior...

Anti-pattern: el cono del helado

El concepto de pirámide de las pruebas es particularmente interesante, porque permite caracterizar de una manera muy visual su estrategia de pruebas y compararla con lo que debería ser una estrategia ideal. Se desarrolló por Mike Cohn en su libro "Succeeding with Agile" y han participado muchos actores influyentes del escenario Ágil.

En primer lugar, comienza describiendo qué es el anti-pattern típico, todavía muy presente en un buen número de proyectos: probar el software se hace principalmente usando su interfaz de usuario (porque intuitivamente es el método que parece más sencillo), a través de pruebas que se ejecutan manualmente. Los demás tipos de pruebas de mayor nivel son escasas. En particular, las pruebas unitarias, que son pruebas automatizadas implementadas por los desarrolladores a nivel de código (desarrollaremos un poco más adelante esta noción) son, como decimos, escasas.

Si se representa el volumen de pruebas por categoría, poniendo las más costosas en la parte superior, tendremos una representación con esta forma:

La forma en "cono de helado" es apetecible... pero no sienta bien en un enfoque Ágil (todavía más que en los métodos tradicionales), porque basamos la estrategia de calidad en las pruebas más costosas de desarrollar (y automatizar), lentas...

La pirámide de pruebas ideal

Por lo tanto, una cartografía eficaz de las pruebas debería parecerse a lo siguiente:

Podemos comprobar que las pruebas unitarias constituyen la base de la pirámide. Cuanto más numerosas sean estas pruebas, más sólida será la base de la pirámide, dando en consecuencia a la aplicación una mayor calidad porque tendrá una buena estabilidad. También es importante constatar que estas pruebas sean automatizables, porque se trata de pruebas realizadas en forma de código. Por lo tanto, el coste de su aplicación y su ejecución, es poco elevado y ofrece una predisposición muy importante para detectar los problemas.

A continuación vienen las pruebas a nivel de componente o servicio, que permiten validar los comportamientos funcionales del sistema, poniendo en juego uno o varios componentes. Como se ha visto, el objetivo es poder validar la conformidad con las necesidades expresadas de manera más cercana a los componentes técnicos que implementan la lógica funcional. La ventaja de esto es que incluso si son un poco más complejas de implementar que una prueba unitaria, son fácilmente automatizables, teniendo en cuenta su rango "limitado", se deben poder ejecutar de manera independiente las unas de las otras e incluirlas muy fácilmente en su porfolio de pruebas de no regresión.

Por ejemplo:...

Los testers en el equipo Scrum

1. La prueba forma parte del equipo

Estructuralmente, los testers forman parte integral del equipo Ágil: aislarlos del resto como se hacía habitualmente en los equipos organizados alrededor de los procesos tradicionales de tipo ciclo en V es un error fatal: en la Agilidad, para poder entregar software probado en cada ciclo, la colaboración debe ser permanente con los desarrolladores y el PO y la prueba se debe hacer con un bucle de feedback tan corto como sea posible, por lo tanto durante el Sprint, no después.

Observe que la calidad es el objetivo de todos en un equipo Ágil, porque se va a pedir a los desarrolladores que pongan el acento en las pruebas unitarias.

2. Tester Ágil: una profesión en cambio

Ser tester es una profesión muy valorada en el entorno Ágil, porque el tester es un elemento central del proceso:

Ya no es un castigo o una opción por defecto.
No se improvisa ser tester: es necesario tener conocimientos metodológicos y técnicos, capacidad para entender la funcionalidad y buena comunicación.

Además, con la necesidad de automatizar se necesitan perfiles tradicionales y testers que sepan también desarrollar (por ejemplo, scripts de prueba, así como algunas veces también ir al código del software que están probando).

"Software Engineer in Test" en el enfoque Google. Son ingenieros de desarrollo especializados...

En conclusión: escriba las pruebas

Este capítulo a la vez técnico y teórico tiene como objetivo principal demostrar que la presencia de las pruebas es primordial para asegurar la calidad de su futuro producto.

La escritura sencilla de las User Stories no es suficiente. Es necesario completarlas con las pruebas de aceptación. Fundamentalmente esto va a permitir al Product Owner aceptar o no una User Story, así como dar confianza a los usuarios si perciben que el producto entregado responde a sus expectativas. Consideradas hasta no hace mucho como una pérdida de tiempo y un trabajo ingrato, hoy en día las pruebas deben ser el núcleo de trabajo del desarrollador.

Ahora que se han explorado las principales facetas de la puesta en práctica de Scrum, vamos a volver sobre un tema muy estratégico: cómo hacer que el cambio hacia Scrum sea lo mejor posible.

Probar en modo Ágil