#148 - Behavior-Driven Development (BDD) Essentials - Jan Molak & John Ferguson Smart

Techly Journal has a mission to elevate the technical leadership and excellence of all engineers in collaboration with the one and only Patrick KWA. I am excited to share that I'm organizing 2 workshops in Singapore in early November 2023, The Technical Leadership Master Class and the Engineering Manager Essentials. You can find more information at techly journal dot def slash courses slash TL and Techly journal dot deaf slash courses EM register early while the

early but discount is available. See you there. BDD is not about using UI automation tools to verify a fully assembled system. It's about helping you collaborate with different parties involved in software delivery to understand what's actually required of your system, why you need to deliver it, and then to help you find the best possible way to automate your requirements.

Either As to the UI, fine, but typically you'll have other, better ways to do it. Hey everyone, my name is Henry Surya Virawan and you're listening to the Technical Journal Podcast, the show where I'll be bringing you, the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your

personal work. So let's dive into our journal. Hello again to all of you, my listeners. Welcome back to the Techly Journal Podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If this is your first time listening, please subscribe on your favorite podcast app. You can also subscribe to Techly Journal contents on various social media, on LinkedIn, Twitter and Instagram.

And for video contents subscribe on YouTube and TikTok. And if you have been enjoying Technijunal, please support my work by either buying me a coffee at technijunal dot deaf slash tip or becoming a patron at technijunal dot deaf slash patron. My guests for today's episode are Jan Moloch and John Ferguson Smart. They are the co-authors of BDD in Action second edition. In this episode we discussed Indepth Behavior Driven development of BDD and its essentials.

Jan and John first began by introducing what BDD is, the benefits of using BDD and the Gherkin language with its Given, When Then syntax. They gave advice on how to introduce and apply BDD, especially for legacy software and how to manage the BDD specifications effectively.

Jan and John then shared several BDD techniques such as feature mapping, example mapping, impact mapping and went deep into the Screenplay pattern and the Serenity projects they both create to implement the screenplay pattern. Towards the end, Jan and John shared the insights on which testing layers we should apply BDD and some anti patterns we

should avoid. I hope you enjoy listening to this episode and learn a lot about BDD and good practices for managing user requirements and automated testing. And if you know someone who will also benefit from this episode, please help. Share it with your colleagues, your friends and your communities and leave a 5 star rating and review on Apple Podcasts and Spotify. It will help me a lot in getting more people discover and listen to this podcast and I really appreciate it.

Let's go to my conversation with Jan and John after quick words from our sponsor. Are you looking for a new cool swag? Technically, Juno now offers you some swags that you can purchase online. These swags are printed on demand based on your preference and will be delivered safely to you all over the world. Where shipping is available, check out all the cool swags available by visiting Techlyjuno dot dev shop. And don't forget to brag yourself once you receive any of

those swags. Hello everyone, Welcome back to another exciting new episode of the Techlyjuno Podcast. Today I have with me two guests in one time, right? So they are the co-authors of a book titled BDD in Action. So if you are into software testing and if you have heard about Behavior Driven development today, we will be discussing a lot about it. And this BDD in Action is actually a second edition in extension to the 1st edition which was published I think sometimes in 2014.

So John Smart was the first author of the book, and then in the second edition he collaborated with Jan Moloch here. To come up with the 2nd edition. So really looking forward to this conversation and learn a lot about BDD and software testing in general. So thanks for being here guys. It's a pleasure. Thank you for inviting. Thank you for having us. So Yan and John, I always like to ask my guests to introduce themselves a little bit, maybe telling about career highlights

or any turning points. So maybe I'll leave it to either one of you to start first. Well, I can go first. So I'm John Ferguson, Smart. I've been in software development for more years than I can remember since the 90s. So I've been doing Agile software development since the late 90s, early 2000. I've done a bit of everything, so development. I still do active development, testing, project management, waterfall, agile, XP, the whole

whole range of things. In the 2000s, my role was very technical and I always thought the requirements side of things was a little bit intimidating. All this talking to people and stuff as well. That was a little bit of a challenge. So I gave myself the challenge of actually getting into that and doing that a little bit more. And that's where a lot of my activity in the sort of BDD space emerged.

I started to get involved with people in these sort of Agile and BDD communities in London. Quite a bit, The Dan N, Liz Keo, people like that who were very active. Chris Matts was another one, very active in that area. And so that's where my big interest in behavior driven

development really came from. But if you're talking about highlights, actually one of the interesting highlights was I've actually been doing BDD for well over 20 years because one, there was this one time I was working with an insurance company in Paris, France. And their problem was they wanted to put an insurance application online, and their problem was reproducing their mainframe insurance algorithm in Java. And they had like a gazillion

lots of rules that are all done in this really complicated Excel spreadsheet. So I had the idea of taking that Excel spreadsheet and actually saying, well, give me all the examples that you use to test your Excel spreadsheet and we use that to test the actual code we write. And that was effectively, we just read it through J units and produced a little report. And there was actually another Excel spreadsheet, somewheres were green, somewheres were red.

And that was the first executable specification with collaboration with the business that they ever wrote. And I thought that was such a wonderful technique that works really, really well. I've been trying to do it ever since because I really do think it is by far the most effective way of so collaborating and delivering software that makes a difference that I've experienced. Wow, that must be a very tremendous effort. So I really congratulate you to have a success for that project.

How about you, young? Oh, so my career journey actually didn't start in finance or banking, where I work right now. It started in a complete opposite of the spectrum. So it started in early 2000 in the video games industry when I was back in Poland. So I remember one of my first jobs I was actually working for CD Project Thread, the studio behind the games like The

Witcher for example. I was the very first full time web developer there and my job spec had one sentence and said, well sort out everything around the Internet. So, well, that's quite broad. Well, I asked my boss, well what exactly do you need? And he told me, well, what do you think we need? So I said, well, we would probably need a place for people to exchange comments about the game. We need to have a place to

publish the news about the game. I said all those things and he was like, well that's awesome, let's do it. How can I help you so? Remember that that's my first job. I was like, you know, in my early 20s I had absolutely no idea what I was doing. But what it really helped me to do is to actually have this business perspective on software. So how can I create software, how can I work with my team to create software to support a then small company.

So I've been used now the things I learned back there and try to apply it to other industries. Now, later on, I moved from Poland to the United Kingdom. And there was similar to John. That's where I met many people who are no practitioners of Extreme Programming, of Test Driven Development of BDD and so on. And one of the problems I was trying to solve, I was trying to find the ancestor was how do we ultimate testing? Now I'm not sure.

If the audience knows about it. But one of the main problems in one of the many challenges in video games development is how do we actually test the games? If you have a like a real time simulation, because that's really what a video game is, how do you make sure it works? So I tried to find answers to that, and typically the answer I would get as well. It's not possible. That was just too hard. And whenever I hear it's not possible, it's not too hard.

The first thing I do is I try to figure out why it's not possible. Then the second thing I do is try to figure out how to do it. So I tried to answer this question now across different industries. So I worked in publishing, I worked in media. I worked in broadcasting, I worked in finance. And the one thing I actually realized is that whatever company I joined or whatever client I worked with is very often here that the testing is impossible. It's very hard to do well. Why is that?

So many of those companies, what they would do is they would hire manual testers to click through the scenarios and basically confirm whatever developers have already created. Now what I realized is that, you know, testing is difficult because it's actually very hard to understand what is that we actually trying to test. Why try to test how to set the priorities, how to understand what parts of the system are

actually important? And turn out is that just in video games there was the same case in financing insurance, in banking, in broadcasting, every was the same case. So then I started looking at two ways actually. Well, first automate my tests, then figure out how to gather the requirements. Actually, how to understand what bit are important. And that's how I came across Jones work around behavior development.

That's how I got to meet guys like the North and Lee Skio and the rest of the London BDD and TTD crowd. So that's how I actually got to connect all those different dots. And actually, if you got in order to avoid issues with manual testing, in order to automate testing, well, you actually need to understand what is that you're trying to test, why you're trying to test it now. To do that, you need to

understand your requirements. To understand your requirements, you need to speak with the business stakeholders, you need to speak with your customers, you need to have ways to actually gather and analyze feedback in very fast and efficient ways. So that's how all those different pieces of my career journey came together here in London. Thanks for sharing your story.

I think throughout both of your career journey and highlights, I can tell that you guys deal a lot with software requirements and testing, right? And the challenges how BDD later on can help in terms of doing software testing and also gathering requirements. So let's just go straight into BDD, right? So in the 1st place, maybe if you can summarize what were the challenges before BDD was around right? What were the challenges that probably was prominent in the software development world?

So from my perspective. BDD, I've heard it described by one of the managers I've worked with us. It's what makes you actually be agile, not just do agile. And so BDD and Agile are very closely related. That is all about solving that same problem. It all comes down to the communication. So we can code all we want, but coding is not really the aim of the game. The aim of the game is to deliver solutions that actually. Solve problems that the business have. Enable them to do something that

they couldn't do previously. Enable them to do something that they could do previously but better. Prevent problems. Save money. Or where. There are the four categories that we know about how you can actually deliver value. Chris Matt's 4 categories, if I recall correctly, how you can actually deliver value and all of that. The problem is it comes from understanding the requirements. And what we've always found is that.

You can't just write down the requirements, or have someone write down the requirements for you and expect to get value out of them. There's always iterations, there's always feedback cycles, and the aim of the game is to actually reduce those feedback cycles. And the waste that comes from that. And before, well before the days are sort of BVD, you would inevitably have really long cycles where.

You'd have siloed processes. And even in allegedly agile projects, you still get that siloed processes of BA's or analysts or product owners right? Requirements hand them off to the development team to build, they build something, they hand that off to testers to test, and then they the testers. Or maybe they even also have a UAT testing phase where users go through and test things in their own way. And that's always a bit of a surprise because they never told you what they were going to

actually test all of that. Every stage gives you the opportunity to lose information, to make mistakes. And so that's what the biggest challenges we're having before BDD is getting that communication allied. Yeah, I think that's quite a funny thing because now typically when we think about software development, we focus on things like the languages we use, the frameworks we use, or the automation tools we use. But.

We kind of forget about the most important bit, which is the social aspect of creating software. So PDD is one of those tools, Behavior Driven Development. It's one of those tools that helps you to focus on the actual outcome that your software or your solution is supposed to bring to the organization. Now, the interesting thing about it is that bringing the outcome doesn't necessarily need to

require software. So that's again one of the things that software developers very often forget about. If you think about it, I'm a software developer before I have to build software in order to exist, right? And that's my job. That's my role in the system. With BDD, what we can do is we can look at the outcomes that our organization seeks to achieve and then perhaps we could try and find solutions that don't require us to build

any software. Perhaps we can bring the same outcome by improving the process, by speaking to another person, by reusing the tools we already have. Now, if we can accomplish the same outcome without building additional software, well, then we won't have any additional software to maintain and therefore we can further reduce the costs. Thanks for the addition to that important bit, right. So we don't always have to need software to bring an outcome for the business or the

organization. It could come in many different shapes and forms, right? It could be process improvements, maybe some kind of prototypes, maybe some kind of a cheaper solution than writing software. So let's go to probably the definition of BDD, right? So for people who are new to BDD, I also heard people sometimes mistaken BDD with just the Gherkin, right? The Given when then. Some people also refer to ATDD Acceptance Test Driven Development.

Also people are saying a specification by example. There are so many different terms. Maybe if you can help to define first what is BDD and how does it compare with all these different terms that are available out there in the industry. So Behavior Driven Development is a collaboration approach from my perspective. It's not a particular tool set or not a particular. Well, it is a methodology, but it's not related to a particular language or tool set or.

Testing approach. It's definitely not about test automation and it does encompass all of those other aspects nowadays. I mean, it's a concept that's been developed in different ways. Back in the noughties we have fitness, we'd call that a TDD because we'd try and define the acceptance tests first, just like we're doing TDD and we'd try and write them in a business

readable format. Specification by example was Guico and Six. Book which described that same approach, Behavior Driven Development was originally coined by Dan North as a way to explain Test Driven Development. But with the work of Chris Matts and Liz Keo and other people in that community, it fairly rapidly expanded into being applied to analysis. So we often we see BVD extends from TVD, now it does it. BVD is a totally much broader concept now. It's the collaboration.

Process where we involve business, users, developers, testers, everyone to have conversations around the requirements in BDD. One of the concrete things that we use, one of the really characteristic aspects of BDD, is that we use examples a lot. So rather than just writing general specifications, we describe everything in terms of examples. And we use those examples to drill into the details and challenge the assumptions and challenge our mental model of what a requirement actually is

about. So that using examples and counter examples and telling concrete stories is a much better way of getting the team involved and engaged than there's a more traditional requirements writing approaches and even just the classic news stories which can very quickly become just a proxy for requirements. Now the automation aspect. BDD is not about automation. Cucumber is not an automation tool. We'll test automation tool. We're not in the business of

automating test cases. What we're trying to do is define the requirements in a format that can give us fast feedback on whether they've been implemented. Now it turns out that a really effective way of getting that fast feedback is to automate them. So automate the requirements. It's using tools like Cucumber. Now tomorrow, if we get a tool that's better than Cucumber, we can use a different tool. We'll still be doing BVD. It's not related to a particular tool.

So Gherkin is the Given, When Then language that's used in tools like Cucumber and Spectlow and Behave and quite a few others. And it's one of the more common ways of doing BDD. But it's not the only way. We can also do BDD, express our requirements and write them very well just in plain JavaScript or Java or Python.

And if we write our scenarios, our examples in a business readable language, and if we can produce reports that reflect that business readable language, then that's BDD as well.

So I'll tell you that in a nutshell is sort of what BDD is all about and it is a very broad definition, but there is a lot to it. Maybe one thing I would like to add is that what PD helps you with is helping to avoid things like scope creep, so focusing your team on outcomes, so focusing on the conversation around outcomes. So what is that our software system? What is that our solution is supposed to bring to the organization? What does does several

interesting things. So firstly, we talked a lot about our collaboration and conversations and so on what many people might hear. Well, Oh my God, we're just going to have more meetings. No, no, not at all. What we mean is that what we're doing with BDD is we're helping team to start having informed conversations on focused conversations around specific outcomes they were trying to accomplish and it was just not any random chit chat.

So we are trying to focus on the outcomes because focusing on the outcomes helps us find more precise solutions to the problems we're trying to solve. We are not just shipping features for the sake of shipping features, we want to solve a specific problem. Now this focus also helps us to avoid scope creep, as I mentioned earlier. Now the idea here is that you know, if you know that your goal is to, I know, increase the number of conversions on your homepage by what, about 20%? Nobody.

By some time, well then you are trying to focus on delivering those features that help you to accomplish this specific goal. Now this helps you to avoid having to ship any other features that don't support this goal. Now what this focus also gives you is also gives you an opportunity to improve the overall quality of your

software. So again, not only we can turn those requirements, those scalable specifications into automated tests by reducing the scope and focusing only on those things that matter, it's easier for us to ensure the quality of the software we deliver simply because we have less of it to deliver in the 1st place and what we deliver is of higher

value. So again, we're focusing on delivering high value software and making sure that is actually the software itself is of high quality as well, not just sharing more and more features. There are many other interesting outcomes of this approach by again focusing scope, improving quality, improving the value of software we develop and deliver. We also improve things like developer happiness.

Because suddenly now that you have conversations with your business sponsors, you have conversations with your customers, you understand what is that you're trying to solve now, why you're trying to solve it. You actually have a mental image of the person you're actually delivering the solution to. It's much easier to see how your work is worthwhile. It's easier to see why you're

actually trying to do it now. This again improves developer morale, improves developer happiness, increases developer productivity, and so on. So it's actually quite interesting how many positive effects that team can see by doing things like focusing your work on the outcomes that you are supposed to bring to your organization. Thanks for highlighting the important aspects of BDD. I think the first thing I heard very clearly from John is that BDD is not automation only, right?

It's not software testing only. The first is about collaborative approach that focuses a lot on conversations, examples, right and also outcomes like Yan also extended in the later part. So I really love that explanation. So for people who still think BDD is just another tools for automation to make your software testing much better, I think it is more than that which speaks to the next topic that I'd like to ask you guys. What do you think are some of

the benefits? If you can summarize that BDD offers for people to give it a try? If they don't have the time yet to try BDD, why they should consider applying BDD now in their software development

practices? From my perspective, and this is what I see on the ground, it's a good question because you do need to know why you're introducing any technique and what you're going to measure it on and whether it gives you the outcomes, because that will tell you whether you're actually implementing it effectively or not. And there are two levels of outcomes that I see. There's what you might call the proxy outcomes, which are easier to spot, easier to see straight away.

And then there are the longer term outcomes which was what you're really trying to achieve, the sort of proxy or short term outcomes because of the nature of the collaborative nature of BDD and the fact that you really do build up a shared understanding within the team of what you're trying to do, it tends to reduce the number of defects dramatically.

So I see typically, and this is not talking about automation, just the fact that you collaborate effectively reduces a typical defect rate by seventy 8090%. You just. Don't get defects into production a lot of times because you get a much deeper understanding and you've got the opportunity to ask questions and people do ask questions. Now that assumes that you are actually doing the collaboration correctly.

If you're just writing given when, Then statements in your test cases and calling it DVD, you won't get those benefits and you'll wonder why it doesn't work. But if you do the collaboration and then think about how to automate, you will get those benefits. The automation BDD is a really effective way of doing

automation. So I find it when you do it well and combine it with TDD you can do a really nuanced level of automation and get a lot of bang for your buck for the amount of automation effort that you do. So it really helps you get a laser focus on what you should automate, why you should automate, and where you should automate. And so that's a good practical benefit. I find there's also a longer term benefit.

Is that. Because you're having these conversations and this applies, you want to be having conversations not just at the story level, but also at your features and epics and then coming up with examples of user journeys and use cases at the epic level, so you can understand what they're about and where the value is coming from. And that helps you to be more confident in delivering value, that actually delivering things that make a difference to make an impact.

So that's a really important longer term benefit. And the third big benefit that I see and which is a little bit less tangible, but as what a lot of people report to me and what I see in the teams that I work with is that you get the teams which are much more engaged. So team members tend to be much more engaged and creative because they know what they're contributing to and they have a sense of mission and the sense of ownership of the problems they're solving.

Much more so than the traditional siloed approach where often development activity is basically implement this JIRA. Without really understanding the bigger picture, very much so. The teams do get much more engaged and that leads to some better productivity and more creative outcomes. Yeah, I think one of the things that John mentioned, they really deserve to be highlighted even

more. I mean, if you think about it, according to various scientific research done over the last couple of decades, it turns out that between I think 40 to 80% of all software defects actually come down to issues with requirements, issues we've misunderstood or perhaps no

miscommunicated requirements. Now you asked about the benefits, Henry. So if in your audience we have listeners who are on teams that suffer from issues with production defects, issues with defects in their software, if there was one thing for you to improve, think about what can you improve around your requirements, around how your development team collaborates with the business, with testing, if you have one, with OPS teams, and so on.

Think about improving how we collaborate around the requirements, because issues with requirements cause most issues with your software, most probably. So by addressing issues with requirements, you are more likely to improve the quality of your software than by focusing issues with, let's say, coding errors, which are much less frequent than issues with requirements. Well, thanks for the plug. I think I remember this kind of

research as well. And I also know that rework is also something due to the miscommunication or maybe the requirements not captured properly. So I think yeah, if software engineering team wants to improve some parts of their productivity and effectiveness, probably requirements is 1 big area where it will bring a lot of impact. So thank you for explaining some

of these benefits. I really love that John mentioned about this increased engagement from not just engineers, probably it's the whole team, right, because they are so collaborative and trying to come up with a better way of approaching the problem and achieving the target outcomes. So talking about BDD, I think we talked about it earlier just now about Gherkin, right. I think talking about BDD, we have to cover a little bit about Gherkin. So what is this Gherkin? Why the name is so funny?

And. What is the essence of Gherkin anyway? Gherkin is a small cucumber, Pickled cucumber kind of. It's in that family of vegetables. And so there's a relationship between cucumber the tool and Gherkin the language. So Gherkin is the given when then notation that we use. So Dan N was originally at the origin of that where coming up with that notation and then Chris Matt observed that it was a good way of describing business expectations as well.

But a lot of people misinterpret it by a lot of people. They don't know how to use it, basically use it incorrectly. And it's what happens when we see test groups written in this given, when then format given when. That format that can be crystal clear, can be a really nice, precise, readable way of writing your requirements, or it can be a horrible mess. It's like anything it can be depending on whether it's well written or not. So well written it will have value or not.

So there is quite a skill to writing a clean, effective, concise, given when then statement that really reflects a business rule and really reflects a business requirements. And so it does take some practice and some effort to get that right to start with. But when you do, what happens is you end up with this, what we call a domain specific language, which is really the heart of the collaboration for a team around a set of requirements. And that's where I've had projects.

Where we've defined this sort of domain specific language for a particular part of a project and it's allowed business to write their business rules and express their business rules with such clarity that there's no other automation that needs to be done. They just need to express a new business rule using their existing language and everyone will understand what it needs to do or what needs to be done. That doesn't happen in all projects or in all cases and

with all situations. But when you aim to do that, you can come up with that language and use it as a really central part of your requirements definition process. If you just use it for test scripting, it's much less valuable because a test script was given When then. Generally people will mix up the Given When Then and it won't make any sense. It'll be hard to read, and also when people write test scripts with them, they tend to be much

more granular. Much more focused on clicking on buttons or clicking on the fields, and that becomes brittle and hard to maintain. And so people say Gherkin's no good because it creates test scripts that are hard to maintain. Absolutely it does. But if you use it to write executable specifications in the business language, it can be extremely effective. Absolutely. I think one of the main things that's character language is supposed to help you accomplish.

What aims to help you accomplish is a separation of preconditions, actions, and outcomes. So given when then it's actually very similar to what you see in well written unit tests with the separation of three parts. So Arrange, Act, Assert. Now we're doing something very similar, but with the focus on business requirements. Now the reason why we're expecting this in a human readable language is so that now we can create an opportunity to avoid some implementation specific details.

So again, we can focus on the business language. We can focus on introducing this business domain language into our executable specifications. Now an interesting thing about Cucumber and Gherkin that you know many especially English native speakers forget about is that what's Cucumber and Gherkin allow you to do is they allow you to express those in scalable specifications in a language other than English. Now Cucumber, the last time I checked is supported over 70

different languages. So what you can do now as a team, If your business sponsor or your audience speaks language other than English, or they're more comfortable with other language other than English, then you can express your specification in Spanish, French, Arabic or whatever other language you prefer. And then Cucumber under the hood will translate those statements in the human readable language

to your actual automation calls. Now it's going to be very, very useful again as a tool to improve collaboration with different audiences of your automated specifications. I wasn't aware that many languages are supported, so thanks for adding that. So I think that's really interesting. Yeah, even Pirates speak from what I remember. So those are. And also, I just knew from John what Gerkin means, right?

It's a small cucumber. So I think I learned these two things really well today from you guys. So talking about BDD, right, I think in order to introduce that, I think it's not just a simple switch, right?

People need to learn and people need to understand how should the flow be. And I think I believe many teams these days practice Agile software development methodology, whether good or bad, it's a separate discussion, but I think in your book you outline several steps that people can try in order to incorporate BDD in their software development flow. Maybe if you can give us a highlight, an outline. How should people introduce BDD seamlessly in their software development methodology?

So we work with teams, John and myself, that's what we do. We work with teams to introduce BDD into the. So we've got a fair bit of experience with what works and what doesn't. And what we've always found is that you need to start with the requirements part. You need to start with the conversation. The automation comes later. You've got to start with the conversation. So you've got to get people communicating and collaborating and having those conversations.

And it might feel like, yeah, I was saying earlier, it might feel like you're spending more time in meetings. But actually what you get out of those meetings is multiplied many times by the time you save actually delivering the code that you meant, building and delivering the code and the features that add the value. So the first step is to understand what the BDD process is.

Understand that it's about conversations and collaboration and then automation and start structuring that those making time, carving out a time in your existing process to have those conversations. You don't want to leave it at Hock and you don't want to leave it to sort of just random conversations. So the second thing is that BDD proposes a number of practices, like example mapping, feature

mapping, a whole lot of others. But they're structured practices which designed to help teams get the most out of those conversations. And they are very intended. A whole lot of psychology that goes into a lot of the things we suggest in BDD. But those techniques are really important, especially when we have teams where some people might be more vocal, some people might be more reflective and like to take time to get their answers.

When we can use collaboration tools, when we use tools like mural and figma and mural and whatnot for online collaboration, we can get the same effect. We can use a structured approach to coming up with those examples and then turning them into an executable format. The third step we introduce is. The actual automation side of things. So how do we find an automation approach that will work for the technologies that the team's

using? And that obviously varies and I'm very reluctant to say to a particular team you must use this automation tool. I'd rather the team own the automation technology and then we basically what we do is we'll guide them and to choose. How they can actually implement and I mean, we have our preferences, but I've worked with teams who work with APL. I remember one team was working on and also it's really obscure stuff. So not everyone is using Java or JavaScript.

So Java, JavaScript and Python, they're the big ones that people are using these days. And with them, Cucumber does provide some nice options. But there are lots of options out there and you want something that the teams embrace and adopt themselves. And then the final stage is actually getting the teams doing the automation themselves. So automation is not just about the test or automating test cases. It's about we want an outside in approach. So we're as far much as

possible. You don't automate after the fact, you automate before you actually start the work. And that's what I was saying earlier on. The ultimate end goal of that is that you don't need to automate at all, that you express the requirements in your domain language. And the automation is already done for you. So that's sort of the ultimate in ATDD. So they're typically the stages that we go through that we see when we help teams introduce

BDD. Yeah, absolutely. I think the collaboration aspect is again one of the most important ones here. So like you mentioned earlier, John, so one of the things that the teams very often try and do when introducing BDD is to focus on the tool. I mean, it's an actual inclination of any software engineer. We focus on the tool first, so we think, Okay. Well, I like BDD. I like all the things it promises. I'll just use Cucumber to write some automated scripts after

I've already done development. Well, that's kind of pointless, right? What do you mean? The development has already happened? The collaboration has already hopefully happened. So now it's way too late to actually write any automated tests. Now what we do, this workshop that John mentioned earlier is one of the core practices of Behavior Driven Development is a Three Amigos workshop.

Now the idea of the Three Amigos workshop is to have people representing different perspective involved in software delivery. So the business perspective to the development perspective and the verification perspective. Someone to actually describe the word and why it's needed for the organization, someone to figure out how we actually ship it, and someone to critique the idea to find the house, find the things that might possibly not work so that we can actually guard

against them. So that's one of the critical workshop that we typically introduce. Now, another thing that you need to do this workshop is you need to make sure that the people who actually can add value to those workshops are involved. So what a team would need to do is to identify the dependencies not only in terms of software, but again in terms of other teams.

So for example, if I need to accomplish a certain goal that requires me to work with my Dbas or application security teams or QA teams or whatever other teams I have in my organization, I would try to establish those communication links first. So again, we typically focus or we recommend teams to focus on establishing those communication links because this then leads to you understanding the requirements, but it doesn't help you automate those requirements.

But then this helps you to deliver better quality software. Right. I like the emphasis that you put that we should not start with the automation first, right? Like picking the tools do the automation, but actually the development is done and maybe the story was already defined. So I think, again, the emphasis is on the collaborative aspect. What about if the teams already have a software in place? There's a legacy code. There's a legacy requirements.

Maybe it written somewhere, maybe it doesn't get written somewhere. Maybe it's in people's head. Is there a way that you would advise people to incorporate BDD into, you know, like legacy software? Generally speaking, there are two approaches. Either you only do it for incrementally for new features, or you backfit executable specifications for your entire

application. I don't generally recommend the second approach, but I have had teams who are really insistent on wanting to do that approach because they wanted the value of the living documentation. And they knew the legacy application was mission critical and they had no understanding of what it actually did. So they were in the case. Particular case I'm thinking, which was a company in Sydney who did this and it worked really well, is that they used

the BDD approach to retrofit. Executable specifications for their existing functionality. And that was a way of them understanding what the application did and documenting what the application did. And that allowed them to progress faster afterwards. But in most cases, what I find is a path of lesser resistance is to apply it incrementally and progressively. So you come with a new feature. Your new feature is at a column to a particular search result.

You're not going to write a whole lot of BDD scenarios for everything around it. You're going to write a BDD scenario for that particular use case and use a journey. So your use case might be well, a admin will add a product to a catalog with a range of colors, and the search screen should show those colors in the search results. And so you might have a some scenarios around that, and that

will be your BDD scenarios. You won't explore every possible way the admin can add products to the catalog or every possible way you can search. But as you add new features, you'll expand on what you've done and gradually you'll create these little islands of executable specifications which will eventually come together and form a bigger picture.

And that is a more pragmatic approach when you've got an existing application and you don't want to burden the team too much with having to do too much automation at the start. Now that said, I do know teams who use that approach, but simultaneously they have a tech debt approach where they recognize that there is a technical debt related to the lack of automation, lack of executable specifications.

So each Sprint they'll do a little bit of work to chip away at that and add a little bit more than they need to, so that they can gradually build up their executable specifications more quickly. Now, one of the things that could be helpful to teams that actually need to support existing software while introducing new features is something we described in the book as well, and that's a technique called journey mapping.

Journey mapping is a BDD technique that we've developed when working with teams who work on established software systems. If you think about it, this is a very common case, especially in finance, insurance, healthcare. Where you know you very rarely have the luxury of starting with a Greenfield project. You typically have something you have to maintain.

You need to add to that now techniques like journey mapping, what they allow you to do is they allow you to focus collaboration with other parts of your organization around the important aspects of the system that your systems to support.

So it allows you to focus on the specific actors or the specific external parties, your systems to support their main use cases, the main scenarios and so on. So with this collaboration technique helps you to do this, helps you to prioritize any of your refactoring or re architecting work better. Because now that you understand what the system is supposed to do, you understand what the important parts are. You understand what parts need to keep working whenever you add

new software or new features. Then you can make sure first your manual testing or exploratory testing activities around those important aspects. Then you can start creating your automation with the focus on the important aspects of the system. Because now any existing system will have functionalities that are used on a daily basis frequently, but most of the users and we have some features that have been added by two decades ago for whatever reason that nobody remembers.

So it's important to be able to distinguish between those two. Right, so start small, start gradually, right? It's not like one Big Bang approach. You can have all the requirements captured in one goal, right? Absolutely start small and build right. So both of you mentioned things like features, scenarios, steps. I think. Let's go a little bit more into the techniques, right? For teams who implement BDD, how should they structure all these different given, when then different scenarios?

Is it common to put it in their user stories or is there a better way of structuring and managing those requirements? Generally speaking, some teams will put the Given, When Then statements directly in JIRA, some teams will put it in version control. We used to.

Well, it was very common a while back to actually come up with the Given When Then statements directly in Three Amigos, then automate them later on. But we've found that that's a rather inefficient process because it takes a lot of people a lot of time to words with those given when then scenarios, whereas what you're really after is getting the key examples and counter examples. And so the given When then really should be what we call an executable specification.

And if it's executable, it's part of the source code, so it should be actually in the source code. Now the problem that happens is product owners and business analysts, they want visibility on those given when then. So there are tools around Jira plugins for example, that allow you to give you visibility on those given, when Then statements that you've got in your source code.

Even edit them some of them so that you can get that visibility from Jira in your user stories, but without compromising the fact that the Given When ends are effectively source code and they need to be in a place where they can be executed. What is an anti pattern and I find is that when product owners right the Given, when, Then statements directly in the user stories before they have the conversations because that cut short the whole conversation part of BVD.

That introduces a whole lot of cognitive biases and actually makes the conversations a lot less efficient. And also they're really hard to automate generally. So that is generally speaking, there's maybe one team in 10, one team in 20 who can pull that off that I've seen. But generally speaking we don't advise that.

We advise having the conversations first, writing lightweight acceptance criteria first, having the conversations and then putting the Given When, then inversions from, then figuring out how to get that visibility in JIRA or whatever tool you're using. Plus, I think a very important distinction to make is between features and user stories. I remember for me to say very important switch in how I was thinking about software delivery as a whole. Features is what your software provides.

It's what the things that people can use. User stories is how you deliver those features, how you structure your software delivery process, in what sequence do you deliver different pieces of functionality. So what typically happens with those feature files? If your team uses Cucumber, or with your test specification classes, if you're using JUnit or Aspect or whatever.

What typically happens is as you deliver new user stories, you will be expanding your feature, the executable specifications of your feature, with every new user story you deliver. Sometimes you'll be adding additional scenarios, sometimes you'll be changing the existing scenarios. Sometimes you'll be removing scenarios when you see certain aspects of a feature. Don't gain as much traction as

you were hoping it's to gain. So again, every user story your team delivers, you're basically affecting the current shape of the feature your system has. Well I think I get a lot of explanation and clarity on how teams should manage their given when then right? I see some teams actually just write it in the stories and then it gets lost once the story is done. Maybe few sprints before right? And the teams also couldn't figure out how to collect back

all these given when then. So I think all these explanations make sense. Both of you have mentioned a few techniques in addition to making BDD work more effectively, right? Things like journey mapping, I think impact mapping, private campuses, and all of these are also mentioned in the book. Maybe if you can highlight one or two of your favorites techniques that we can also explore in order to make our BDD implementation much more effective. Yeah, sure thing.

So maybe we could start with the screenplay pattern. So the pattern itself caused a bit of a stir when we first talked about it in the test automation community and the ability community in general. So what is screenplay pattern? So screenplay pattern is quite an innovative user centered approach to writing high quality automated acceptance tests.

And what it does It tears you towards an effective use of layers of obstruction and helps your test scenarios capture the business vernacular of your domain. It also encourages good testing and software engineering habits on your team. Now, how does it do it? You see, typically when we do automated testing, when we write automated tests, we express those tests from the perspective of an integration tool interacting. With our system. So in the UI testing you would

write a test as a web driver. So go to a page, click on a button, enter a value into a field and so on. When we do API testing, we express it from the point of view really of an HTTP client. So I send the request, I get the response, I verify a status code. But what we typically miss in those scenarios is we completely miss the business vocabulary. We miss the business reason behind those scenarios. We completely failed to capture all this information in our test script.

So with the screenplay pattern, what we do is we flip this whole thing on its head. Instead of expressing the automated tests from the perspective of a low level tool, we look at them as a way to express all the different tasks that an external user of our system or of our interface would perform in order to accomplish their goal.

So rather than talking about a Webdriver or playwright or Cypress clicking on button and entering values into fields or talking about rest assured we identify actors. So those could be either people or external systems interacting with our system. What we do next is we capture the specific goals and tasks they need to perform in order to

accomplish their goals. So for example, we might focus our scenario on a person or a persona of a shopper that goes to an e-commerce website, tries to find a product added to the basket, make sure that the tax is calculated correctly, and so on. So what we do this pattern is we actually capture the business vocabulary, we capture the business intent behind given piece of functionality and we use high quality code to express those things and capture them in

a form of an executable specification. So the main thing in a user centered model is a model representing a user or an external system interacting with our system. Now the interesting thing about the pattern itself is that it's actually, it might sound like something really complicated, but in fact it really isn't. It's made out of five main building. So we have actors. Actors are the first building block of the screenplay pattern. Now I already talked about the

tasks. So tasks are basically a way to express those different things that an actor would do in order to accomplish their goal. They're basically aggregates of lower level SAP tasks or interactions with the system. So we have actors and we have tasks. Those tasks are typically made-up of interactions. Now interactions are the lower level actions that the actor would perform in order to interact with the system, hence

the name. So we have actors who perform tasks and those tasks are made-up of other tasks and interactions. Now how do those actors perform the tasks? So the interesting thing about the screenplay pattern is that we try to encapsulate all the lower level API calls to our. API clients. So you wouldn't see any web driver or playwright or Cypress calls in your tests. All those would be encapsulated

in another class. So those class are called Abilities, and abilities are basically thin wrappers around those integration libraries. So we have actors who perform tasks. Tasks are made-up of other subtasks and interactions, and what enables those interactions are abilities and abilities. Again, just the thin wrappers around your integration library. So those are the four elements. Now the fifth one are questions now similar to the CQRS model for designing system architecture.

In the script play, we also separate the interactions that the actor would perform from the information that would get out of the system and the test. So an equivalent of a command from your CQRS model are the interactions in screenplay equivalent. Of a request in the screenplay button. Questions.

So questions are a way to retrieve information from the system, and questions could be things like get me that text from that element on the screen, or get me the last response body that you received from the API requests, or get me the position of this button in my mobile app. So again, you've got those five building blocks, so actors, tasks, interactions, abilities, and questions. And out of those five building

blocks, you can. Develop pretty much any type of automated tests you might dream of, really. So we've used it for UI testing, for mobile testing, for API testing, for performance testing, for visual regression testing. You can do all sorts of things by expressing your test scenarios using those five building blocks, and also gives you a very nice way to introduce code reusability patterns into your code base as well. Thank you so much for such elaborate explanation about

screenplay pattern. I personally is the first time for me to learn about this. I think the abstraction makes sense, the five things that you mentioned. Maybe if I can ask a little bit further why was it causing a lot of stir in the testing community? And then secondly, if I'm not mistaken, not just coming up with this pattern right, you also contribute an open source project called Serenity. Maybe if you can also give a high level about this serenity library.

So I can chip in on this side of things because I've seen a lot of conversation on the line when we first proposed or came out with it started talking about screenplay. A lot of people still think in terms of UI as a test automation approach. So a lot of people are very anchored on UI testing being the default way to test an application and sort of goes back to the.

Very first implementations of test automation where it was tools like Mercury and whatever it's called these days, and where it was just record replay tools were so very clunky. Basic Scripting. Literally Visual Basic Scripting style scripting and tended to be. Very ugly and unmaintainable from when you come in from this perspective of an software engineering and you look trying to make your code maintainable, you try to make it

understandable. You try to write code that when you come back to it next week and you have to maintain it, will change it. You can understand what it's doing. I mean I have to be careful with my own code because I I won't understand what I did this afternoon. I'm not careful. So looking at code later on, it's really important to make sure that your code captures the intent.

And the traditional way that people tend to do these, even one of the big things that people try to do is use the page objects approach. The problem is most people that we see, or I'd say most code that we see implementing the page object approach becomes very heavyweight and convoluted and complicated and hard to understand and hard to maintain. So you have page objects that try and represent an entire web

page, which the name might. Indicate and that'll be 1000 lines long and have a gazillion selectors and then a whole lot of logic and assertions inside it. And do a whole lot of different stuff. And that means that if a test changes for reason A and then the test also needs to change for reason BA different test, they'll both affect the same page object and you get churn and instability. And you might have an implementation for one test. And start in a particular way.

Then for another test you need to do something else and so it can create code that's historically very hard to maintain. And so basically the screenplay approach really is a way of what happens when you apply OO and functional programming principles. Just clean coding principles to the problem of test automation. And also you start to step away from the screen, step away from the UI and think about. Hey, what is the business actually trying to do here? What is the task?

And so I was talking to a team recently and using an approach that recommended a while back. Basically having a very clean separation of the description of your tests, the description of what the business is trying to do, what the user is trying to do and how you implement that. And so they had cucumber scenarios where it was things like.

Given I want to purchase some books, when I add these books to the shopping cart, then the tax should be calculated correctly and then under the hood they had three different implementations of that that they could hook in based on different tags and blue code or whatnot. One implementation was through the UI, another implementation was through the API, another implementation was just with their pure domain logic, so

effectively unit tests. And those 3 implementations were all driven by the same Cucumber scenarios and that under the hood it was using actors but different tasks for those actors. And so I think the domain model was just a few unit tests, but the integration, the API calls and the UI calls, the code read very similar, It was an actor attempts to add these items to the shopping cart. Except there are two slight variations. One was going through the UI1 was going through the API.

And the cucumber layer never changed. It was the same for both implementations under the hood and the step definitions. The code was very similar, slightly different because it uses different tasks, but very relatable. You can read it and understand what I was doing. The only real difference was in the implementation of those tasks. Now that sort of approach would be impossible to do. If you start off with the mindset of I'm going to use Page Objects, you can only have that, sort of.

Level of abstraction. When you think in terms of, I'm going to model how my user interacts with the system in business language. Then I'm going to decide what the best way to implement that is. What task do I need, does the business the user need to do? And then how will those tasks actually be performed? And the screenplay is not the only way of doing that, but it is a very elegant way of doing that. Wow, it sounds really powerful. So I think having a unified

cucumber feature test. And you can have a different implementation details, so to speak, right. I think that's really powerful. So yeah, going to the Serenity part, right. So maybe if one of you can also share what kind of cool project that you're doing with this Serenity library. I can take the JavaScript part, so I'm the maintainer of Serenity JS project. So in terms of screenplay, just to maybe build on what John's

already said. But I think what's really, really important about screenplay is that. It helps you focus on the business language and business domain and avoid the implementation details. I mean, you think about it from the implementation perspective, it's actually very, very important. Your company, your business, the way your business processes work, those tends to change much less frequently than the software systems that we implement to support them,

right. Typically a bank would be doing their business in a very similar way over the last 100 years, right? Or an airline or an automotive company, right? Unless you restart the pivot step product every week or so, then typically the way the vocabulary use the processes you use there, they tend to remain fairly constant. It's just we constantly rebuild the software systems that support them because new

technologies come along. So if you focus on expressing those test scenarios from the perspective of the business, you will see much less change in the overall flow of the scenarios, probably a bit more change on the implementation side or the integration side, so. Now going back to your question Henry about 70 JS. There's a lot of interesting things that the 70 JS team is doing right now with all the new features. So recently we've introduced

Strengthy JS 3.0. Now one interesting feature. Many of those, but the most interesting feature about Synt JS is that introduces a universal web facade. What it basically means is that you can create your automated tests using strengthy JS, screenplay pattern, building blocks, interactions and questions and you can then plug any web integration tool it's going to be supported into your

tests. So you can run the exact same scenario using Webdriver IO or playwright or Protractor or puppeteer, which basically allows you to be completely vendor agnostic. So should there be a better integration tool in the future or you need to change from one tool to another or you want to share your code across different teams that use different tools? You can do it again thanks to the abstraction and thanks for focusing on the business

vocabulary. One other interesting feature that we've introduced recently is component testing. So apart from doing N 20 web testing, I think we typically use an acceptance testing framework for. You can also do component testing now so you can test individual react or view or spell or solid components using string, JS and tray right? So you can design and develop your low level interactions and questions.

Again scripting pattern, building blocks in a very confined space of a single component and then plug them into your end to end tests. Now what this allows you to do, It allows you to share test automation code between component teams and to end teams or product teams.

So for example if you have a component team building a design system for a company building color and widgets and drop down boxes and so on, they can provide you with test code that interacts with those specific components. And if you want to incorporate those components into a larger system and write an end to end test and detect those components, you can simply plug in this test alteration code that's already been tested at the uni level into your end to

end tests. Now if you think about it, this approach removes completely the problem of trying to figure out what CSS selector should I use to interact with a specific component or you don't care anymore. You just take a library to interact with a date picker, you don't care how the date picker is built. This also allows your UI components team to have much greater flexibility and freedom because they don't need to worry

about all the other teams. So if you think about it, the great thing about being able to use the same patterns for different kinds of testing, so end to end testing or acceptance testing, performance testing, component testing, is that you actually get to reuse test code across all those different test suites so you don't have to do your work from scratch. You don't have to start from scratch every single time.

Once you have a piece of code that works, you can just plug it into another test suite and run it in a different context. Now it's particularly interesting in the context of component testing. So if you think about it, 1 popular pattern that's very often used across especially large enterprises is that you would have component teams, UI component teams that develop design systems or UI widgets for

other teams to use. So you might have a component team that designs charts or dates because or drop down boxes or buttons for all the other teams to use and other teams would assemble those into your booking systems or trading dashboards or other sorts of UI applications. And this way by reusing the common UI components they ensure a common look and feel of all those systems and they also reduce the amount of rework that would be required.

Either wanted to build all this stuff from scratch themselves. Now with the screenplay pattern and Serenity implementation of the screenplay pattern, what you can do is you can share your test codes the exact same way you can share your production

code. So again if we have our components team that designs this, no date picker or a drop down box or a button and so on. Apart from providing other teams with this specific implementation of a component, they can also provide those teams with test codes to interact with those components. So if you have a date picker, you might have a screenplay task to advance a month, or pick a date or get the current date, enter a value and so on.

Another team using this specific widget could now incorporate the widget into the application and incorporate the widget specific test code into their N twin tests. So again, if you have a trading dashboard for instance, where you want to set a date of a trade, you don't have to think about well how the date picker is structured, what are the HTML tags I need to use, what are the CSS selectors? Now you don't have to discover this whole thing from scratch

every single time. You don't have to handcraft it, you can simply reuse the code that the team who developed the widget has already provided you with. If you think about it, this is a complete game changer in test automation because it allows you to avoid rediscovery of basic things like selectors and structures all over the enterprise, something all over again, and then seeing all the test suites break if someone changes even a slight thing in a

widget. It allows you to simply reuse test code the same way you would reuse production code, and completely addresses this whole class of problems around how do I find the right selector for this widget? Well, you don't care. You don't need to worry about the selectors. You need to care about the business scenario to be able to prove or verify that a trader can book a trade, that a traveler can book a plane ticket, that a shopper can now put a thing into their basket.

You don't need to care about the CSS selectors that you need to use to interact the shopping basket. Simply reuse the test code. So that's an absolutely amazing thing and completely on game changer for many teams that have been using particularly security JS. And yeah, I'm actually looking forward to how it gets adopted

in the rest of the industry. Thank you so much for explaining in depth about this Serenity JS, so I think I will put it in the show notes for people who are interested in this screenplay pattern. That's the first thing, right? And especially if you have JavaScript project, feel free to try to incorporate this Serenity JS. I'm a big fan of Serenity JS. I'd use it for any sort of front end project or even front end plus APIs.

If you've got a team who's familiar with TypeScript and JavaScript, or if the testers are happy to learn that or familiar with that, it really is a no brainer. One of the things I find really cool about that and we'll talk about Serenity BDD, but Serenity BDD is basically the Java. Implementation of the screenplay pattern, and there's a lot of other stuff that goes with it, but it's a similar concept in

the Java world. So often in teams that I coach, what I'd try to suggest is if they're doing front end work or UI work or if they come to with JavaScript and they should offer Serenity JS because of just the reusable components and the way it's fits nicely into the front end. Build cycles and when they're working on either back end components or sometimes end to end scenarios, if they're more comfortable with the Java world, then that's where anything BDD

allows that as well. It integrates with API testing and UI testing with Selenium and playwright and does all the nice screenplay stuff so you can create those reusable business components. But in both cases, what I really find powerful sort of what? Yarn was alluding to is the idea that what screenplay does it helps you step away from the implementation, and we've actually used it.

One of the first big screenplay projects we did was with teams where the testers were not particularly experienced with either the domain or with even Java. And so the way we got that team to sort of scale their automation and to. Produce more automated tests than anyone expected was by getting more experienced developers or testers to write these tasks.

So write the task of place a trade or place a booking or create a customer which actually interact with an API or a UI or a screen or whatever they need to interact with and then other testers who are maybe less experienced. They can assemble those tasks just like Lego blocks, and reuse those tasks without having to worry about what's selected to use. And if they need to extend it or add a new task, they can look at what's already been done and

start to learn how that works. But they've already got this set of building blocks which is very focused not on how to click on a button, but on how to interact with the business domain. And that's something. You see a lot of the low code tools these days. None of them go anywhere near that. None of them are able to. The best low code tool in my experience is when you create it yourself and it maps to your domain.

All of the low code tools that we're seeing now there might be exceptions, but I'm not sure how they could be, are very much focused on just basically scripting out low level interactions and. If you've got a good marketing team, you might be able to sell that well because it makes it feel easy to click on a button. But that's not where you get the

leverage. Where you get the leverage is where you can reuse business components and model business domains and actually understand that you are testing the important stuff and scaling your tests. So if you have an end to end flow where you're on board a customer of a particular type and may.

Take them through a long Kyz process and get them out the other side and make sure you've got heaps of systems that interact together correctly and then you need to do another flow with a different type of customer. You can scale that really well because you have all these reusable components. If you had to re script that, even with low code tools that's still quite a headache. When you actually start to do things at scale.

So I think that reusability, I mean, it does take some planning and some thought and some design. And that's where the BDD aspect tells, because it does make you think about modeling the domain concepts. That's where you get the scalability. One more thing to add to that, so people often ask us so should I choose Strengthy JS or should I choose Strengthy BDD? Which one's better? I mean that's not really the question that that's really important here.

So if you think about it now you can use either. If your product is predominantly using a JVM language, now certainty is a perfect choice. If it's not predominantly front end or scripting languages, trying to just is great. But it was interesting that both frameworks use the same reporting engine. So in fact you would actually use both Serenty JS and Serenty BD on the same project and many

teams do that. So now sometimes you might have a huge mono repo and know some back end services using Serenty BD. The front end was using Serenty JS, but what you can do is you can actually make them produce reports that get combined and the result in a unified leading documentation of your entire system. So we've come across cases like that, so we've made strength to JS and strength to BD support this case as well.

Might have the favorite from working with more complex requirements like finance, insurance and whatnot is feature mapping, which I find a really nice way of mapping out. User journeys, mapping out variations of what a user actually does or how data gets transformed. So it might be a user, it might also be a client record.

There are lots of different ways of looking at how a process works, so feature mapping is very good at analyzing, walking through, and visualizing how a process actually plays out and what are the goals, what are the outcomes we're trying to achieve. And a little bit more than say story mapping which is much broader feature mapping is very focused on a particular use case and how we look at the

variations around that. And the close second would be example mapping, which is the sort of go to tool I find just for getting clarity on what we're trying to do. It's really very deceptively simple but very effective technique for mapping out examples for identifying examples and counter examples and hunting out new ones. I think my other personal favorite is impact mapping.

And the reason why I would like the impact mapping is because it helps you to create this very easy to see visual association between the goal you're trying to accomplish, the actors that can help you accomplish this goal or can hinder your progress. It can help you understand the behaviors you want to change, and form some hypothesis around how you're going to change those behaviors.

What this allows us to do when using impact mapping tells us to create a very good communication link between typically business sponsors and the delivery team. Because business sponsors understand the goals very well, they tend to have a very good understanding of what is the audience they're trying to address with whatever functionality they want to ship. Now developers have a very good understanding of deliverables of

the features they can build. So what those two parties need to figure out is how actually we can now create those deliverables, how we can create software in order to change the behavior of the groups that we want to affect in order to accomplish our goal. So it's a really nice way to use when you facilitate workshops between business and technical people. Thanks for sharing some of these techniques if people are interested to learn more.

I think the book covers some of these techniques in detail right? Including examples and fictitious stories how this can be applied. And I think I would also suggest people reading a lot more about these techniques because they can really make the collaboration effort much more productive I would say and effective. So one thing about BDD that I always think people get confused where we should apply it right? Because there is a unit test integration test.

API tests, UI tests and so many other tests, right? Maybe a bit of wisdom here. Where should BDD be applied? Can it be applied to all of them? Or maybe yeah, based on your experience. That's a really good question and I tend to answer it by saying you want to use what I call the lowest responsible level of automation. And what I mean by that is what is the lowest possible level you can automate and still have confidence that your feature has been implemented so BDD

transcends. End to end unit integration. It can be any of those. Any test can be a BDD test. A BDD test is simply a way of illustrating it that a particular business requirement has been implemented and you could do that with the unit test or you could do that with an end to end test. If you take our example of for the product catalog adding a new column, you might have a BDD

scenario where you say well. Given Sally is on the shopping search page when she searches for some addresses and she should see the following dresses with these color options and that. Would that be a unit test? Would it be a UI test? Would it be an end to end test? An API test? It could be combinations of all of those. Whatever, depending on your architecture will be the most efficient way of testing that. It could be any of those, so it's not a specific.

You don't implement BDD at a specific level, you implement at the level which makes the most sense, and. I think throughout that, one of the things I really like about this BDD approach, so focusing on the observable behavior of the piece of software we're actually interacting with, be the system as a whole, being a component, being a unit or a function and so on, is that you're focusing on the

observable outcome now. What you can also do with those tests is you can now describe what should a given piece of your software do. So what you're doing in those tests you are not simply specifying what the system already does, So what a component or a function already does. You're specifying what it should do. Now, why is this important?

This thing that we all suffer from, that's called confirmation bias, which is basically the tendency to seek out and prefer information that supports our preexisting beliefs. One of the preexisting beliefs that all software developers have is that now our software, the one we've just written, is perfect, right? So if we write the software and we write the test after that, what we tend to do is we tend to confirm what we've already written. In the test. So for example, I might have a

customer class. I create a test that now I can set the address and I can get this sweet address from this customer, which is great. So I have just now confirmed that my code does what I told it to do. Big achievements, right? Here's my gold medal. But what is much more interesting was what are the implications for the system of the customer changing their address. What should happen in the system when the customer changes the address? Should their default settings change?

Where we make this change now with BDD, we're focusing on the outcomes. So what we can do in our test scenarios is rather than saying that my set address method works, we're saying that when a customer changes their address, their default tax rates should change to whatever state they are in right now. Now this is much more useful from the business perspective as well because now. Know. Should this test fail you know exactly what business functionality is affected.

You can know easily judge the impact on your business based on the failure of the test. If you tell a business person that, well, you know what? I have this unit test failing that was testing just one method in a class that you've already forgotten about. I mean, should we know? Stop the release. The business person will be like what? What are you talking about?

But now if you say, well actually with this those changes we just introduced, we've affected the behavior of how we calculate tax for our customers, well, this will get you a much better answer from a business sponsor. Around the risk readiness of the system. Thanks for expanding all those, right. So I think. I really like the confirmation

bias that you mentioned, right. So we developers, if we have to incorporate new tests in our software, we always try to confirm whatever that we have written right. So not necessarily the quality would be much better. So both of you are very experienced in BDD and software testing in general. Even John mentioned in the beginning you have worked with BDD for 20 years.

That's really a long time. Are there anti patterns, the common anti patterns that you see maybe your favorite anti patterns that you should advise us to avoid? Maybe some of anti patterns here if you can mention there are so many I'd say the biggest. One is what we said at the start, treating BDD as a testing activity.

Because if BDD becomes considered as just another way of writing tests, it short circuits the whole BDD conversation process and drains a whole stack of most of its value in fact, and also makes it actually harder to do what you set out originally to do, which is write the test if all you need to do is write is automate tests. So you don't need a BDD tool. You can do that perfectly well with any of the Java or JavaScript or Python testing

tools that already exist. You don't need BDD for that. BDD is all about the collaboration. So the biggest anti pattern is writing test scripts in Gherkin. The second big anti pattern is at the other end of the scale what we're saying earlier writing requirements in given, when then. So using the given, when, then notation as a way to write the requirements before you have the conversation and not as a way to confirm the understanding after

the conversation. Because again that short circuits the conversation that introduces the cognitive biases that YA was talking about. But from the other direction, that you assume that whoever wrote these wonderful given when then statements knows what they're talking about. So you don't question them, you assume that they're good. Whereas if you come up with something you're much more tentative and much more lightweight, you can have a much

more interesting conversation. So I'd say they're the two biggest anti patterns to avoid from my perspective, yeah, absolutely. I think the biggest one. Just like John said, is using BDD tools to avoid collaboration. That's kind of completely missing the point. Now interestingly enough, this typically happens out of good intentions actually. So you're very often see people new to behavior, different developments, like no product owners or business analysts.

They're trying to ease some of the burden put on the development team, and they just try to write all the Cucumber scenarios before giving them to the developers just so that they can avoid all this additional work. So they're trying to do the good thing, but the outcome is the complete opposite. You might have testers write the test scenarios in Cucumber so that they're easier to

understand to other. People involved in software delivery, but then again they will write them typically from the point of view of a tester. So the producer test scripts full of implementation specific logic, talking about UI screens and clicking on buttons and so on.

And what then typically happens is that now whoever reads this scenario who is not a tester by profession, they'll just now get bored halfway through if you're lucky and they just say, yeah, okay fine, I trust you just go with the school. So again, we're missing the whole collaboration aspect of behavior driven. Development and I think the next one is using UI to test everything. I think that's one of the more common ones.

So very often people think of behavior driven development as using Cucumber to drive CD numeral playwright or Cyprus or whatever other web testing tool and uses that to verify your system. And again, that's a misconception, the whole idea of expressing your executable specifications. In implementation agnostic manner is so that you can automate them using the fastest, most sensible interface that makes sense in this particular

context. That's what John was saying earlier about the lowest responsible level. If you can verify your business requirement at the unit level just by interacting with classes and functions, awesome. This way you can avoid incorporating all the infrastructure in our databases, docker, containers, all the other stuff just to verify. Something you can do at the unit level, that's fine. BDD is not about using UI automation tools to verify a fully assembled system.

It's about helping you collaborate with different parties involved in software delivery to understand what's actually required of your system, why you need to deliver it, and then to help you find the best possible way to automate your requirements. Either through the UI fine, but typically you'll have other better ways to do it. Thanks for sharing all these anti patterns I'm sure people. Will be able to relate to most of them, if not all I would say.

And I think that's a really key learning to end this conversation. So as we go to the end, I have only one last question for each of you, which is what I call 3. Technical leadership wisdom. So you can think of it like advice that you want to give to us to learn from you. So maybe one of you can share each your wisdom. Yep, sure. So I did come up with three tips that hopefully are useful. The first is that good practices transcend languages and frameworks.

So the thing to remember is that whatever technology you choose, it's less important than how you actually use it and how your teams embrace it so you don't get too hung up on a particular technology or tool. Focus on the outcomes you're trying to achieve. The second one is think before you code. The time that you invest in understanding a problem and digging into the requirements and challenging your own assumptions pays off multiple times in preventing defects and waste.

And the third gem would be lead by example. I find a lot of people will pontificate. I think it's a word. I'll say what she should be doing and tell people off because they're not doing the best practices. Don't tell people what to do, show them. And if you show that your own commitment to quality and learning and collaboration, then you've got a much better chance of getting your team to follow. So maybe I'll just add one more to this list of.

Three, so that we have four. When trying to optimize software delivery processes, I see many organizations, many teams look at factors such as delivery speed. So how quickly can we ship new feature to production? However, what's much more important is whether those features actually solve the business problems they've been intended to solve. It's much more important to focus on doing the right thing than doing the wrong thing

quickly. That's a perfect wisdom to end our conversation so. Thank you so much, John and Young for being here. If people want to connect with you, learn more about all these great practices, right? Is there a place where they can find both of you online? LinkedIn is usually the best place to find me. It's the easiest way to reach out and connect. If you'd like to learn more about our work, just connect on LinkedIn. That's probably. Yeah, it's probably the easiest way.

Yeah, absolutely. Same here. So if you'd like to connect with. I'm Young Moloch. My colleague is John Ferguson Smart. Should be easy to look up. So yeah, hopefully we'll see you all online. So thank you so much for your time. I really learned a lot about BDD. And generally good practice about software testing today. Thank you. It's been a pleasure. Thank you so much. Thank you for listening to this episode and for staying. Right until the end.

If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode and if you're new to the podcast. Make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better.

You can also find the full show notes of this conversation on the episode page at Techly journal dot def website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the show's mailing list on Techly journal dot def to get notified for any future episodes. Stay tuned for the next Technically Juno episode, and until then, goodbye.