Menú

Cómo participan los probadores en las técnicas TDD, BDD y ATDD

how testers are involved tdd

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Descripción general de las técnicas TDD, BDD y ATDD:

TDD, BDD y ATDD son los términos que han revolucionado el mundo del tester en Agile y también han ganado impulso. Cambio en la mentalidad de los probadores También requiere aprender nuevas habilidades y, lo que es más importante, cambiar la actitud y la forma de trabajar.

A diferencia de trabajar de forma aislada, los probadores deben colaborar y trabajar junto con los programadores, lo que significa

  • Compartiendo los casos de prueba
  • Participar en la redacción de los criterios de aceptación de las historias.
  • Proporcionar retroalimentación continua a las partes interesadas
  • Colaborando para solucionar los defectos a tiempo.
  • Proporcionar sugerencias y aportes para mejorar la calidad de los entregables.
  • Automatización

Probadores involucrados en Agile

Antes de pasar a la discusión sobre la participación de un evaluador en estas prácticas, primero intentemos comprender los conceptos detrás de estos términos:

Lo que vas a aprender:

Desarrollo basado en pruebas

Considere el enfoque tradicional de desarrollo de software donde el código se escribe primero y luego se prueba. El desarrollo impulsado por pruebas o TDD es un enfoque que es el REVERSO exacto del desarrollo tradicional. En este enfoque, las pruebas se realizan primero y luego se escribe el código.

¡¡¿Confundido?!!

¿Cómo podemos probar un software que aún no se ha desarrollado?

¡¡Sí!! Eso es desarrollo impulsado por pruebas o TDD.

TDD funciona en pequeños incrementos donde:

  • La prueba se escribe primero
  • Se ejecuta la prueba, que fallará (por razones obvias)
  • El código está escrito (o refactorizado) solo para que el caso de prueba pase
  • La prueba se vuelve a ejecutar
  • Si la prueba pasa, pase a la siguiente prueba ELSE vuelva a escribir / modifique el código para que la prueba pase

Déjame intentar explicarlo a través de un diagrama de flujo:

Diagrama de flujo TDD

Ahora, tenemos que entender el hecho de que TDD no habla de las pruebas que hacen los probadores. Más bien, este enfoque en realidad habla de las pruebas que realizan los programadores.

¡¡Sí!! ¡¡Lo has adivinado bien !! Es la prueba unitaria.

La prueba que se escribe primero no es la prueba que escriben los probadores, sino la prueba unitaria que escriben los programadores. Entonces, reformularía los pasos como:

  • La prueba UNIT se escribe primero
  • Se ejecuta la prueba UNIT, que fallará (por razones obvias)
  • El código está escrito (o refactorizado) solo para que la prueba pase
  • La prueba UNIT se vuelve a ejecutar
  • Si la prueba pasa, pase a la siguiente prueba ELSE vuelva a escribir / modifique el código para que la prueba pase

Ahora, la pregunta que surge aquí es: si TDD es el trabajo de un programador, ¿cuál es el papel del probador en este enfoque?

Bueno, habiendo dicho que TDD es el trabajo de un programador, no significa que los probadores no estén involucrados en él. Los evaluadores pueden colaborar compartiendo los escenarios de prueba que consisten en:

Lo que quiero decir es que los probadores deben participar en la definición de los escenarios de prueba unitaria y colaborar con los programadores para implementarlos. Los evaluadores deben proporcionar sus comentarios sobre los resultados de la prueba.

Si queremos implementar TDD, los evaluadores deben actualizar sus habilidades. Deben ser más técnicos y concentrarse en mejorar sus habilidades analíticas y lógicas.

Los evaluadores también deben esforzarse por comprender la jerga técnica que usan los programadores y, si es posible, deben tener una visión general del código. De manera similar, los programadores deben ponerse en el lugar del probador y tratar de idear escenarios más sofisticados que harán que las pruebas unitarias sean más sólidas y sólidas.

Tanto los programadores como los probadores tienen que ponerse en el lugar del otro, a diferencia del antiguo enfoque tradicional en el que los programadores no daban mucho peso a las pruebas unitarias porque confiaban en los probadores para encontrar errores y defectos, y los probadores no querían darse el gusto. en aprender las cosas técnicas porque creen que su trabajo termina después de encontrar los defectos.

Desarrollo impulsado por el comportamiento

Behavior Driven Development o BDD es una extensión de Test Driven Development.

BDD, como su nombre indica, ilustra los métodos para desarrollar una función en función de su comportamiento. El comportamiento se explica básicamente en términos de ejemplos en un lenguaje muy simple que puede ser entendido por todos en el equipo que es responsable del desarrollo.

Algunas de las características clave de BDD son las siguientes:

  • El lenguaje utilizado para definir el comportamiento es muy simple y en un formato único en el que puede ser entendido por todos, tanto técnicos como no técnicos involucrados en la implementación.
  • Proporciona una plataforma que permite a los tres amigos (programador, probador y PO / BA) colaborar y comprender el requisito. Determina una plantilla común para documentarlo.
  • Esta técnica / enfoque analiza el comportamiento final del sistema o cómo debería comportarse el sistema y NO habla sobre cómo debería diseñarse o implementarse el sistema.
  • Hace hincapié en ambos aspectos de la calidad:
    • Reunir los requisitos
    • Apto para su uso

¿Por qué BDD?

Bueno, sabemos que arreglar un defecto / bicho en la última etapa de cualquier ciclo de desarrollo es bastante costoso. La reparación de los defectos de producción no solo afecta el código, sino también el diseño y sus requisitos. Cuando hacemos el RCA (análisis de causa raíz) de cualquier defecto, la mayoría de las veces, llegamos a la conclusión de que el defecto en realidad se reduce a requisitos mal entendidos.

Básicamente, esto sucede porque todos tenemos diferentes aptitudes para comprender los requisitos. Por lo tanto, las personas técnicas y no técnicas pueden interpretar el mismo requisito de manera diferente, lo que puede dar lugar a una entrega defectuosa. Por lo tanto, es fundamental que todos en el equipo de desarrollo comprendan el MISMO requisito y lo interpreten de la MISMA manera.

Necesitamos asegurarnos de que todos los esfuerzos de desarrollo estén dirigidos y enfocados hacia el cumplimiento de los requisitos. Para evitar cualquier tipo de defecto de 'falta de requisito', todo el equipo de desarrollo debe alinearlos para comprender el requisito que es apto para su uso.

El enfoque de BDD permite que el equipo de desarrollo lo haga mediante: -

  • Definición de un enfoque estándar para definir el requisito en inglés simple
  • Suministro de ejemplos de definición que expliquen los requisitos.
  • Proporcionar una interfaz / plataforma que permita a los técnicos (programadores / probadores) y no técnicos (PO / BA / Cliente) colaborar y unirse y estar en la misma página para comprender e implementar los requisitos.

¿Cómo implementar BDD?

Hay muchas herramientas disponibles en el mercado para implementar BDD. Estoy nombrando algunos aquí:

  • Pepino
  • Aptitud física
  • Concordion
  • Jbehave
  • Flujo de especificaciones

Ejemplo:

Intentemos entender el BDD con un ejemplo. Para mi caso, estoy usando Gherkin (Pepino):

Considere un caso simple en el que queremos permitir que solo los usuarios autenticados ingresen al sitio XYZ.

El archivo Gherkin (archivo de características) sería el siguiente:

Característica: Portal de registro de pruebas

Esquema del escenario: Usuario válido registrado

Dado: El cliente abre el portal de registro

Cuando: el usuario ingresa el nombre de usuario como '' y la contraseña como ''

Entonces: el cliente debería poder ver el formulario.

Ejemplos :

| usuario | contraseña |

| usuario1 | pwd1 |

| usuario2 | pwd2 |

Podemos ver cómo se documenta un requisito en particular utilizando un inglés simple. Los tres amigos pueden trabajar juntos para diseñar los archivos de características y los datos de prueba específicos se pueden documentar en la sección de ejemplos. BDD proporciona un medio para reunir a programadores, evaluadores y empresas en una mesa y establecer un entendimiento común de las funciones que se implementarán.

El enfoque de BDD ahorra esfuerzos y costos y verifica si hay algún defecto después de la implementación de producción, ya que la colaboración de los clientes y desarrolladores fue durante todo el ciclo de desarrollo de la función.

Los equipos de desarrollo pueden utilizar estos archivos de funciones y convertirlos en programas ejecutables para probar una función en particular.

¿Cómo?

Bueno, ¡necesitas aprender Pepino / Fitnesse para eso!

Desarrollo impulsado por pruebas de aceptación

El desarrollo impulsado por pruebas de aceptación o ATDD es una técnica en la que todo el equipo colabora para definir los criterios de aceptación de una historia épica antes de que comience la implementación. Estas pruebas de aceptación están respaldadas por ejemplos adecuados y otra información necesaria.

La mayoría de las veces, BDD y ATDD se usan indistintamente. El enfoque ATDD también se puede implementar utilizando el formato Dado-Cuándo-Entonces, al igual que escribimos características en el enfoque BDD.

Intentemos rápidamente resumir las diferencias entre los tres enfoques:

  • TDD es más técnico y está escrito en el mismo idioma en el que se implementa la función. Si la función está implementada en Java, escribimos JUnit Casos de prueba . Considerando que BDD & ATDD está escrito en un idioma inglés simple
  • El enfoque TDD se centra en la implementación de una función. Mientras que BDD se centra en el comportamiento de la función y ATDD se centra en capturar los requisitos
  • Para implementar TDD necesitamos tener conocimientos técnicos. Mientras que BDD y ATDD no requieren ningún conocimiento técnico. La belleza de BDD / ATDD radica en este hecho de que tanto las personas técnicas como las no técnicas pueden participar en el desarrollo de la función.
  • Dado que TDD ha evolucionado, da margen para un buen diseño y se centra en el aspecto de calidad de 'Cumplimiento de requisitos'; mientras que BDD / ATDD se centran en los 2Dakota del Norteaspecto de la calidad que es 'apto para su uso'

Todas estas técnicas hablan básicamente del enfoque de “prueba primero”, a diferencia del enfoque de “prueba último” utilizado en las metodologías de desarrollo tradicionales.

Como las pruebas se escriben primero, los evaluadores desempeñan un papel muy importante. Los probadores no solo deben tener un vasto dominio y conocimiento comercial, sino que también deben poseer buenas habilidades técnicas para poder agregar valor en la lluvia de ideas durante las discusiones de los 3 amigos.

Con conceptos como CI (Integración continua) y CD (Entrega continua), los probadores deben colaborar bien con los programadores y contribuir por igual al área de desarrollo y operaciones.

expresiones regulares en c ++

Permítanme resumir esta discusión con la famosa Pirámide de prueba en Agile:

Prueba Pyramid en Agile

La capa más baja de esta pirámide está formada por la capa de prueba unitaria. Esta capa es la capa de base; por lo tanto, es imperioso que esta capa sea sólida como una roca. La mayoría de las pruebas deben introducirse en esta capa. Esta capa más baja se enfoca solo en TDD.

En el Ágil mundo, se hace hincapié en hacer que esta capa de la pirámide sea más fuerte y robusta y se enfatiza que la mayoría de las pruebas se logran en esta capa.

Las herramientas utilizadas en esta capa de una pirámide son todas las herramientas de Xunit.

La capa intermedia de la pirámide es la capa de servicio, que explica las pruebas de nivel de servicio. Esta capa actúa como un puente entre la interfaz de usuario de la aplicación y la unidad / componente de nivel inferior. Esta capa se compone principalmente de las API que aceptan solicitudes de la interfaz de usuario y devuelven la respuesta. El enfoque BDD y TTDD está activo en esta capa de la pirámide.

Las herramientas utilizadas en la capa media de la pirámide son: Fitnesse, Cucumber y Robot Framework .

La capa superior de la pirámide es la interfaz de usuario real, que muestra que esta capa debe contener la menor cantidad de pruebas, o debería decir, el esfuerzo de prueba en esta capa en particular debe ser mínimo. La mayoría de las pruebas de la función deberían haberse completado cuando llegamos a la capa superior de la pirámide.

Las herramientas utilizadas en la capa superior son: Selenio , QTP y RFT.

Dado que trabajamos en pequeños incrementos en Melé (llamados Sprints), la implementación manual de todos estos enfoques no es factible. Estos enfoques requieren una intervención automatizada. La automatización, en este caso, es muy crítica.

De hecho, estos enfoques se ejecutan realmente mediante la automatización. Al final de cada sprint, se agregan nuevas características, por lo que es importante que la característica implementada anteriormente funcione como se esperaba; por eso, Automatización se convierte en el HÉROE aquí.

Conclusión

Al final del artículo, debe haber aprendido cómo los probadores están involucrados en las técnicas TDD, BDD y ATDD.

En la tercera parte de la serie, centraré mi discusión en la automatización en un mundo ágil.

Sobre el Autor: Este artículo es del autor de STH, Shilpa. Trabaja en el campo de las pruebas de software durante los últimos 10 años en dominios como publicidad en Internet, banca de inversión y telecomunicaciones.

Siga mirando este espacio para obtener muchas más actualizaciones.

Lectura recomendada

^