Congreso Testing Day Ve 2023
¿Porqué mis pruebas fallan cuando uso BDD?
Behavior Driven Development (BDD) Como bien lo indica su nombre, no se trata de una técnica de testing, sino que es una estrategia de desarrollo de software. En pocas palabras es definir un lenguaje común para el negocio y para los técnicos, y utilizar eso como parte inicial del desarrollo y el testing. Sin embargo el uso de BDD ha sido explotado de mala forma en el área de la automatización de pruebas, llevando a proyectos fallidos debido a la complejidad de crear casos de prueba así como el nulo entendimiento del proceso y asociando herramientas como cucumber y Gherkin a este término. En esta Charla nos enfocaremos en como implementar BDD y su relación en el área de las pruebas de software.
Gilberto Sanchez Mares AKA Mexitester
Únete a las actividades que realizaremos
Summary of «Why My Tests Fail When I Use BDD» by Mexitester
Detailed Summary
The video begins by questioning the common practice of adopting methodologies and tools used by renowned companies like Netflix or Facebook without analyzing whether they are suitable for the project at hand. Mexi tester emphasizes that each project has unique needs and that planning should be based on those needs, not on trends or fads.
The idea that Martin Fowler’s test pyramid is the only correct way to test is criticized. It is argued that this pyramid, which prioritizes unit testing, may not be applicable to all projects, especially those focused on the backend or in advanced projects where creating unit tests might not be efficient.
The evolution from Test Driven Development (TDD) to Behavior Driven Development (BDD) is discussed. It is explained that TDD, although useful, often created a gap between technical and business teams. BDD seeks to close this gap by fostering collaboration and the use of a common language to define requirements and test scenarios.
The idea that BDD is simply writing test cases is demystified. It is clarified that BDD is a broader process that involves the discovery, formulation, and automation of scenarios. The importance of communication and shared understanding in all stages of the process is emphasized.
The three main phases of BDD are presented:
- Discovery: Gathering information and defining business rules.
- Formulation: Creating scenarios using natural language (Gherkin) to describe the desired system behavior.
- Automation: Implementing automated tests based on the defined scenarios.
Tools like Cucumber and SpecFlow that facilitate BDD implementation are mentioned. It is highlighted that the use of these tools does not guarantee the success of BDD and that the most important aspect is the process of collaboration and shared understanding.
Conclusion
The video concludes by reiterating the importance of planning and communication in BDD implementation. Teams are urged not to blindly follow trends, but to adapt methodologies and tools to the specific needs of each project.
In summary, BDD is a powerful tool for improving software Quality and collaboration between teams, but its success depends on a deep understanding of its principles and a careful application adapted to the project’s context.
Únete a las actividades que realizaremos
Resumen de «Por qué Mis Pruebas Fallan Cuando Uso BDD» por Mexitester
El video comienza cuestionando la práctica común de adoptar metodologías y herramientas utilizadas por empresas de renombre como Netflix o Facebook sin analizar si son adecuadas para el proyecto en cuestión. Mexi Tester enfatiza que cada proyecto tiene necesidades únicas y que la planificación debe basarse en esas necesidades, no en tendencias o modas.
Se critica la idea de que la pirámide de pruebas de Martin Fowler es la única forma correcta de hacer pruebas. Se argumenta que esta pirámide, que prioriza las pruebas unitarias, puede no ser aplicable a todos los proyectos, especialmente aquellos centrados en el backend o en proyectos ya avanzados donde la creación de pruebas unitarias podría no ser eficiente.
Se discute la evolución de Test Driven Development (TDD) a Behavior Driven Development (BDD). Se explica que TDD, aunque útil, a menudo creaba una brecha entre los equipos técnicos y de negocio. BDD busca cerrar esta brecha al fomentar la colaboración y el uso de un lenguaje común para definir los requisitos y escenarios de prueba.
Se desmitifica la idea de que BDD es simplemente escribir casos de prueba. Se aclara que BDD es un proceso más amplio que involucra el descubrimiento, la formulación y la automatización de escenarios. Se enfatiza la importancia de la comunicación y el entendimiento compartido en todas las etapas del proceso.
Se presentan las tres fases principales de BDD:
- Discovery: Recopilación de información y definición de reglas de negocio.
- Formulation: Creación de escenarios utilizando un lenguaje natural (Gherkin) para describir el comportamiento deseado del sistema.
- Automation: Implementación de pruebas automatizadas basadas en los escenarios definidos.
Se mencionan herramientas como Cucumber y SpecFlow que facilitan la implementación de BDD. Se destaca que el uso de estas herramientas no garantiza el éxito de BDD y que lo más importante es el proceso de colaboración y entendimiento compartido.
Conclusión
El video concluye reiterando la importancia de la planificación y la comunicación en la implementación de BDD. Se insta a los equipos a no seguir ciegamente las tendencias, sino a adaptar las metodologías y herramientas a las necesidades específicas de cada proyecto.
Gilberto Sanchez Mares AKA Mexitester
quality assurance Quality Control