Métodos de prueba ágiles: pruebas basadas en el comportamiento

Las pruebas ágiles son un enfoque relativamente nuevo para las pruebas de software . Sigue los principios del desarrollo de software ágil como se indica en el Manifiesto Ágil. Hace unos 10 o 12 años, la mayoría de los proyectos se ejecutaban en cascada. Sin embargo, con la ventaja básica de un tiempo de comercialización más rápido, la metodología Agile está ganando popularidad en la actualidad.
En Agile, el desarrollo y las pruebas de software son continuos, y es un esfuerzo de colaboración entre probadores, desarrolladores, propietarios de productos e incluso clientes, y las pruebas no son una fase separada como el modelo en cascada.

La diferencia con la metodología Agile es que la prueba comienza al inicio del proyecto, incluso antes de que haya comenzado el desarrollo, y brinda una retroalimentación continua a la actividad de desarrollo.

Además, como proceso de pensamiento, las pruebas en la metodología ágil son diferentes, ya que la responsabilidad de la calidad recae en todos los miembros del equipo Agile y no solo en el control de calidad, es decir, en cierto modo, todos en el equipo son responsables de las pruebas.

Métodos de prueba ágiles:
1. Desarrollo dirigido por pruebas (TDD):

• El término TDD fue acuñado por Kent Beck en 2002
• En esta metodología, las pruebas se escriben antes que las funciones.
• Se basa en la repetición de un ciclo de desarrollo muy corto.
• Primero, el desarrollador escribe un caso de prueba automatizado inicialmente fallido que define una mejora deseada o una nueva función
• En segundo lugar, el desarrollador produce la cantidad mínima de código para pasar esa prueba y
• Finalmente refactoriza el nuevo código a estándares aceptables

La idea detrás del desarrollo basado en pruebas es hacer que cada cambio sea lo suficientemente pequeño para iterar rápidamente. A medida que automatiza e implementa cada función o un cambio, básicamente ha agregado algo valioso a su sistema general y está listo para un producto que se puede enviar y comentarios del propietario del producto.

(a). Pruebas basadas en el comportamiento (BDD):

• Fue descrito por primera vez por Dan North en 2009.
• BDD es una extensión del desarrollo basado en pruebas (TDD).
• Product Owner, Programmer y Tester (3 amigos) están involucrados desde el principio.
• Ayuda en la implementación de la aplicación desde el punto de vista de las partes interesadas mediante el uso del estilo dado-cuándo-entonces para representar las pruebas.
• BDD Cambia el vocabulario de estar basado en pruebas a estar basado en el comportamiento.
• Puede ser llamado indistintamente/vagamente
  • contar historias
  • Pruebas funcionales
  • Desarrollo impulsado por pruebas de aceptación (ATDD)

Dado que BDD implica pensar en un lenguaje común, ayuda a los equipos a tener las conversaciones correctas en el momento adecuado y, por lo tanto, maximiza la cantidad de código valioso producido. También tiene potencial para identificar lagunas en la comprensión y áreas en las que necesitamos más información antes de que sepamos realmente lo que se debe hacer. 

2. Pasos involucrados en la prueba BDD:

• Primero, tome un pequeño cambio próximo al sistema, es decir, una historia de usuario o un escenario (también conocido como ejemplo en contexto de pepino).
• Analice la nueva funcionalidad para explorar y acordar los detalles de lo que se espera que se haga discutiendo entre tres amigos: BA, desarrollador y probador.
• Documente los escenarios de una manera que se pueda automatizar.
• Por último, implemente el comportamiento descrito por cada ejemplo documentado, comenzando con una prueba automatizada para guiar el desarrollo del código.

En la siguiente figura se describe un flujo de proyecto BDD práctico. 

3. BDD vs ATDD vs TDD: diferencias clave
Desarrollo impulsado por el comportamiento (BDD):

• De naturaleza más orientada al cliente y ayuda a los desarrolladores a escribir pruebas teniendo en cuenta el comportamiento deseado por las partes interesadas, y no pruebas para verificar la implementación del código.
• Enfocado en el cliente y utiliza un idioma similar al inglés, lo que permite una colaboración más fácil con las partes interesadas no técnicas.
• Brinda una comprensión clara de lo que debe hacer el sistema desde la perspectiva del desarrollador y el cliente.
• En BDD, las pruebas fallan porque la función no se ha desarrollado,
  • La función se basa en las necesidades del cliente

Desarrollo impulsado por pruebas de aceptación (ATDD):
 

• Comienza guiando al equipo de desarrollo sobre las funciones que realmente se requieren para construir y luego probar esas funciones para verificar su funcionalidad. Por lo tanto, ATDD se enfoca en un nivel alto y TDD en un nivel bajo.
• Hacer lo correcto (punto de vista empresarial).
• Le da al desarrollador una comprensión de lo que debe hacer el sistema.
• Las herramientas recientes de ATDD se inclinan más hacia el uso de un lenguaje similar a BDD de Dado, Cuándo, Entonces.

Desarrollo dirigido por pruebas (TDD)

• Le dice al desarrollador si su código funciona bien.
• Hacer las cosas bien (Punto de vista del desarrollador).
• En TDD, las pruebas fallan porque no se ha desarrollado el algoritmo/función.
  • El algoritmo se basa en lo que sabe el programador
     

4. Pepino y Pepinillos :
Pepino :

• Un punto importante a tener en cuenta es que Cucumber no es una herramienta de prueba.
• Cucumber es una herramienta basada en el marco de desarrollo impulsado por el comportamiento (BDD) que se utiliza para escribir pruebas de aceptación del usuario.
• Cucumber lee las especificaciones ejecutables escritas en texto en inglés y valida que el software haga lo que sugieren las especificaciones.
• Los escenarios o especificaciones para pepino están escritos en el siguiente formato:

Escenario : <Descripción detallada del escenario>

Dado : Esta cláusula describe las condiciones previas

Cuándo : esta cláusula define el punto de activación o una operación.

Luego : Esta cláusula define el resultado del evento o la operación. 

pepinillos:

• Gherkin es un lenguaje de dominio específico legible por negocios.
• Es fácil de entender, ya que elimina los detalles de lógica y sintaxis de las pruebas de comportamiento.
• Utiliza un conjunto de palabras clave para que las pruebas sean más comprensibles. Las palabras clave más utilizadas son: Característica, Dado, Cuándo, La, Regla y muchas más.
• Gherkins se ha traducido y se puede utilizar en varios idiomas. Esto ayuda a facilitar la comunicación entre las partes interesadas y los usuarios comerciales.

Ventajas y desventajas :

• Las pruebas escritas en Gherkins/Cucumber tienen el doble propósito de pruebas y documentación del proyecto.
• La adopción del enfoque BDD garantiza que se construya un proceso de desarrollo teniendo en cuenta la experiencia del usuario.
• Esta metodología requiere mucho compromiso entre 3 amigos. Esto puede servir como ventaja o desventaja dependiendo de la situación del proyecto.

Pensamientos finales:
el enfoque BDD puede ser una buena opción cuando necesita que todos los miembros del equipo participen sin profundizar en los aspectos técnicos. Además, este enfoque no es ideal para todos los tipos de proyectos. Los proyectos más cortos pueden retrasarse con este método. También puede complicar los proyectos y, a veces, ralentizarlos. También requiere un importante cambio de mentalidad de la forma tradicional de trabajar.