Pruebas ágiles o Agile testing. Equipo feliz, clientes contentos

Pruebas ágiles o Agile testing. Equipo feliz, clientes contentos

¿Qué es ágil?

Antes que nada, recordemos el significado de Ágil.

La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulento.

agileallieance.org

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Uno de los 12 principios de "Agile Manifiesto"

Con este enfoque, un producto que se crea usando metodologías ágiles debe ser adaptable, es decir, responder al cambio en un ambiente turbulento. Esta respuesta al cambio nos permite crear productos que sean sustentables. Más abajo se describe a que nos referimos como sustentable.

¿Qué son las pruebas ágiles?

Pruebas ágiles son técnicas esenciales en el desarrollo de software que implementan los principios y prácticas ágiles.

Una de las prácticas ágiles para implementar el principio de adaptación al cambio son las pruebas ágiles.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Uno de los 12 principios del "Agile Manifiesto"

Las pruebas ágiles mejoran la agilidad porque nos permite crear un producto con un mejor diseño, más entendible y en general de mejor calidad. Esto promueve un fácil mantenimiento y la adaptabilidad en una ambiente súper cambiante. Lo que nos lleva a menores costos financieros.

Cuando hablamos de pruebas ágiles hablamos de varias técnicas y de diferentes tipos de pruebas, como pueden ser TDD, BDD, las pruebas unitarias, funcionales, de integración, de rendimiento, de usabilidad, etc.

¿Qué significa sustentable o sostenible?

Se refiere a algo que está en condiciones de conservarse o reproducirse por sus propias características, sin necesidad de intervención o apoyo externo.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

Uno de los 12 principios de "Agile Manifiesto"

Siempre deberíamos preguntarnos a nosotros mismos si estamos creando productos sustentables, que se adapten al cambio fácilmente.

Características de las pruebas ágiles

Como ya hemos descrito hasta este punto, existen muchos principios que se relacionan muchísimo con el uso de pruebas ágiles. Hago hincapié, las pruebas ágiles se basan en principios ágiles.

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Uno de los 12 principios del "Agile Manifiesto"

Es una ilusión, nos engañamos a nosotros mismos, cumplir con la fecha de entrega dejando de lado la calidad. Tirando las buenas prácticas como Desarrollo guiado por pruebas (TDD ) o Desarrollo guiado por comportamiento (BDD), y creando código en el último minuto. Eso no es desarrollo ágil, aunque se pudiera obtener velocidad a corto plazo, el costo a mediano y largo plazo es muy grande para el negocio y/o stakeholders. ¿Eso es la descripción de un software con verdadero valor para nuestros clientes?

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Uno de los 12 principios del "Agile Manifiesto"

El software funcionando es la medida principal de progreso.

Uno de los 12 principios del "Agile Manifiesto"

Guían al desarrollo a través de especificaciones claras

TDD y BDD son técnicas ágiles, pero si nos fijamos en sus definiciones, la frase principal es "Desarrollo guiado por", así es, no se trata de pruebas, se trata del desarrollo y las pruebas son una parte que integra al todo, las pruebas forman parte del desarrollo. Y aunque técnicamente son pruebas, realmente son especificaciones de como debe funcionar el software.

Existe un hecho importante y que se nos olvida a la hora de indicar que una funcionalidad está terminada, si las pruebas no están terminadas y las pruebas son parte del desarrollo, entonces la funcionalidad tampoco puede estar terminada.

¿Cómo podemos entregar software funcional y como podemos decir que estamos progresando si en realidad no estamos entregando ninguna funcionalidad "Terminada" a nuestros clientes?

De hecho creo que TDD es una mala definición, no debería tener la palabra prueba (Test). BDD es una evolución de TDD para tener una perspectiva más hacia el cliente y el negocio, precisamente es una mejora en el nombre, más centrado en darle un verdadero valor a un software.

Relación con Individuos y colaboración

A veces perdemos el enfoque dentro de una metodología o framework ágil, nos centramos mucho en los procesos y las herramientas, cuando siempre debemos darle prioridad a los individuos (las personas) y las interacciones sociales que se producen. Estos individuos son los que genera las especificaciones del software.

Olvidamos de las prácticas de colaboración y de las prácticas de desarrollo técnico que nos permiten establecer la calidad, la arquitectura y las soluciones que se generan en equipo, que le dan la cualidad sustentable a un producto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 

Uno de los 12 principios de "Agile Manifiesto"

Un equipo de desarrolladores es más productivo si se encuentra creando nuevas funcionalidades en lugar de estar arreglando bugs que pudieron mitigarse antes y que por la complejidad y madurez del sistema es muy difícil de resolver actualmente. Si, el estrés del programador es un factor clave.

Relación con pilares de scrum

Reitero que las pruebas ágiles se basan en principios ágiles, lo podemos ver en el proceso empírico de scrum y sus tres pilares:

  • Transparencia
  • Inspección
  • Adaptación

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Uno de los 12 principios de "Agile Manifiesto"

Necesitamos la transparencia con todo el equipo a la hora de definir las especificaciones que se traducen en pruebas, de esa manera todos obtienen un mejor entendimiento sobre la parte lógica del negocio y la parte técnica de la implementación.

La inspección nos permite aprender de manera rápida usando las pruebas para definir y fallar tempranamente con la ayuda de todo el equipo. De modo que se obtiene un ciclo de Retroalimentación muy pequeño obteniendo información y dirección lo más pronto posible.

Luego de que aprendimos de todos y de nuestros errores, se adaptan las pruebas para cumplir con las necesidades del cliente y entregar un producto de calidad probado correctamente. Ahorrándonos mucho esfuerzo y dinero, porque el coste de arreglar bugs en etapas maduras de un producto es muy costoso en comparación con mitigarlos desde el principio con pruebas pequeñas.

Todos se involucran en las especificaciones

En scrum, un equipo multidisciplinario es más eficiente que un equipo dividido por habilidades específicas. Una división muy común y que disminuye considerablemente la agilidad de un equipo es la fuerte división de manual testers, programadores y automation testers.

Aunque posiblemente cada uno de los integrantes tenga mayor habilidad en una área, es importante que sean flexibles y se adapten a las necesidades del proyecto.

Es necesario que también la perspectiva del negocio, para que aporten significativamente a la creación de las pruebas ágiles, por poner un ejemplo, un Product Owner tiene el mayor entendimiento sobre lo que es de mucho valor para el cliente.

Todo el equipo se involucra en las pruebas para fomentar el entendimiento global desde un enfoque centrado en el cliente, y esto genera un aumento en la creatividad de las soluciones.

Al estar todos involucrados en las pruebas, se elimina un cuello de botella significativo porque se acelera la definición y la creación de las mismas. Es más rápido terminar una tarea entre varias personas que si lo hiciera una sola.

Incorporan muchas prácticas ágiles

Además de las características ya mencionadas, las pruebas ágiles permiten incorporar técnicas de gran productividad en el desarrollo de software como:

  • TDD, Test Driven development
  • BDD, Behavior Driven Development
  • Pair programming
  • Mob programming
  • Example mapping

Listado de características

Existen muchas cualidades buenas en las pruebas ágiles, pero listemos las características principales:

  • Se basan en principios y prácticas ágiles.
  • Las pruebas forman parte del desarrollo, formando un todo integral, no es algo que esté separado.
  • Acelera la retroalimentación para poder realizar las adaptaciones necesarias lo más pronto posible.
  • Se acelera el proceso de definición, creación y terminación de las pruebas.
  • Todo el equipo se involucra en las pruebas para fomentar el entendimiento global desde un enfoque centrado en el cliente, y esto genera un aumento en la creatividad de las soluciones.
  • Permite incorporar prácticas ágiles para aumentar la agilidad y productividad.
  • Menos estrés y desarrolladores felices, mayor productividad y mayor calidad.
  • Ahorran tiempo y dinero.

La matriz de pruebas ágiles

Las pruebas ágiles nos proporcionan la certeza de que con el aprendizaje actual estamos resolviendo un determinado problema con la solución correcta y la implementación y/o construcción sé está realizando correctamente.

Las pruebas ágiles maximizan el valor de la solución y minimizan los riesgos, esto se consigue fallando inmediatamente de manera segura para aprender y adaptarse rápidamente.

Con esto último tenemos cuatro aspectos fundamentales a la hora de hacer pruebas:

  • Perspectiva tecnológica
  • Perspectiva de negocio
  • Soporte y guía al desarrollo
  • Crítica del producto

Cuadrantes en relación con los cuatro aspectos

Esos cuatro aspectos anteriores se representan en los siguientes cuadrantes:

Matriz de agile testing

Matriz de agile testing

¿Cuáles son las actividades que hacemos diariamente para contestar las siguientes preguntas?

  • ¿Estamos construyendo el producto correcto?, Perspectiva de negocio.
  • ¿Estamos construyendo el producto correctamente?, Perspectiva tecnológica.
  • ¿Cómo guiamos el desarrollo para asegurarnos que el producto es correcto y que se está construyendo correctamente?, Soporte y guía al desarrollo.
  • ¿Cómo obtenemos crítica del cliente que nos ayude a construir el producto correcto de manera correcta?, Crítica del producto.

Describiendo cada cuadrante

El cuadrante 1 proporciona una guía y soporte al programador desde la perspectiva tecnológica. Se crean pruebas unitarias y de componentes, estas pruebas se construyen antes y después de escribir código, nos indica que las partes más pequeñas funcionan como deberían. Aquí se puede utilizar BDD con un enfoque más inclinado a las unidades o piezas del software de manera aislada.

El cuadrante 2 proporciona igual una guía y soporte al programador, pero desde la perspectiva del negocio. Se utilizan pruebas funcionales para User stories y features de tal forma que se validan como el Product Owner las definió y como el usuario final las necesita. Aquí se utiliza mucho BDD (Behavior driven development) para automatizar las pruebas. Y si no existe otra opción, se pueden hacer pruebas manuales.

El cuadrante 3 proporciona crítica del cliente desde la perspectiva de negocio. Son pruebas a nivel del sistema completo, sé válida que el sistema cumple con las expectativas de funcionalidad y usabilidad. Se realizan en su mayoría manualmente porque involucran al usuario y a los testers dentro de un ambiente real o simulado.

El cuadrante 4 proporciona crítica del cliente desde la perspectiva tecnológica. Son pruebas para asegurar la calidad del sistema completo en términos de velocidad de carga, rendimiento, seguridad y escalabilidad. En general pruebas no funcionales que se realizan mediante herramientas y automatización.

Divide y vencerás. Pruebas pequeñas y automatizadas

Las pruebas ágiles generan un producto de alta calidad. Para que esto sea posible es necesario tener una filosofía de prevención de bugs en lugar de buscarlos. Es obvio que existe el error humano, siempre existirán bugs, pero la pregunta principal es ¿Pudimos haber evitado este bug?

Las técnicas como TDD y BDD son muy útiles porque su filosofía es "test-first", es decir, antes de escribir cualquier línea de código primero crea tus pruebas para entender con mayor claridad el negocio, el cliente y por consiguiente los requerimientos. De esta manera se reduce el tiempo en que se recibe la retroalimentación por las dudas que surgen al momento de escribir las pruebas.

El diseño es superior (más si se realiza en equipo) y se puede refactorizar las funcionalidades rápidamente, eliminando futuros bugs, esto puede suceder varias veces en un mismo día.

Obtener retroalimentación diaria y adaptarse cada minuto o cada hora, es menos costoso y más ágil que hacerlo cada mes o cada semana con pruebas mucho más grandes. Es por eso que las pruebas que nos dan retroalimentación más rápida, son en las que más se deben invertir, normalmente estos tipos de pruebas son las pruebas relativamente pequeñas como unitarias, funcionales y de integración que se pueden automatizar.

Es importante disminuir el uso de pruebas manuales porque son mucho más lentas que las pruebas automatizadas. No estoy diciendo que las pruebas manuales deben desaparecer. Al final son necesarias, pero podemos ahorrarles mucho tiempo a los testers manuales para que reporten bugs que solo se puedan identificar realizando una prueba manual.

Así podemos disminuir las pruebas manuales en la medida de lo posible porque representan un costo mayor que las pruebas automatizadas.

Conclusión

Pasamos mucho tiempo trabajando, tal vez demasiado, creo que más de la mitad de nuestra vida adulta. Pero me he dado cuenta de algo importante, lo he percibido en mi mismo y también en mis compañeros de trabajo. Todos, en algún momento nos la pasamos mal y no estamos contentos, esto produce estrés y nuestra productividad individual empieza a disminuir, lo que sé traduce en disminución de la productividad de todo el equipo.

Las pruebas ágiles y el desarrollo ágil en general ayudan mitigar este problema. Creo firmemente que soy más productivo y hago mejor mi trabajo cuando estoy feliz haciéndolo, aún más si estoy consciente de entregar productos de alto valor para los clientes.

Tampoco estoy diciendo que todo es negro, pero sin duda las pruebas ágiles contribuyen en gran medida a tener un equipo contento, clientes felices y negocios sustentables, ahorrando tiempo, dinero y esfuerzo en el camino.

Podría interesarte