Experiencia usando BDD

Hace aproximadamente siete años, Dan North describió en su artículo la aplicación práctica del enfoque BDD, que le permite hacer que el proceso de desarrollo sea más comprensible y manejable mediante el establecimiento de comunicaciones internas. La industria muestra cada vez más interés en esta metodología, dirigida a la interacción productiva de los equipos estándar, tales como "análisis-desarrollo-prueba".

Sin embargo, ahora solo una pequeña parte de las empresas decide usar BDD. Por qué

Entonces, vamos a resolverlo. BDD (Behavior Driven Development) es una metodología flexible estrechamente relacionada con TDD (Test Driven Development - "Desarrollo a través de pruebas"). Por experiencia, incluso los evaluadores experimentados a menudo no ven la diferencia entre estas metodologías. De hecho, a primera vista es difícil de aislar: ambos enfoques implican escribir documentación y pruebas antes del inicio de la fase de desarrollo. Y la diferencia es esta: en BDD, para describir las pruebas, debe usar un lenguaje natural que sea comprensible para cada participante del proyecto para, de hecho, combinar la declaración del problema, las pruebas y la documentación juntas. En otras palabras, se define DSL (lenguaje orientado a temas específicos), luego se crea un conjunto limitado estándar de frases que describe el comportamiento de los elementos necesarios. Luego, con su ayuda, se desarrolla un escenario utilizando la nueva funcionalidad, que será clara para todos.

Veamos la diferencia una vez, y se hará evidente:

Tocaremos este ejemplo, pero primero, veamos toda la variedad de metodologías que actualmente son de relevancia distinta de cero.

Compara varias metodologías

El siguiente diagrama muestra una comparación de tres enfoques: TDD, TLD (Test Last Development) y BDD:

• Cuando trabajamos de acuerdo con la metodología BDD, las especificaciones de autotesting y redacción acompañan cada etapa del ciclo de desarrollo de software, lo que garantiza la relevancia constante de autotests y documentación.
• Las metodologías TDD y ATDD (Pruebas de aceptación) se combinan en un diagrama en un bloque, porque escrito en la etapa de análisis. Como se mencionó anteriormente, TDD se basa en pruebas de escritura antes de desarrollar la funcionalidad. El desarrollador debe escribir pruebas para escribir la funcionalidad de la prueba.
• TLD (Test Last Development) incluye pruebas después de la implementación de la funcionalidad.
• BDD es universal y se puede incluir en cualquier etapa de desarrollo.

El segundo diagrama muestra la participación de los participantes en el proceso de desarrollo al escribir guiones.

• En BDD, cualquier miembro del equipo puede conectarse a las pruebas en cualquier etapa, por ejemplo, analista, usuario comercial, desarrollador y probador, ya que las pruebas son claras para todos los participantes en el proceso.
• BDD también es útil porque no necesita pasar mucho tiempo escribiendo varios tipos de documentación. El esquema de desarrollo clásico requiere, como mínimo, especificaciones y scripts de prueba que generalmente son escritos por diferentes personas. En BDD, una especificación es un caso de prueba, mientras que también es una prueba automática. Los probadores no necesitan escribir documentación de prueba por separado: el analista que escribió la especificación a partir de construcciones de lenguaje natural (que es legible y comprensible por cualquier miembro del equipo) ya lo hizo por ellos.

Sin lugar a dudas, BDD es una buena herramienta para lograr la calidad del producto. Las pruebas y la documentación se escriben más rápido. Para una empresa, un proyecto se vuelve más transparente, gracias a construcciones de lenguaje natural que son comprensibles para cualquier persona lejos de la programación.

Esto es sobre los profesionales. Sin embargo, como ya se ha dicho, a pesar de una gran cantidad de ventajas, pocos implementan esta metodología.

BDD es bueno para todos, pero ¿por qué no usarlo?

La respuesta es simple: es larga y costosa. La mayoría de las compañías de TI estarán de acuerdo con esta declaración. Y al principio no fuimos la excepción. El BDD es inconveniente incluso si requiere la participación de especialistas en pruebas que ya se encuentran en la etapa de elaboración de los requisitos.

BDD da vuelta la clásica guía de desarrollo (TLD). Está mal implementado porque es difícil. El ciclo de desarrollo se está alargando.

BDD es, sin duda, una forma de lograr calidad. Pero no todos están dispuestos a pagar tiempo y especialistas por esta calidad.

Sin embargo, ¿qué debo hacer si todavía quiero implementar BDD?

Puede intentar usar marcos prefabricados. Por ejemplo Pepino, Squish, Yulup.

El principal problema de la complejidad de BDD no está en el proceso, sino en la implementación y las herramientas existentes. Tome WEB como ejemplo de desarrollo de un sistema de información corporativo. Con una implementación web, nos encontramos con un WebDriver, que actualmente es el estándar para automatizar aplicaciones que se ejecutan en un navegador web. Tiene muchas oportunidades. Para tener en cuenta diversas personalizaciones de los elementos de la página, debe encontrar opciones para acceder a ellos. Y aquí, para facilitar el desarrollo de la prueba, varias bibliotecas vienen al rescate (Selenide, etc.), lo que crea su propio ecosistema que necesita saber. Para trabajar con WebDriver, necesita un programador o un probador de automatización, porque todo se implementa utilizando códigos y diseños astutos.

Comenzar con el marco BDD es difícil y requiere mucho tiempo.

Nuestro enfoque está en un instrumento llamado Gauge. Este es un marco flexible y ligero, distribuido bajo una licencia gratuita. Francamente, realmente no estudiamos las alternativas, porque El uso de Gauge ha sido dictado agresivamente por nuestro cliente.

En Gauge, las pruebas se escriben en archivos de especificación (archivos con la extensión .spec). La especificación contiene pasos de prueba escritos en lenguaje natural. Estos pasos se implementan en un lenguaje de programación (utilizamos el lenguaje de programación Java). Al implementar los pasos, es importante cumplir con la Convención de nomenclatura tanto en los nombres del script y los archivos de implementación, como en los nombres de los métodos de implementación y los pasos del script, deben ser completamente idénticos. Una flexibilidad adicional para esta herramienta es que los pasos pueden tener parámetros.

Gauge nos permitió usar los beneficios de BDD. Sin embargo, todavía encontramos problemas que son la complejidad de la implementación: los problemas de las herramientas y la implementación del proceso.

Resultó que la participación de los evaluadores en una etapa temprana tiene un efecto negativo en el resultado final. Mayor tiempo para desarrollar pruebas. El uso de cualquier marco requiere grandes esfuerzos por parte del probador, quien, sin duda, debe tener un buen dominio de la programación. Al principio, el proceso de trabajar con el guión fue el siguiente: el analista le dijo la prueba al probador, y el escritor técnico la escribió. Si bien el probador se ocupó de la implementación del software, el significado de la funcionalidad probada cambió. Esto afecta la separación del punto de entrada, y debería ser uno, ya que el proceso se divide y se convierte en un proceso "normal", del que solo quería irme. Es decir el punto de entrada se dividió, las comunicaciones se extendieron, el probador se precipitó en la implementación de la prueba, el escritor técnico entendió a su manera, y el analista reescribió sus muelles y cambió de opinión, el desarrollador entró en "su mundo").

El probador pasó mucho tiempo en el código. Pero aún el mismo probador tuvo que pensar sobre la búsqueda de elementos en la página. La situación recordaba a un famoso juego infantil: "Teléfono estropeado". Se produjo el colapso. Y decidimos: BDD funcionará solo si los analistas pueden escribir pruebas. Es necesario reducir la complejidad de las pruebas de escritura, para simplificarlas. Pero para esto necesita simplificar significativamente las interfaces de prueba. Al probar las herramientas, la implementación del proceso en conjunto con todos los enfoques y bibliotecas debería ser más simple.

El trabajo del probador al principio se veía así:

1. Examen de documentación, si la hay;
2. Elaboración de una lista de verificación;
3. Pruebas ad-hoc
4. Elaboración de un plan de prueba;
5. Refinamiento de la cosmovisión del analista;
6. Refinamiento de la imagen del mundo por el desarrollador;
7. Si todo ha crecido junto, escribir documentación de prueba, en paralelo con la prueba;
8. Esperando errores corregidos, probando errores;
9. Descripción de páginas, controles, búsqueda de elementos en la página usando Web-Driver. Busque lo que ya se ha implementado en el sistema de prueba;
10. Escritura de lógica de prueba;
11. Lanzamiento
12. Error de soporte / error de regresión;
13. Actualización de la especificación;
14. Fix bug
15. Actualización de prueba automática, actualización de una gran cantidad de controles modificados;
16. Lanzamiento
17. ...
    Los artículos en cursiva (1, 5, 6, 7, 9, 13, 15) conllevan costos de tiempo. Pueden y deben optimizarse.

Esta lista se ilustra brevemente en el diagrama del proceso de desarrollo:

Nuestra empresa se especializa en proyectos con implementación web de interfaces. En base a esto, utilizamos la herramienta Web Driver para interactuar con el navegador web.

De hecho, Selenium Web Driver es el estándar, y se usa para describir objetos web en cualquier marco, incluidas las bibliotecas Gauge, jUnit, Masquerade y otras. Tiene mucha flexibilidad para diferentes tareas, lo que crea una laboriosidad excesiva en problemas de tipo local. Necesitamos encontrar una solución para reducir la complejidad.

Por ejemplo, muestremos en el diagrama cómo se relacionan Selenium Web Driver, Gauge Framework, la biblioteca Masquerade y el lenguaje de programación Java.

En este esquema, en lugar del marco BDD, puede poner jUnit, TestNG o cualquier otro, cualquier paquete funcionará, dependiendo de las necesidades. Selenium y Masquerade permanecerán, el lenguaje de programación se puede cambiar.

Acelerar la escritura de códigos: conectar la mascarada

Nuestra empresa se está desarrollando en la plataforma CUBA . Y específicamente para esta plataforma, se desarrolló una herramienta para pruebas automáticas: Masquerade es una biblioteca que proporciona una API concisa y conveniente para trabajar con código al implementar pruebas usando WebDriver. Esta biblioteca funciona en Selenium Web Driver, es amiga de selenide y cualquier framework.

En los proyectos de CUBA, cada elemento de la página web contiene cuba-id, que no cambia. CUBA utiliza un enfoque de componentes , y la biblioteca Masquerade simplifica la interacción con los elementos de la página web. La biblioteca puede realizar acciones con elementos de la página web implementados usando CUBA de una manera más simple. Por lo tanto, cuando busque elementos en la página, no necesita usar construcciones voluminosas con XPath, como era antes:

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click(); 

O construcciones más concisas en Java, que, sin embargo, siguen siendo engorrosas:

 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); } 

Después de conectar la biblioteca Masquerade, la descripción del control incrustado parece simple y de fácil acceso. Ni siquiera tiene que buscar controles en la página, porque él ya lo tiene en el proyecto. Aquí hay un ejemplo de una descripción de botón para el formulario de autorización en la aplicación:

En el código de la página, vemos un elemento claramente reconocible cuba-id=”loginButton”

Describamos el botón usando la biblioteca Masquerade:

 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton; 

Una implementación de prueba simple en el marco jUnit es un bloque de autorización que se ejecuta antes de cada prueba:

 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); } 

Y en el cuerpo del método de inicio de sesión, el siguiente código:

 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click(); 

Lo más importante es cómo describimos la página, cómo nos referimos a los elementos. Descripción de la página LoginWindow:

 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; } 

Encontrar artículos es solo parte de la biblioteca Masquerade. Acceder a los elementos de una página web le permite realizar varias acciones con estos elementos. Por ejemplo, puede seleccionar un elemento de la lista desplegable:

 getMaxResultsLayout().openOptionsPopup().select("5000") 

O ordenar la mesa:

 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING); 

Vea las capturas de pantalla a continuación para obtener una lista de algunas acciones de la tabla:

El uso de Masquerade ha simplificado enormemente la escritura de pruebas, ahora para escribir una prueba para una nueva funcionalidad, necesita:

1. Usar Masquerade para describir una página es fácil y no requiere habilidades especiales de programación.
2. Reúna en una clase todas las páginas que se utilizan al verificar la funcionalidad.
3. A partir de las construcciones listas para usar del lenguaje natural, recopile un script de prueba (sustituyendo los nombres de los elementos necesarios allí), es decir, escriba una especificación Gauge.

Integrando Masquerade y Gauge

Antes de usar BDD, se utilizó el enfoque de TLD y para trabajar con él también optimizamos el proceso de escritura del código de prueba. Paquetes jUnit / TestNG + WebDriver + Selenide + Masquerade usados.

Ahora, para trabajar con Gauge, agregamos el complemento correspondiente a intellij IDEA. Después de eso, será posible crear un nuevo tipo de prueba: Especificación.

Ahora creamos la especificación (script) e implementamos los pasos utilizando las capacidades de WebDriver, Masquerade y Java.

Hacemos clic en el paso del script y vamos a la implementación:

En la implementación, puede usar el método existente login ().

¿Cómo se ve esta perfección?

Recordemos el ejemplo que examinamos al principio del artículo:

"Navigation.openMenu(menu)” contiene la implementación de abrir un menú usando la biblioteca Masquerade.

La biblioteca se expandió posteriormente y aparecieron pasos universales que podrían usarse para cualquier aplicación CUBA. Estos son los pasos que le permiten trabajar con elementos del programa: botones, campos, tablas. Estos pasos universales se han convertido en el conjunto de frases estándar que usamos en BDD para escribir guiones.

Gracias a Masquerade + Gauge, redujimos significativamente la complejidad de crear pruebas. Ahora los exámenes pueden ser escritos por personas que no tienen habilidades especiales de programación. Una persona puede escribir una prueba (antes, una secuencia de comandos fue inventada por una, pero implementada por otra, lo que generó confusión). Por lo tanto, hemos logrado nuestro objetivo: las interfaces están simplificadas y no será difícil para los analistas escribir scripts de prueba.

Los cambios del proceso se muestran a continuación:

Fue:

Se convirtió en:

En comparación, se ve que los requisitos, la especificación y la documentación de prueba se combinan en un párrafo. La documentación de prueba también es una prueba automática, con la excepción de la implementación de pasos de prueba específicos.

Resumen

Por el momento, estamos desarrollando con éxito de acuerdo con el esquema indicado anteriormente. Y logramos deshacernos del problema principal de BDD: un aumento serio en términos debido a la complejidad de la implementación, agregando y finalizando el kit de herramientas. Sin embargo, la calidad de la entrega del producto ha mejorado.

El tiempo requerido para mantener la documentación se reduce en proporción al número de especificaciones modificadas, porque Un cambio en la especificación (lógica del sistema) conduce automáticamente a un cambio en la prueba automática en una iteración. Es decir el probador no necesita ingresar al sistema de documentación (como Confluence, etc.) para una actualización, y esto también es cierto para otros miembros del equipo.

El tiempo para implementar y soportar pruebas en presencia de una biblioteca que simplifica el trabajo con objetos de página se ha reducido a la mitad en comparación con trabajar con el controlador web limpio habitual y el costo de rehacer enlaces XP.

En el desarrollo de cualquier solución comercial y en la gestión de calidad, el costo de eliminar errores en la recopilación de requisitos y análisis está creciendo exponencialmente . En consecuencia, la probabilidad de problemas asociados con la alteración del producto, de acuerdo con los artículos y cronogramas existentes en el desarrollo iterativo, con la detección temprana de un problema, que es un buen estudio de los requisitos, reduce significativamente el costo de desarrollo, dependiendo del proyecto. Puede ser tanto 0% como ~ 40%. Es esta mejora la que se logra a través de la introducción de BDD. Esto se puede implementar sin llamarlo la palabra BDD, pero existe en BDD. Poder sortear los problemas es una parte importante de la garantía de calidad.

En conclusión, me gustaría señalar que este esquema de desarrollo también está integrado con la Integración continua y el sistema de gestión de pruebas de QA Lens desarrollado en nuestra empresa. En QA Lens, puede escribir los mismos scripts que en IDEA utilizando un lenguaje orientado a temas. Este lenguaje consiste en un glosario previamente compilado de acciones disponibles que fueron implementadas previamente. Al realizar una prueba automática en Gauge desde la máquina de un desarrollador o CI, QA Lens automáticamente anota qué pasos de guión se completaron y cuáles no. Por lo tanto, después de ejecutar una prueba automática de un script escrito por un analista, el departamento de pruebas recibe de inmediato información completa y actualizada sobre el estado del producto.

Autores: Sunagatov Ildar y Yushkova Julia ( Yushkova )