Este documento describe los conceptos de BDD (comportamiento dirigido por desarrollo) y TDD (desarrollo dirigido por pruebas), destacando que BDD enfatiza la colaboración entre negocio, calidad y desarrollo mediante la escritura de especificaciones ejecutables en un lenguaje común, mientras que TDD se centra más en escribir pruebas unitarias que fallen inicialmente y luego hacerlas pasar a través del código. BDD y TDD no son lo mismo, pero comparten el objetivo de construir software
Como implementar La Automatización De Pruebas y No Morir En El IntentoSoftware Guru
Muchas personas piensan que la automatización de pruebas es descargar y/o usar una herramienta de pruebas y empezar a crear scripts, la verdad es que eso es solo una pequeña parte para poder implementarla de una forma adecuada y ordenada.
En esta sesión hablaremos de las fases(propuestas) desde la experiencia de un servidor para que tengas una base y sobre ella implementarla o adaptarla ya con un poco de más claridad a tu entorno.
La ingeniería de requerimiento en el proceso ágilSoftware Guru
Un error muy común de varias personas es creer que en un proceso ágil de desarrollo de software la Ingeniería de Requerimientos es innecesaria. Aunque se cambie: la ejecución de la disciplina, las técnicas aplicadas, el momento de ejecución del trabajo y el perfil de los responsables; la disciplina de requerimientos sigue siendo fundamental para el éxito en los proyectos.
El objetivo de esta ponencia es demostrar como La Ingeniería de Requerimientos es aplicada en el contexto ágil, utilizando el proceso Scrum a manera de ilustración.
Ésta es la presentación en la que me apoyé para realizar una formación sobre BDD usando Cucumber y Selenium. La presentación fue hecha conjuntamente con José Antonio Such.
Vision práctica del BDD (Behaviour Driven Design) para agilizar el proceso de...Software Guru
En esta ponencia vamos a presentar en la práctica el uso de BDD en el desarrollo, discutiremos cómo implementar BDD y presentar los beneficios alcanzados con su uso.
Presentada por: Marcelo Nascimiento
La arquitectura de microservicios persigue maximizar la adaptabilidad de las soluciones mediante la distribución de las responsabilidades del software en servicios con ciclo de vida independiente.
Lograr la independencia de los microservicios es clave para beneficiarse de las ventajas de la arquitectura. Esto exige un profundo entendimiento del dominio funcional, lo que se logra mediante DDD.
Por otro lado la arquitectura hexagonal nos permite estructurar el software de manera que la capa de código relacionada con el dominio funcional no se vea interferida por aspectos tecnológicos, es decir, que dicha capa sólo exprese el Ubiquitous Language, es decir el lenguaje del modelo en según lo llama DDD.
Dicha separación en capas y el invertir las dependencias permite además garantizar la máxima portabilidad del código.
¿Qué vamos a ver?
1. Beneficios
2. Domain Driven Design.
- Conceptos - Big Picture.
- Conceptos - Code architecture.
- Event Storming.
3. Clean Code Architecture.
- Hexagonal Architecture.
- Onion Architecture.
Como implementar La Automatización De Pruebas y No Morir En El IntentoSoftware Guru
Muchas personas piensan que la automatización de pruebas es descargar y/o usar una herramienta de pruebas y empezar a crear scripts, la verdad es que eso es solo una pequeña parte para poder implementarla de una forma adecuada y ordenada.
En esta sesión hablaremos de las fases(propuestas) desde la experiencia de un servidor para que tengas una base y sobre ella implementarla o adaptarla ya con un poco de más claridad a tu entorno.
La ingeniería de requerimiento en el proceso ágilSoftware Guru
Un error muy común de varias personas es creer que en un proceso ágil de desarrollo de software la Ingeniería de Requerimientos es innecesaria. Aunque se cambie: la ejecución de la disciplina, las técnicas aplicadas, el momento de ejecución del trabajo y el perfil de los responsables; la disciplina de requerimientos sigue siendo fundamental para el éxito en los proyectos.
El objetivo de esta ponencia es demostrar como La Ingeniería de Requerimientos es aplicada en el contexto ágil, utilizando el proceso Scrum a manera de ilustración.
Ésta es la presentación en la que me apoyé para realizar una formación sobre BDD usando Cucumber y Selenium. La presentación fue hecha conjuntamente con José Antonio Such.
Vision práctica del BDD (Behaviour Driven Design) para agilizar el proceso de...Software Guru
En esta ponencia vamos a presentar en la práctica el uso de BDD en el desarrollo, discutiremos cómo implementar BDD y presentar los beneficios alcanzados con su uso.
Presentada por: Marcelo Nascimiento
La arquitectura de microservicios persigue maximizar la adaptabilidad de las soluciones mediante la distribución de las responsabilidades del software en servicios con ciclo de vida independiente.
Lograr la independencia de los microservicios es clave para beneficiarse de las ventajas de la arquitectura. Esto exige un profundo entendimiento del dominio funcional, lo que se logra mediante DDD.
Por otro lado la arquitectura hexagonal nos permite estructurar el software de manera que la capa de código relacionada con el dominio funcional no se vea interferida por aspectos tecnológicos, es decir, que dicha capa sólo exprese el Ubiquitous Language, es decir el lenguaje del modelo en según lo llama DDD.
Dicha separación en capas y el invertir las dependencias permite además garantizar la máxima portabilidad del código.
¿Qué vamos a ver?
1. Beneficios
2. Domain Driven Design.
- Conceptos - Big Picture.
- Conceptos - Code architecture.
- Event Storming.
3. Clean Code Architecture.
- Hexagonal Architecture.
- Onion Architecture.
Eliminando la brecha entre clientes y desarrolladores mediante BDDJorge Gamba
Muchos, si no la mayoría, de los problemas o fracasos en proyectos de desarrollo de software se debe a que clientes y equipos de implementación de aplicaciones sencillamente no se entienden porque ven el mundo de manera muy distinta, hay una brecha entre ambas partes, dificultando materializar los requerimientos en software que realmente aporta valor para el negocio.
La metodología ágil BDD (Behavior-Driven Development) tiene precisamente el objetivo de lograr que ambas partes, cliente y equipo de desarrollo, en un proyecto se comuniquen de manera efectiva, ayudando a los primeros a especificar de manera sencilla y clara sus requerimientos, y a los segundos a entregar software que realmente cumple esas expectativas.
Tomando muchas de las buenas prácticas de desarrollo ágil de software y Lean, BDD fomenta y facilita la colaboración entre los miembros de diferentes roles, así como la integración de todas las etapas del proceso de desarrollo de software de tal manera que, aun escribiendo código fuente, nunca se pierda la referencia y conexión con las especificaciones del cliente, asegurando que el producto que se entrega coincide con ellas, es de calidad y, como un beneficio adicional, queda soportado por pruebas automatizadas.
Esta sesión mostrará, tanto a gente de negocios (gerentes de proyectos y analistas de negocios), como a gente técnica (especialistas en QA, arquitectos y desarrolladores de software), como aplicar BDD para obtener todos sus beneficios a la vez que hacen más felices a sus clientes con un proceso más eficiente y mejor producto.
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
En este seminario web, le mostraremos "en vivo" como en Chakray, logramos implementar una plataforma WSO2 completa en cuestión de minutos. - Uso de API Manager, Enterprise Integrator (ESB & BPS) e Identity Server.
- Todo en cluster, con alta disponibilidad y capacidades de escalabilidad horizontal
- En la nube (AWS)
- Totalmente automatizado, con DevOps (Ansible, Terraform, Docker, etc.)
- Con todas las capacidades de CI/CD incluidas
Watch the webinar on-demand here: https://wso2.com/library/webinars/despliegue-de-productos-wso2-la-metodologia-chakray/
Test driven development: advantages and common errors.
Why is important to use TDD?
What kind of things TDD give us?
Which are common errors using TDD?
With or without TDD?
Similar a Meetup bdd & tdd: aprovecha_su_poder (20)
En este documento analizamos ciertos conceptos relacionados con la ficha 1 y 2. Y concluimos, dando el porque es importante desarrollar nuestras habilidades de pensamiento.
Sara Sofia Bedoya Montezuma.
9-1.
Inteligencia Artificial y Ciberseguridad.pdfEmilio Casbas
Recopilación de los puntos más interesantes de diversas presentaciones, desde los visionarios conceptos de Alan Turing, pasando por la paradoja de Hans Moravec y la descripcion de Singularidad de Max Tegmark, hasta los innovadores avances de ChatGPT, y de cómo la IA está transformando la seguridad digital y protegiendo nuestras vidas.
Catalogo general Ariston Amado Salvador distribuidor oficial ValenciaAMADO SALVADOR
Distribuidor Oficial Ariston en Valencia: Amado Salvador distribuidor autorizado de Ariston, una marca líder en soluciones de calefacción y agua caliente sanitaria. Amado Salvador pone a tu disposición el catálogo completo de Ariston, encontrarás una amplia gama de productos diseñados para satisfacer las necesidades de hogares y empresas.
Calderas de condensación: Ofrecemos calderas de alta eficiencia energética que aprovechan al máximo el calor residual. Estas calderas Ariston son ideales para reducir el consumo de gas y minimizar las emisiones de CO2.
Bombas de calor: Las bombas de calor Ariston son una opción sostenible para la producción de agua caliente. Utilizan energía renovable del aire o el suelo para calentar el agua, lo que las convierte en una alternativa ecológica.
Termos eléctricos: Los termos eléctricos, como el modelo VELIS TECH DRY (sustito de los modelos Duo de Fleck), ofrecen diseño moderno y conectividad WIFI. Son ideales para hogares donde se necesita agua caliente de forma rápida y eficiente.
Aerotermia: Si buscas una solución aún más sostenible, considera la aerotermia. Esta tecnología extrae energía del aire exterior para calentar tu hogar y agua. Además, puede ser elegible para subvenciones locales.
Amado Salvador es el distribuidor oficial de Ariston en Valencia. Explora el catálogo y descubre cómo mejorar la comodidad y la eficiencia en tu hogar o negocio.
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta in...espinozaernesto427
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta intensidad son un tipo de lámpara eléctrica de descarga de gas que produce luz por medio de un arco eléctrico entre electrodos de tungsteno alojados dentro de un tubo de alúmina o cuarzo moldeado translúcido o transparente.
lámparas más eficientes del mercado, debido a su menor consumo y por la cantidad de luz que emiten. Adquieren una vida útil de hasta 50.000 horas y no generan calor alguna. Si quieres cambiar la iluminación de tu hogar para hacerla mucho más eficiente, ¡esta es tu mejor opción!
Las nuevas lámparas de descarga de alta intensidad producen más luz visible por unidad de energía eléctrica consumida que las lámparas fluorescentes e incandescentes, ya que una mayor proporción de su radiación es luz visible, en contraste con la infrarroja. Sin embargo, la salida de lúmenes de la iluminación HID puede deteriorarse hasta en un 70% durante 10,000 horas de funcionamiento.
Muchos vehículos modernos usan bombillas HID para los principales sistemas de iluminación, aunque algunas aplicaciones ahora están pasando de bombillas HID a tecnología LED y láser.1 Modelos de lámparas van desde las típicas lámparas de 35 a 100 W de los autos, a las de más de 15 kW que se utilizan en los proyectores de cines IMAX.
Esta tecnología HID no es nueva y fue demostrada por primera vez por Francis Hauksbee en 1705. Lámpara de Nernst.
Lámpara incandescente.
Lámpara de descarga. Lámpara fluorescente. Lámpara fluorescente compacta. Lámpara de haluro metálico. Lámpara de vapor de sodio. Lámpara de vapor de mercurio. Lámpara de neón. Lámpara de deuterio. Lámpara xenón.
Lámpara LED.
Lámpara de plasma.
Flash (fotografía) Las lámparas de descarga de alta intensidad (HID) son un tipo de lámparas de descarga de gas muy utilizadas en la industria de la iluminación. Estas lámparas producen luz creando un arco eléctrico entre dos electrodos a través de un gas ionizado. Las lámparas HID son conocidas por su gran eficacia a la hora de convertir la electricidad en luz y por su larga vida útil.
A diferencia de las luces fluorescentes, que necesitan un recubrimiento de fósforo para emitir luz visible, las lámparas HID no necesitan ningún recubrimiento en el interior de sus tubos. El propio arco eléctrico emite luz visible. Sin embargo, algunas lámparas de halogenuros metálicos y muchas lámparas de vapor de mercurio tienen un recubrimiento de fósforo en el interior de la bombilla para mejorar el espectro luminoso y reproducción cromática. Las lámparas HID están disponibles en varias potencias, que van desde los 25 vatios de las lámparas de halogenuros metálicos autobalastradas y los 35 vatios de las lámparas de vapor de sodio de alta intensidad hasta los 1.000 vatios de las lámparas de vapor de mercurio y vapor de sodio de alta intensidad, e incluso hasta los 1.500 vatios de las lámparas de halogenuros metálicos.
Las lámparas HID requieren un equipo de control especial llamado balasto para funcionar
2. ¿Quién soy?
Eduardo Riol, Líder Técnico de QA & Testing en
atSistemas.
Comencé desarrollando en entornos Java y .NET hace
alrededor de una década pero he dedicado los últimos
siete años a la Calidad del Software, tanto orientada
al producto como a los procesos de desarrollo.
Actualmente mis intereses se centran en el control de
la deuda técnica, BDD y la integración de las
actividades de QA en entornos Agile y DevOps.
twitter.com/eduriol
github.com/eduriol
linkedin.com/in/eduriol
3. Houston, we have a problem!
“Esto no es lo que habíamos pedido” ¿Nos suena?
El teléfono
escacharrado
The Gossips, Norman Rockwell, 1948
4. Nos enfocamos en construir el software
CORRECTAMENTE…
Testing funcional
Tests unitarios
Testing de rendimiento
Testing de integración
Análisis estático Hacking ético
Auditorías de procesos
UAT
5. … ¿pero estamos construyendo el software CORRECTO?
Features Used
The Standish Group estimate of features used in custom application development, 2014
Hardly Ever
50%
Often
20%
Infrequently
30%
6. No confiamos en las releases
La mayoría de las veces no
contamos con una suite de tests
de aceptación lo suficientemente
robusta y completa como para
fiarnos de ella
7. ¿Y la colaboración dentro del equipo?
¿Desarrollo? Creo que son los que se
sientan en el zulo ese de la cuarta
planta
Tenemos problemas
de calidad
No es mi problema, de la
calidad se encarga la gente
QA, ¿no?
La gente de Desarrollo no para de
devolverme el software sin corregir el
bug
8. Este problema parte de aquí
Como fases separadas, estimadas y
planeadas al principio del proyecto
• Análisis
• Desarrollo
• Testing
• Operaciones
9. BDD: Cómo colaboran Desarrollo y Negocio
BDD es un modelo de colaboración entre los usuarios de Negocio
y el equipo de Desarrollo…
… que consiste en establecer conversaciones basadas en ejemplos
concretos de uso de la aplicación, con el objetivo de reducir
malentendidos y asunciones…
… descubriendo en el proceso las features que realmente aportan
valor
10. ¿Entonces qué es (y qué no) BDD?
• Escribir requisitos en lenguaje
Gherkin
• Automatizar pruebas con
Cucumber
• Documentar funcionalidades
después de programarlas
• Modelo de colaboración
• Un proceso de descubrimiento
• Entender necesidades de
Negocio
• Describir el software con
ejemplos
Qué es Qué no es
11. BDD: Cómo colaboran Desarrollo y Negocio
• Los ejemplos que describen una nueva
feature se plasman en un lenguaje sencillo
y común, sin ambigüedades (por ejemplo
Gherkin)
• El equipo de Desarrollo transforma estos
ejemplos en una serie de especificaciones
ejecutables como tests automáticos
• Una feature del software está acabada
cuando todas sus especificaciones se
ejecutan correctamente
BDD
TDD
Escribir un test que falla
N ciclos
13. Un escenario de colaboración
Queremos que nuestra aplicación requiera un
password que tenga que tener al menos 8
caracteres, un número y una mayúscula
Password strenght, xkcd, Randall Munroe
Password Seguridad Aceptable?
secret Débil No
password Débil No
password1 Débil No
aBcdEfg1 Débil No
qwertY12 Débil No
dJeZDip1 Medio Sí
GaviotaErizo Fuerte Sí
GaviotaErizoCatapulta Muy fuerte Sí
¿No querrás decir que quieres
que la aplicación requiera un
password seguro?
14. Implementando BDD: Describiendo escenarios
ESCENARIO
Envío del formulario de contacto
Dado que Juan Pérez entra al formulario de contacto
Y rellena los campos con sus datos y el mensaje
Y acepta las cláusulas legales
Cuando envía la consulta
Entonces se muestra la confirmación de
la correcta recepción del mensaje
Dado / Given: Define el contexto en el cual se
ejecuta el escenario. En este paso se
determinan las condiciones de partida del
ejemplo.
Cuando / When: Es la acción que desata el
ejemplo. Consiste en la interacción con la
aplicación, normalmente de un usuario, cuyo
comportamiento se quiere validar.
Entonces / Then: En este paso se define el
resultado esperado por Negocio. La condición
que se debe cumplir para que el escenario se
haya ejecutado correctamente.
15. Implementando BDD: Automatizando escenarios
Escenario: Transfiriendo dinero a una cuenta de ahorros
Dado que mi cuenta Corriente tiene un balance de 1000.00
Y que mi cuenta Ahorro tiene un balance de 2000.00
Cuando transfiero 500.00 de mi cuenta Corriente a mi cuenta Ahorro
Entonces debo tener 500.00 en mi cuenta Corriente
Y debo tener 2500.00 en mi cuenta Ahorro
@Given(“^que mi cuenta (.*) tiene un balance de (d+)$")
public void setupInitialAccount(AccountType accountType,
double amount) {
// Setup account
}
@When(“^transfiero (d+) de mi cuenta (.*) a mi cuenta (.*)$")
public void transferAmountBetweenAccounts(double amount, AccountType source, AccountType destination) {
// Perform action
}
@Then(“^debo tener (d+) en mi cuenta (.*)$")
public void checkAccountAmount(double amount, AccountType accountType) {
// Assert amount
}
16. Testing exploratorio
Niveles de BDD: La pirámide del testing
UI
API / Services
Unit
UI (manual & automático)
API / Services
Unit
Prevenir errores / Aportar valor Detectar errores / Certificar releases
17. ¿Pero entonces BDD y TDD son lo mismo?
My experience is that BDD’s emphasis on collaboration, and the use
of business-readable, executable specifications, means that this
shared language develops much more quickly. When everyone is
involved in writing documentation that describes what the system
should do, they all get a chance to learn the language of the
domain together.
So BDD really isn’t all that different to TDD. What BDD adds is a
clear emphasis on what it takes to make TDD succeed.
Matt Wynne
18. BDD en el proceso de construcción del software
La ejecución de los escenarios deben ser parte del proceso de
integración, construcción y despliegue del software.
Cada escenario debe poder ejecutarse de forma separada, sin ningún
orden concreto. No debe haber dependencia entre escenarios.
Los escenarios son un activo más de código a mantener bajo control de
versiones.
El proceso de construcción y despliegue del software también pasa a
ser un proceso de construcción y despliegue de documentación e
informes.
19. ¡Ojo!, BDD no es una bala de plata
Implicación de Negocio: necesitamos que los involucrados
se impliquen desde el comienzo.
BDD está pensado para Agile: es un modelo de colaboración
de cara al descubrimiento iterativo de requisitos.
A BDD no le gustan los silos: si la organización
trabaja en grupos aislados y la colaboración no fluye,
desaparece la aclaración progresiva de objetivos.
Riesgo de alto coste en mantenimiento de tests: se requiere
experiencia y conocimiento para diseñar especificaciones
funcionales mantenibles e implementarlas correctamente