X
BLOG

Cómo y por qué adoptar BDD en el desarrollo de software

Cómo y por qué adoptar BDD en el desarrollo de software Tiempo de leer: 7 minutos
El desarrollo impulsado por el comportamiento (BDD) aborda el problema de implementar requisitos mal definidos aprovechando la experiencia en el dominio de los profesionales de control de calidad y negocios para garantizar que el equipo de desarrollo construya el software correcto. Siga leyendo para obtener más información sobre cómo adoptar BDD en la empresa.

Durante los últimos años, muchas organizaciones han pasado a Desarrollo ágil para acelerar la entrega y obtener comentarios más oportunos del mercado. En estas organizaciones, mientras el desarrollo comienza a moverse más rápido, QA tendrá dificultades para mantener el ritmo a menos que integren prácticas de prueba de software automatizadas en la línea de desarrollo, por lo que a menudo es el primer cuello de botella a superar.

Pero después de la adopción exitosa de la automatización de pruebas y de que toda la organización se mueva más rápidamente, las organizaciones comienzan a preguntarse si están construyendo el Derecho software. Acelerar el desarrollo de software y garantizar la calidad del software con pruebas continuas automatizadas es un gran logro, pero no sirve de nada si el software no es lo que sus clientes quieren o necesitan.

Las personas en esta etapa de la evolución de sus procesos de desarrollo de software están observando de cerca a BDD como un medio para garantizar que su software cumpla con los requisitos comerciales de su organización. Pero, ¿qué es exactamente el BDD y cómo se relaciona con las pruebas?

TDD frente a BDD

BDD es una evolución del metodología de desarrollo impulsado por pruebas (TDD), en el que los desarrolladores escriben la prueba antes escribiendo el código. Después de crear una prueba fallida para comenzar, los desarrolladores que practican TDD escriben solo el código suficiente para asegurarse de que la prueba pasa, luego escriben otra prueba; enjuague y repita. El resultado es un código delgado y medio con una alta cobertura de prueba.

TDD es una actividad diseñada para mejorar la calidad del software y garantizar la cobertura del código. BDD, por el contrario, resuelve el problema de implementar correctamente los requisitos. En lugar de centrarse en el prueba para verificar el . desea implementar, BDD se trata de definir el comportamiento de la aplicación para que cumpla con los negocios específicos requisitos.

La similitud entre TDD y BDD es que se implementa un mecanismo contractual antes de realizar cualquier trabajo, para garantizar que el resultado coincida con una expectativa específica. Pero aquí es donde termina la similitud. En TDD, la prueba es un contrato destinado a garantizar que la aplicación cumpla con un requisito funcional específico. En BDD, el comportamiento es el contrato destinado a garantizar que la aplicación cumpla con un requisito comercial específico.

¿Qué es BDD en desarrollo de software?

Hemos estado lanzando casualmente el término "comportamiento", pero tiene un significado técnico en el contexto de BDD. En BDD, comportamientos son declaraciones cuidadosamente elaboradas y legibles por humanos que siguen un formato específico. Se recopilan en "archivos de características" que se pueden integrar en el proceso de desarrollo.

Los archivos de características generalmente se escriben en Gherkin, que es una sintaxis específica de BDD que permite a las herramientas de BDD, como Cucumber y SpecFlow, automatizar el proceso de validación de los comportamientos. Estas herramientas BDD analizan los comportamientos en el archivo de características y ejecutan el "código de pegamento" apropiado. Este código de unión mapea los "comportamientos" a los pasos de ejecución, normalmente código de prueba Java o .NET escrito por un desarrollador, en un motor de prueba específico. Estas asignaciones se denominan comúnmente "definiciones de pasos" o "definiciones de pasos". Como resultado, los evaluadores pueden usar archivos de características como casos de prueba que verifican los comportamientos asociados con los requisitos.

¿Cuáles son los beneficios de BDD?

Hay varias ventajas que el desarrollo impulsado por el negocio aporta al desarrollo de software. Con BDD, puede:

  • Incrementar la colaboración. BDD proporciona un lenguaje común para los diferentes roles en la organización. Esto ayuda a los miembros del equipo técnico y no técnico a comprender la funcionalidad prevista y los requisitos comerciales del proyecto.
  • Aproveche una gama más amplia de experiencia en el dominio. Debido a que los comportamientos se definen en un formato comprensible para los humanos, las organizaciones pueden aprovechar la experiencia de probadores, arquitectos y otras partes interesadas que tienen diferentes perspectivas y antecedentes.
  • Cumplir con los requisitos con un fuerte enfoque en las pruebas. BDD impulsa la cobertura de prueba con un enfoque en el cumplimiento de los requisitos, lo que garantiza que el producto final sea pertinente para las necesidades comerciales de una organización.
  • Promueva la reutilización y reduzca la complejidad de la automatización. Se anima a los desarrolladores que escriben el código de pegamento a escribir Reutilizable pasos de prueba, así como código más comprobable. Por ejemplo, una aplicación puede tener algunos pasos de configuración repetitivos que deben invocarse para lograr un cierto estado. Un desarrollador puede definir esos pasos en el código de pegamento, que se pueden reutilizar para manejar la configuración y ejecución.

Este último punto es una de las características clave de BDD. Los pasos de prueba modulares y reutilizables permiten a los probadores confiar en la herramienta BDD para hacer el trabajo pesado al verificar y validar los requisitos. El problema, sin embargo, es que los desarrolladores aún deben escribir el código adhesivo que une los comportamientos a los requisitos. Hablaremos más sobre esto a continuación.

Costos de implementar BDD en la empresa

El mayor costo asociado con la implementación de BDD es escribir el código de pegamento. En la mayoría de los casos, esta tarea recae en el equipo de desarrollo, que traslada la carga de crear los artefactos de prueba para validar los requisitos de los probadores a los desarrolladores.

En un mundo anterior a BDD, los probadores usarían herramientas y marcos para crear pruebas que validaran la funcionalidad, no necesariamente los requisitos. Con BDD, los probadores, analistas de negocios y otras partes interesadas definen comportamientos en un archivo de características, pero los desarrolladores o las personas con habilidades de escritura de código aún deben escribir el código adhesivo que mapea los comportamientos con la funcionalidad.

El hecho de que BDD aumente el costo de desarrollo puede perjudicar a las organizaciones con recursos de desarrollo limitados. Aunque el código adhesivo está destinado a ser reutilizable y más fácil de aprovechar para la automatización de pruebas, la inversión necesaria para escalar e implementar BDD en toda la empresa suele ser demasiado alta.

Cómo reducir la carga técnica de BDD

Parasoft ayuda a reducir la carga técnica asociada con la creación y el mantenimiento del código de prueba de BDD. Existen múltiples enfoques para las pruebas automatizadas de una aplicación, principalmente entre las que se encuentran las pruebas de API y las pruebas de IU. Parasoft puede reducir la carga técnica de cada uno de diferentes formas;

Reducir las barreras técnicas para implementar código de prueba a través de pruebas API con BDD

Parasoft permite a los no desarrolladores escribir definiciones paso a paso que se ejecutan como pruebas SOAtest, lo que reduce en gran medida los recursos técnicos necesarios para escribir pruebas. Con Parasoft SOAtest-Cucumber Executor, la definición de cada paso se asigna a una prueba SOAtest reutilizable o un conjunto de pruebas que se ejecuta cuando se ejecuta ese paso.

Considere los siguientes ejemplos:

  • Una definición de paso hace referencia a un cliente REST SOAtest que llama a una API específica
  • Una definición de segundo paso hace referencia a un cliente REST SOAtest conectado a una afirmación JSON que valida los datos en una respuesta de una API diferente.
  • Una definición de tercer paso hace referencia a una herramienta SOAtest DB conectada a un Value Assertor que ejecuta una consulta DB y valida los datos en el conjunto de resultados.

Las definiciones de pasos también pueden hacer referencia a una prueba SOAtest individual o un conjunto de pruebas que contiene una serie de pruebas.

Reduzca los costos de mantenimiento continuo de la automatización de pruebas de IU con Selenium y BDD

Surgen desafíos técnicos adicionales y únicos al integrar las pruebas de IU en su solución BDD. De manera similar a la solución de prueba de API de Parasoft, Parasoft Selenic tiene la capacidad de registrar las acciones de la interfaz de usuario desde el navegador y crear código Selenium puro que se puede asociar con sus definiciones de paso para impulsar la automatización de la prueba de la interfaz de usuario. Para reducir el mantenimiento continuo de los scripts de Selenium puros, Parasoft Selenic crea pruebas de Selenium aprovechando el modelo de objetos de la página. El modelo de objetos de página es un paradigma de diseño de pruebas de IU donde los usuarios pueden definir elementos de IU en asociación con las páginas en las que están presentes.Esto hace que sea mucho más fácil mantener sus scripts debido a que las ubicaciones de los elementos se definen en un solo lugar y luego se aprovechan en su suite de pruebas. Además de reducir las habilidades técnicas necesarias para crear los scripts de prueba iniciales en primer lugar.

Sin embargo, la creación es un costo único y la mayor parte de la carga incurrida por el código de prueba BDD está en el mantenimiento. Con el tiempo, a medida que su aplicación cambia, los localizadores de elementos y las condiciones de espera definidas inicialmente en el código de prueba subyacente de Selenium pueden romperse. Esto genera confusión al revisar los resultados de las pruebas porque es difícil determinar si sus pruebas fallan debido a defectos reales en la aplicación o simples cambios en la interfaz de usuario. Esto erosiona el valor que proporciona BDD. 

Activado dentro de su IDE, o, para CI / CD, con un cambio de código de una línea en la ejecución de la línea de comandos, Parasoft Selenic realiza un análisis en tiempo de ejecución de la ejecución de la prueba. Cuando una prueba falla, aplica su heurística de IA para determinar cómo se podría haber evitado esa falla, por ejemplo, actualizando localizadores o condiciones de espera), y luego intenta autocurar la prueba en tiempo de ejecución para que la tubería pueda continuar. Evita desperdiciar ciclos depurando fallas de compilación debido a pruebas inestables, y aprende más sobre sus pruebas al mismo tiempo.  

Todo esto reduce el tiempo que dedica al mantenimiento, reparación y reparación de pruebas rotas y le permite obtener los verdaderos beneficios de BDD, que es una mayor colaboración y una mayor confianza debido a la automatización de pruebas.

Reducir el costo asociado con la automatización de pruebas y BDD

Parasoft pone más control en manos de los probadores y les da la confianza de que han cubierto completamente la funcionalidad bajo prueba. Aprovechando un solución de prueba completa, madura y repleta de funciones proporciona una entrada fácil a la automatización de pruebas, el mantenimiento de pruebas y una integración natural en los flujos de trabajo de CI / CD existentes. En un nivel alto, permite a las organizaciones aprovechar menos recursos técnicos para implementar BDD, liberando recursos de desarrollo, cambiando el área de creación como se ilustra a continuación:

Conclusión

BDD es una práctica de desarrollo poderosa que puede garantizar que se construya la funcionalidad correcta. Sin embargo, escalar BDD a nivel empresarial puede ser difícil porque la implementación de la práctica requiere una gran cantidad de recursos técnicos. Parasoft reduce la barrera técnica al permitir a los usuarios asignar declaraciones de comportamiento a definiciones de ejecución de pasos utilizando un interfaz de usuario simple de entender. Las definiciones de pasos se ejecutan como SOAtest pruebas, lo que lo hace mucho más fácil para los probadores y el personal no técnico Contribuir al proceso de verificación. Parasoft Selenic reduce el mantenimiento continuo asociado con las pruebas de IU a través de Selenic al proporcionar recomendaciones generadas por IA para localizadores y condiciones de espera en tiempo de ejecución. 

Contáctese  si está interesado en aprender más sobre el Parasoft SOAtest-Pepino Ejecutor. O solicite una prueba gratuita haciendo clic a continuación. 

Nueva llamada a la acción

Escrito por

Grigori Trofimov

Grigori Trofimov es un arquitecto de soluciones en Parasoft, que brinda servicios de consultoría para las soluciones de prueba de Parasoft a prospectos, clientes y socios. Recientemente ha hablado en conferencias sobre el tema de la virtualización de servicios y el despliegue de entornos desechables en la nube.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft