Back to Event Details
Agile BDD - Work from the outside-In
Why is it necessary to understand customer requirements? Should we translate them to express behaviour about the system that is being built? Let’s learn how to translate a simple user story and test the Acceptance criteria via the BDD Cucumber approach.
My motive for this presentation is to explain an approach to software development that bridges the communication gap between business and development. The basic idea of BDD in this digital world is how to augment TDD (Test driven development) and ATDD(Acceptance Test Driven Development). If you want to deliver the right thing at the right time to your customers without misunderstanding the original idea and get them to visualise what needs to be built, join me to explore the idea in depth.
Goals & Objectives: I will run through the objectives for the session
Illustrate a flow explaining how an idea from a stakeholder or client gets misunderstood when the information starts moving from the business to the technical team. In a typical agile world, the Technical team start building the system within the 2 weeks iteration and have built something totally different from the original idea because of the communication gaps. As a result of which the code base is corrupted and the team have not met the user requirements. We will try and see what went wrong? Was it lack of high-quality communication, no collaboration between team members, confused user requirements. What really went wrong? Or Missing a collaboration tool like BDD. There is a need for BDD to work from the outside-in.
Touch base on BDD concepts and explain what Behaviour Driven Development is all about. I will present how can we work collaboratively when a story/feature is ready for implementation. The journey from start to end and how it gets tested by validating the Acceptance Criteria. Illustrate and build the bridge between the Technical and Non-technical members.
We will go through ‘Cucumber’, and see how it helps in communicating and expressing behaviour before the application can be built. We will understand to see how this becomes living documentation and a source of truth for the team.
I will present the cucumber testing stack that represents how a system gets tested. We will go through feature, scenarios and steps within the scenario that defines the behaviour of the system. We will go through other areas of the testing stack. – I will then present how a cucumber feature is written tested accordingly through Continuous Integration
Mohammed Rowther is an enthusiastic Agile Coach with an Engineering background in Information Technology and likes to spread the Agile principles across Organisations and teams that can start delivering value and respect culture.
With more than 17 years of experience in the IT industry, Mohammed Rowther is a highly motivated and competent Agile practitioner and has worked as an analyst, developer, tester, test manager and scrum master for several clients within an Agile environment.
“Quality is key to my clients”
I believe in giving more than 100% in whatever you do and loves acknowledging the effort.