Behaviour Driven Development is an increasingly popular Agile development practice that turns testing on its head. It turns automated acceptance testing from a verification activity, done once the development work is done, to a specification activity, with tester involvement starting from the word go.
In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to contribute much more to the successful outcomes of the project. We will see how collaboratively written acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are both well understood and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance tests. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress and release preparation reporting.
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
"Given..When..Then"...a common perception of Behaviour Driven Development focuses on writing and automating SpecFlow-style scenarios. In fact this is just a small part of BDD: the full scope of BDD ranges from requirements discovery and description, through to driving technical design and implementation, helping testers focus their testing efforts more effectively, and even providing reliable, useful and accurate technical documentation. In this talk, you will learn about how much more there is to BDD than just "Given..When..Then"!
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
Slides from the London Agile Testing Meetup of November 25 2014:
John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month).
John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.
Think BDD is just for web sites? Think again! In this talk, we rethink traditional software testing strategies in the context of micro-services and Behaviour-Driven Development. We will see how traditional testing approaches are both inadequate and poorly targeted for micro-services development. We will learn how to use BDD techniques to discover, describe and document micro-service requirements, and tools like Cucumber and Serenity to turn these requirements into automated acceptance tests and living documentation. We will see how Consumer-Driven Contract tools help ensure that micro-services play well together, and how you can implement the details with the help of unit-testing tools like Spock and REST-Assured.
Behaviour-Driven Development (BDD) is a game changer for the whole team! More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery. In this session, you will learn what BDD is about, its benefits, and how it affects development teams and processes. But you will also see BDD techniques applied to a real project using tools like JBehave, Cucumber, Selenium 2, Thucydides and more!
- Learn how BDD helps teams focus on discovering and delivering the features that really matter! - Learn what it takes to write more relevant and more maintainable automated acceptance tests - Discover how a well-designed set of automated acceptance criteria can also be a powerful documentation and reporting tool. - See where BDD fits into a Continuous Delivery pipeline.
- And learn how product owners use BDD and Thucydides to drive, coordinate and document releases.
Learn how much more there is to BDD than just “Given..When..Then”!
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
"Given..When..Then"...a common perception of Behaviour Driven Development focuses on writing and automating SpecFlow-style scenarios. In fact this is just a small part of BDD: the full scope of BDD ranges from requirements discovery and description, through to driving technical design and implementation, helping testers focus their testing efforts more effectively, and even providing reliable, useful and accurate technical documentation. In this talk, you will learn about how much more there is to BDD than just "Given..When..Then"!
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
Slides from the London Agile Testing Meetup of November 25 2014:
John Ferguson Smart is a specialist in BDD, automated testing and software life cycle development optimization. John is a well-known speaker at many international conferences and events and an accomplished author (John's new book BDD in Action was published last month).
John presents a talk discussing how to write solid, reliable and maintainable automated web tests using the best-of-breed open source technologies like Selenium WebDriver, Serenity, JBehave and Cucumber.
Think BDD is just for web sites? Think again! In this talk, we rethink traditional software testing strategies in the context of micro-services and Behaviour-Driven Development. We will see how traditional testing approaches are both inadequate and poorly targeted for micro-services development. We will learn how to use BDD techniques to discover, describe and document micro-service requirements, and tools like Cucumber and Serenity to turn these requirements into automated acceptance tests and living documentation. We will see how Consumer-Driven Contract tools help ensure that micro-services play well together, and how you can implement the details with the help of unit-testing tools like Spock and REST-Assured.
Behaviour-Driven Development (BDD) is a game changer for the whole team! More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery. In this session, you will learn what BDD is about, its benefits, and how it affects development teams and processes. But you will also see BDD techniques applied to a real project using tools like JBehave, Cucumber, Selenium 2, Thucydides and more!
- Learn how BDD helps teams focus on discovering and delivering the features that really matter! - Learn what it takes to write more relevant and more maintainable automated acceptance tests - Discover how a well-designed set of automated acceptance criteria can also be a powerful documentation and reporting tool. - See where BDD fits into a Continuous Delivery pipeline.
- And learn how product owners use BDD and Thucydides to drive, coordinate and document releases.
Learn how much more there is to BDD than just “Given..When..Then”!
ehaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
• Learn what BDD is, and what it is not
• Understand that the core of BDD is around conversation and requirements discovery, not around tools.
• Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them.
This is a variation on the talk I gave at Agile Australia, that I delivered at the Sydney Agile meetup on July 15 2014.
It's nice to work on Green Fields projects. But most of us aren't that lucky! Most organisations have large legacy code bases to maintain. And the legacy applications, ugly as they are, are often what generates the revenue!
But legacy code bases are not easy to work with. Adding new features, or even fixing bugs, is slow and fraught with danger. Unexpected regressions are commonplace. Long testing cycles is the norm.
In this talk we will look at some strategies that can enable you to add new features to legacy systems faster and more reliably. We will examine where the hold-ups typically are, and what We will learn how to write cost-effective automated regression tests suites, and how to use unit testing as a way to document your legacy code base for future work, and improve its quality along the way!
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones that the client actually needs.
In this talk, we will discuss what BDD is about, its benefits, and how it affects teams and processes. We will discuss two case studies where BDD practices have been successfully introduced, including the benefits gained and challenges met. We will see how much benefit was gained when BDD was integrated into the broader development infrastructure, including issue tracking systems, requirements management, and project reporting.
We will also see how BDD can be applied to all levels of the development process, from requirements down to low-level coding. We will also look at the principle BDD tools available that can help teams implement executable specifications, BDD-style test automation, and living documentation effectively. Some of the tools discussed will include JBehave, Cucumber, Specflow, Jasmine and Spock.
We will also look at two case studies where BDD practices have been successfully integrated into several projects in large government and financial organizations. Teams that adopted BDD effectively benefited from significantly lower defect rates, much earlier discovery of errors and inconsistencies in the requirements, and better overall communication and collaboration within the team. However, practicing BDD does involve a significant change in mind-set compared to more traditional approaches, a different collaboration model between team members, and a high degree of stakeholder by-in and engagement, all of which should not be underestimated. We will discuss how the teams managed these various challenges during their BDD adoption story.
An overview of Behavioral Driven Development (BDD). This deck covers the basics with an overview as well as some information on why to use Behavioral Driven Development.
Behaviour Driven Development is an increasingly popular Agile practice that turns testing on its head, and involves a major shift in the role testers play in a project. Although popularly associated with automated acceptance testing and tools like Cucumber, BDD actually has much broader applications. In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to tangibly contribute much more to the successful outcomes of the project. We will see how collaboratively discussing and defining acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are well understood, testable, and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance criteria, that free testers to do more productive testing tasks such as exploratory testing. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress, product documentation and release preparation reporting.
Patterns of Automation: Simplify Your Test CodeTechWell
Many organizations are introducing test automation only to discover it is more difficult than they anticipated. The fact is that good test automation requires good coding practices. Good test automation requires good design. To do anything else will lead to spaghetti code that is hard to maintain or update. If you’re new to coding or new to automation, it is difficult to know where to begin. Join Cheezy as he describes and demonstrates lessons he has learned while helping numerous organizations adopt test automation. Cheezy shows the patterns he uses to keep automation code simple and clean, and demonstrates techniques you can use to make your automation code more maintainable. Finally, Cheezy writes code (without a net) to implement these patterns, taking them from theory to implementation.
Tdd vs bdd vs atdd — developers’ methodologies to navigate complex developmen...Katy Slemon
Know key differences between major development methodologies TDD vs BDD vs ATDD in this post that focus on the task of the developers and their creations
BDD in open source projects - Is it really beneficial?Fabian Kiss
You can easily use tools such as Behat and phpspec for practicing BDD in PHP. Regardless of the specific BDD tools, the question of how to do BDD “properly” arises. According to Dan North, initiator of the BDD philosophy, it should be be practiced as a “mutliple-stakeholder, agile methodology”. However, most open-source projects are not developed with an explicit agile methodology. Also, there are hardly any stakeholder roles that are clearly distinguishable from each other - often contributor and user are actually one and the same. So, in the case of open-source projects, you can question the benefit of BDD.
Improving the delivery of critical project milestones through requirements specificity by means of greater specialization of the role of Business Analyst in Information Technology.
Automation Testing Experience, total 2 yrs 2 months+ in Selenium and QTP . Keen in learning new technologies, good team player and taking individual responsibility and ownership
Behaviour Driven Development from the ground up. Non-technical introduction that motivates the adoption of BDD.
Best viewed as a video. Should be followed by Matt Wynne's session "BDD can save your agile"
This slide deck was orignally prepared by Steve Tooke for CukeUp AU and then modified and presented by Seb Rose to
ehaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
• Learn what BDD is, and what it is not
• Understand that the core of BDD is around conversation and requirements discovery, not around tools.
• Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them.
This is a variation on the talk I gave at Agile Australia, that I delivered at the Sydney Agile meetup on July 15 2014.
It's nice to work on Green Fields projects. But most of us aren't that lucky! Most organisations have large legacy code bases to maintain. And the legacy applications, ugly as they are, are often what generates the revenue!
But legacy code bases are not easy to work with. Adding new features, or even fixing bugs, is slow and fraught with danger. Unexpected regressions are commonplace. Long testing cycles is the norm.
In this talk we will look at some strategies that can enable you to add new features to legacy systems faster and more reliably. We will examine where the hold-ups typically are, and what We will learn how to write cost-effective automated regression tests suites, and how to use unit testing as a way to document your legacy code base for future work, and improve its quality along the way!
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones that the client actually needs.
In this talk, we will discuss what BDD is about, its benefits, and how it affects teams and processes. We will discuss two case studies where BDD practices have been successfully introduced, including the benefits gained and challenges met. We will see how much benefit was gained when BDD was integrated into the broader development infrastructure, including issue tracking systems, requirements management, and project reporting.
We will also see how BDD can be applied to all levels of the development process, from requirements down to low-level coding. We will also look at the principle BDD tools available that can help teams implement executable specifications, BDD-style test automation, and living documentation effectively. Some of the tools discussed will include JBehave, Cucumber, Specflow, Jasmine and Spock.
We will also look at two case studies where BDD practices have been successfully integrated into several projects in large government and financial organizations. Teams that adopted BDD effectively benefited from significantly lower defect rates, much earlier discovery of errors and inconsistencies in the requirements, and better overall communication and collaboration within the team. However, practicing BDD does involve a significant change in mind-set compared to more traditional approaches, a different collaboration model between team members, and a high degree of stakeholder by-in and engagement, all of which should not be underestimated. We will discuss how the teams managed these various challenges during their BDD adoption story.
An overview of Behavioral Driven Development (BDD). This deck covers the basics with an overview as well as some information on why to use Behavioral Driven Development.
Behaviour Driven Development is an increasingly popular Agile practice that turns testing on its head, and involves a major shift in the role testers play in a project. Although popularly associated with automated acceptance testing and tools like Cucumber, BDD actually has much broader applications. In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to tangibly contribute much more to the successful outcomes of the project. We will see how collaboratively discussing and defining acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are well understood, testable, and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance criteria, that free testers to do more productive testing tasks such as exploratory testing. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress, product documentation and release preparation reporting.
Patterns of Automation: Simplify Your Test CodeTechWell
Many organizations are introducing test automation only to discover it is more difficult than they anticipated. The fact is that good test automation requires good coding practices. Good test automation requires good design. To do anything else will lead to spaghetti code that is hard to maintain or update. If you’re new to coding or new to automation, it is difficult to know where to begin. Join Cheezy as he describes and demonstrates lessons he has learned while helping numerous organizations adopt test automation. Cheezy shows the patterns he uses to keep automation code simple and clean, and demonstrates techniques you can use to make your automation code more maintainable. Finally, Cheezy writes code (without a net) to implement these patterns, taking them from theory to implementation.
Tdd vs bdd vs atdd — developers’ methodologies to navigate complex developmen...Katy Slemon
Know key differences between major development methodologies TDD vs BDD vs ATDD in this post that focus on the task of the developers and their creations
BDD in open source projects - Is it really beneficial?Fabian Kiss
You can easily use tools such as Behat and phpspec for practicing BDD in PHP. Regardless of the specific BDD tools, the question of how to do BDD “properly” arises. According to Dan North, initiator of the BDD philosophy, it should be be practiced as a “mutliple-stakeholder, agile methodology”. However, most open-source projects are not developed with an explicit agile methodology. Also, there are hardly any stakeholder roles that are clearly distinguishable from each other - often contributor and user are actually one and the same. So, in the case of open-source projects, you can question the benefit of BDD.
Improving the delivery of critical project milestones through requirements specificity by means of greater specialization of the role of Business Analyst in Information Technology.
Automation Testing Experience, total 2 yrs 2 months+ in Selenium and QTP . Keen in learning new technologies, good team player and taking individual responsibility and ownership
Behaviour Driven Development from the ground up. Non-technical introduction that motivates the adoption of BDD.
Best viewed as a video. Should be followed by Matt Wynne's session "BDD can save your agile"
This slide deck was orignally prepared by Steve Tooke for CukeUp AU and then modified and presented by Seb Rose to
New is Easy but Right is Hard: Hacking Product ManagementBernard Leong
Talk given on 15 Nov 2013, in Hackers & Painters (http://http://hackersandpainters.sg/), Singapore @ Blk 71.
Synopsis: A great product is a synthesis of technology and business thinking. How do we decide what goes into the product and determine the roadmap of the product? How do we establish the balance between the business and technology of the product? In this session, we discuss some interesting lessons learned on product management and why both business leaders and technologists don't get it.
Kanban Workflow Best Practices for each Role in a Software Team — Part 3 of "...Blossom IO Inc.
Part 3 of the "How to build the best Software Products" Series, brought to you by Blossom.co
Examples & best practices for a continuous workflow covering the activity of each role in a software team.
Roles:
1. Designer & UX
2. Engineer
3. Marketer
4. Product Manager
Additional:
5. Activity & Reports
How Agile Reduces Requirements Risk Ebg Consulting Slide ShareEBG Consulting, Inc.
Learn how agile practices reduce the many risks associated with requirements in this presentation by EBG Consulting's Ellen Gottesdiener.
To read a companion article, go to:
http://ebgconsulting.com/Pubs/Articles/HowAgilePracticesReduceReqtsRisk_BetterSw_Gottesdiener_JuAu2009.pdf
Positioning of the BA practice in the agile, what is the role of BA and how she/he fits in the agile ceremonies, what is the basic role she/he plays and what are the common tools BA uses and can she/he replaces any of the Agile known roles.
============== Follow us ==============
Website: http://xpdays.org
Linked In: https://www.linkedin.com/company/xpdays
Facebook: https://www.facebook.com/xpdaysorg
Twitter: https://twitter.com/xpdaysorg
#agile #business_analysis #xpdays #agilearena
This CodeIT company presentation gives a short description of the way CodeIT outsourcing company provides software development services and cooperate with clients from 32 countries around the world.
Pair Programming, TDD and other impractical thingsMarcello Duarte
"Why should we write our tests first? Isn't that going to slow my development?" "What? Assigning a single task to 2 developers? How is that efficient? What a waste of resources!" "Look, in the perfect world your advises are great, but I have a project to finish here." In this talk Marcello explores efficiency in contrast to effectiveness. He looks into how practices, traditionally accepted as efficient, sometimes turn out to be less effective than a few "impractical" things he has come across.
Google Featured Snippets, the Discover Feed & More Must-Know SEO Insights, SE...Brodie Clark
The past year has seen massive changes to Featured Snippets on Google. AMP and Chrome are influencing the content on our pages when in the featured position, and deduplication has put a real spanner in the works. And have you heard about what’s happening with Google’s Discover Feed currently?
You’ll want to make sure you’re in the loop for the year ahead – your client traffic sources could be significantly altered from the recent uptake. Watch the replay of this webinar with Brodie Clark to learn more.
From 50 to 500 product engineers – data-driven approach to building impactful...DevClub_lv
Erik Kaju from Wise will give a talk “From 50 to 500 product engineers – data-driven approach to building impactful and efficient product teams”.
Product engineering is data-driven. It is best to avoid personal opinions and back actions with data. Sharing data transparently and making it broadly accessible within the whole company helps to scale and build faster. Data-driven practices are useful beyond just product development. Over the years, we have been systematic and methodological in how we scale the company and track its health.
This is a story of Wise growing from a regular-sized with 50 engineers to one with 500. While our headcount has grown tenfold, the speed of our releasing and ability to deliver complex projects has risen significantly. It is crucial for the scale-up to not slow down. And that is only possible with effective and unhampered teams. Join Erik for fresh insights that will inspire you to grow your teams, track their health and experiment with team metrics.
(Language – English)
Erik is Director of Engineering at Wise.
What are Strategies to Manage Stakeholders by Boeing PMProduct School
A Product Managers ability to manage numerous stakeholders and conflicting priorities is vital when working to deliver valuable software to users. The strategies used to manage stakeholders is a key skillset in a Product Managers toolbox. In this presentation Dan overviews the importance of stakeholder involvement. He also provides practical strategies for Product Managers to facilitate mutual benefit for product teams and their various stakeholders.
Written specs are easy to read but hard to write. Even with an understanding of the principles and tips for writing good Gherkin, it can be very hard to keep scenarios clean, informative and readable.
These slides are from a workshop given by John Ferguson Smart and Tom Roden, where they take a practical look at some real-world Gherkin scenarios, investigate what makes them smell and practise how to improve them. Discover some powerful refactoring patterns to help make your own specs a joy to read.
It was the time of Da Vinci and Michelangelo. It was also the time of Machiavelli and the Medici. Artists working on timeless masterpieces crossed paths with mercenary captains, contracted to do a very specific job.
In this keynote talk, John Smart will address important questions with deep implications for any IT team, or any organisation trying to make a difference, or simply to get the most value out of their IT projects.
Who is your real customer? Is there a cost to quality? Are you building an artwork that will last, or simply fulfilling a contract?
An inspiring and entertaining talk that will take attendees on journey from the Italian Renaissance to Silicon Valley and the City of London, and see what lessons can be learned about cultures, attitudes and work ethics today.
Discover how you can multiply your team’s productivity and innovation by engaging the creativity of your whole team from the outset. Drawing from his long experience helping teams deliver better software faster and more effectively, John will discuss the latest practical techniques leveraged from Behaviour Driven Development, Lean Enterprise, DevOps, and Test Automation, combined with research in Psychology and Team Performance, to show you how to get the best out of your teams.
Learn about the new roles of business analysts, developers and testers in the future of software development, where testers can play a vital role in not only detecting defects but preventing them. Discover how you can make test automation happen during, not after, the sprint, and how to engage the creativity of the whole team right from the word "go".
his talk will present the core concepts of Exponential Business Agility, or XBA. XBA is a set of patterns for organising value streams around self-organising, autonomous teams, and is part of the XSCALE approach to scaling agile. XBA combines the Spotify model with practice patterns drawn from the Iroquois Confederacy, the most successful and longest-lived holarchy in history.
Learn how Throughput Accounting optimises the contribution of each business function to top line throughput rather than blindly attempting to minimise operating expense.
And discover how Self-Propagating Transformation avoids pushing change into pre-existing teams, programs or silos, but generates agile capability by grafting the kernel of a new culture onto the trunk of the old.
Be a pod of dolphins, not a dancing elephant. Don’t try to scale agile. De-scale your organisation instead.
As projects get faster and teams get leaner, the need to write high quality automated acceptance criteria quickly and efficiently has never been greater. Engineers in Test simply cannot afford to spend time maintaining brittle tests. And yet, without solid test automation strategies, this is what many teams find themselves doing. In this workshop, you will learn a better way. You will learn how to write clean, clear and maintainable tests using the Screenplay Pattern, an innovative new approach to writing BDD-style automated acceptance tests that are easier to understand, easier to extend and easier to maintain. The workshop will be a practical demonstration of the principles of good automated test design. There will be live coding of real-world BDD automated acceptance tests in abundance, using Java, Serenity BDD and Cucumber. We will go from requirements and BDD-style Acceptance Criteria in Cucumber right through to automated acceptance tests and living documentation.
Writing good acceptance criteria is one of the keys to effective software delivery. But it’s hard. In this workshop, you will learn about Feature Mapping, a new technique and easy that can help teams write higher quality acceptance criteria more easily. Feature Mapping is an excellent way to build a deep shared understanding of a story's requirements and clear a path to a smooth implementation of automated acceptance tests.
International speaker and author of “BDD in Action” John Ferguson Smart shows how you can multiply your team’s productivity and innovation by engaging the creativity of your whole team from the outset. Drawing from his long experience helping teams deliver better software faster and more effectively, John will discuss the latest practical techniques leveraged from Behaviour Driven Development, Lean Enterprise, DevOps, and Test Automation, combined with research in Psychology and Team Performance, to show you how to get the best out of your teams. Learn about the new roles of business analysts, developers and testers in a DevOps world, and how testers can play a vital role in not only detecting defects but preventing them. Discover how you can make test automation happen during, not after, the sprint, and how to engage the creativity of the whole team right from the word "go".
IT teams today are under constant pressure to deliver more value sooner, and Behaviour Driven Development (BDD) is one of the more effective ways to help teams deliver the high quality software that their business needs. When they adopt BDD, many teams look to tools like Cucumber to help them. But BDD isn’t simply about picking up a new tool.
In fact, there is a lot more to BDD than Given/When/Then and tools like Cucumber, and both can be misused. In this talk, we will take a step back and look at the bigger picture, and learn why using Gherkin at the wrong time, or for the wrong purpose, may be holding you back.
IT teams today are under constant pressure to deliver more value sooner, and Behaviour Driven Development (BDD) is one of the more effective ways to help teams deliver the high quality software that their business needs. When they adopt BDD, many teams look to tools like Cucumber to help them. But BDD isn’t simply about picking up a new tool.
In fact, there is a lot more to BDD than Given/When/Then and tools like Cucumber, and both can be misused. In this talk, we will take a step back and look at the bigger picture, and learn why using Gherkin at the wrong time, or for the wrong purpose, may be holding you back.
The changing role of testing and test automation in the increasingly fast-paced world of continuous delivery and automated acceptance testing. Learn how, in a DevOps environment, testing activities start with requirements discovery and definition, playing a vital role in not only detecting defects, but preventing them, and ensuring not only that the features are built right, but the right features are built. And learn how test automation needs to happen during, not after, the sprint, and how you can achieve this.
Despite rumors to the contrary, the role of the tester is not diminished with the arrival of automated DevOps, with its ultra-rapid deployment cycles and its emphasis on automation. On the contrary, testers play a vital role in ensuring that the code that gets deployed ten times a day is worth deploying.
Learn how to write robust and articulate tests using the Screenplay Pattern, an innovative approach to writing BDD-style automated acceptance tests that are easier to understand, easier to extend and easier to maintain.
The essentials of Cucumber-JVM and Spock - a handbook written for the BDD/TDD Masterclass (https://johnfergusonsmart.com/programs-courses/bdd-tdd-clean-coding/)
Every test tells a story, but some tell a better story than others. Every test illustrates a specific path through the system to achieve a specific goal, but some paths are clearer than others. Valuable tests are the ones that both tell a compelling story, and can stand the test of time, providing value not only as acceptance tests but also as living documentation and easily maintainable regression tests.
In this session, John will invite you to come on a journey of discovery to learn how to write clean, clear and maintainable tests using the Journey Pattern, an innovative new approach to writing automated acceptance tests that are easier to understand, easier to extend and easier to maintain. You will also witness a demonstration of these principles in action, with live coding of Serenity BDD automated tests.
Learn how to plan, prioritise and deliver higher value features by thinking of deliverable features not in terms of what they cost, but of what they can deliver.
XScale is a set of practices based on BDD that enables a product team to efficiently define, budget and prioritise a roadmap or backlog.
It’s also a way to answer some questions Agile has traditionally avoided:
- How much will a set of features cost?
- How do we trade off different feature sets?
- How do we know a feature is ready to ship?
In this workshop, we outline several key practices and practice using a few of them. The main practices we cover include:
- Feature Points, a way to reconcile budgets with story points
- Backlog Bingo determines the dollar investment and relative return for a set of products and services
- Royal Cod applies Backlog Bingo to prioritize a Breadth-First Roadmap
- Release Refactoring enables product owners to make rational trade-offs between feature-sets.
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.
Every test tells a story, but some tell a better story than others. Every test illustrates a specific path through the system to achieve a specific goal, but some paths are clearer than others. Valuable tests are the ones that tell a compelling story.
Come on a journey of discovery to learn how to write such tests, and witness a demonstration of these principles in action, with live coding of Serenity BDD automated tests.
Behaviour-Driven Development (BDD) is a game changer for the whole team! Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
19. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
20. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
21. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
22. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
23. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
24. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
25. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
26. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
27. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
28. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
29. @wakaleo#bddinactionuk
The business owner
tells the business
analyst what he wants
1
2
The business
analyst writes a
requirements
document
3
The developer
translates the
requirements
into software
4 The tester
translates the
requirements
into test cases 5 The technical
writer translates
the software
into functional
and technical
documentation
A traditional development process
BDD in a nutshell
30. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
31. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
32. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
33. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
34. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
35. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
36. @wakaleo#bddinactionuk
The business owner
and the business
analyst have a
conversation about
what he needs.
1
2
3
4 The tester uses
these scenarios
as the basis for
her tests
5
The automated tests provide
feedback on progress and help
document the application
The business analyst,
the developer and the
tester elaborate the
requirements together.
The scenarios guide the
developer and act as
automated tests
They define
requirements as
structured, English-
language format
"scenarios"
A BDD development process
•Specifica8ons
are
elaborated
collabora8vely
•Specifica8ons
use
a
common
language
•Executable
specifica8ons
provide
fast
feedback
38. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
39. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Solves the wrong
problem well
Solves the right
problem poorly
40. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Solves the wrong
problem well
Solves the right
problem poorly
41. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
42. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Hard to
maintain
Slow to
change
Solves the wrong
problem well
Solves the right
problem poorly
43. @wakaleo#bddinactionuk
Building software that matters
Building the
thing right
Building the
right thing
What
How
Misaligned
requirements
Poor craftsmanship
Buggy
and useless
Hard to
maintain
Slow to
change
Does what the business needs
Reliable
Easy to maintain
Solves the wrong
problem well
Solves the right
problem poorly
46. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
We
start
with
a
business
goal
“Increase
*cket
sales
by
5%
over
the
next
year
by
encouraging
travelers
to
fly
with
Flying
High
rather
than
with
a
rival
company.”
48. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
49. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
Earn
Frequent
Flyer
points
from
purchases
50. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal
What
features
will
enable
us
to
deliver
this
goal?
FeaturesFeaturesFeatures
Earn
Frequent
Flyer
points
from
flights
Earn
Frequent
Flyer
points
from
purchases
View
Frequent
Flyer
account
balance
online
51. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
52. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
53. @wakaleo#bddinactionuk
Building software that matters
Business
Goal
Business
Goal
Business
Goal FeaturesFeaturesFeatures
We
use
conversa8ons
around
examples
to
build
up
our
understanding
of
these
features
FeaturesFeaturesExamples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
54. @wakaleo#bddinactionuk
Increase ticket sales
revenue by 5%
Frequent Flyer
members
Call centre staff
Buy more tickets
Encourage
friends to join
Spend less time
on phone sales
Purchase flights with
redeemed miles
Purchase other goods
with redeemed miles
Facebook and Twitter
integration
Online sales
Why Who How What
Building software that matters
Techniques
like
Impact
Mapping
can
help
us
discuss
what
features
are
worth
building
56. @wakaleo#bddinactionuk
BDD - you don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
57. @wakaleo#bddinactionuk
BDD - you don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
58. @wakaleo#bddinactionuk
BDD - you don’t know what you don’t know
Understanding of
what needs to be
delivered
Time
Requirements
phase done
Analysis
Phase done
•Our
ignorance
decreases
over
8me
•It
does
not
decrease
at
a
linear
rate
•It
does
not
always
decrease
in
a
predictable
way
60. @wakaleo#bddinactionuk
BDD - building a shared understanding
“Having
the
conversa/on
is
more
important
than
recording
the
conversa/on
is
more
important
than
automa/ng
the
conversa/on”
-‐
Liz
Keogh
62. @wakaleo#bddinactionuk
BDD - building a shared understanding
Story
bug
reports
Working
code boring
manual
tes*ng
WASTE
BA
Developer
TesterMany
teams
build
features
like
this
69. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Shared
understanding
Story
Examples
Automated
acceptance
criteria
70. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Working
code
and
Working
Automated
Acceptance
Tests
Shared
understanding
Story
Examples
Automated
acceptance
criteria
71. @wakaleo#bddinactionuk
BDD - building a shared understanding
A
liKle
collabora8on
goes
a
long
way
Working
code
and
Working
Automated
Acceptance
Tests
Exploratory
tes*ng,
usability
tes*ng...
Shared
understanding
Story
Examples
Automated
acceptance
criteria
72. @wakaleo#bddinactionuk
BDD - building a shared understanding
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
73. @wakaleo#bddinactionuk
BDD - building a shared understanding
BA
and/or
product
owner
Tester Developer Automatable
Acceptance
Criteria
Shared
understanding
“The
Three
Amigos”
83. @wakaleo#bddinactionuk
Discovering requirements through examples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
“If
I
ask
for
the
details
about
the
flight
FH-‐102,
I
should
see
that
it
is
a
Sydney
to
Hong
Kong
flight
that
leaves
at
11:55pm
”
84. @wakaleo#bddinactionuk
Discovering requirements through examples
“A
new
Frequent
Flyer
member
starts
off
with
Bronze
status”
“If
she
earns
300
points,
she
becomes
a
Silver
Frequent
Flyer
member”
“If
I
ask
for
the
details
about
the
flight
FH-‐102,
I
should
see
that
it
is
a
Sydney
to
Hong
Kong
flight
that
leaves
at
11:55pm
”
•Explore
requirements
•Discover
what
we
don’t
know
•Clarify
ambigui8es
•Iden8fy
assump8ons
and
misunderstandings
107. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
A
star*ng
point
for
manual
tests
Illustrates
delivered
features
Func*onal
and
technical
documenta*on
Progress
repor*ng
130. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
do
we
plan
to
deliver?
What
has
been
done? What
is
in
progress
What
hasn’t
been
started
yet
131. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
do
we
plan
to
deliver?
What
has
been
done? What
is
in
progress
What
hasn’t
been
started
yet
How
many
automated
and
manual
tests
were
performed
134. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
stories
are
defined
for
this
feature?
How
many
stories
have
automated
acceptance
criteria?
135. @wakaleo#bddinactionuk
Living Documentation - completing the cycle
Feature
Coverage
tells
us…
What
stories
are
defined
for
this
feature?
How
many
stories
have
automated
acceptance
criteria?
What
acceptance
criteria
have
been
automated?