Formulation Document Examples with Gáspár Nagy & Seb Rose

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Gaspar Laggy and Seb Rose all about their new book, formulation, documentation, examples given, when then if you don't know. Gasper is the creator of SpecFlow.

It's.

It's a widely used BDD framework for. Net and I think it's a really great implementation of Cucumber. But anyway, he's an independent coach, trainer and test automation consultant and expert focusing on helping teams implement BDD and spec flow throughout their companies. He has more than 20 years of experience in enterprise software development and he's worked as an architect and agile developer coach. Also, Seb is joining us. He has been a consultant, coach, designer, analyst and developer it Sundays for over 40 years, which I don't believe he must have started when he programming around 5 or 10. But anyway he's been in the full development life cycle with the experience ranging from architecture to support, from Ruby to Basic, all types of different programming languages. He's currently a continuous improvement lead with SmartBear helping apply the lessons he learned to internal development practices and product roadmaps. We have two awesome experts on the show. BDD can sometimes be controversial because I think most people do it wrong. Learn how to do it right. You don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com sourcelabs and click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey guys. Welcome to the Guild. Hello.

Hello everyone.

Awesome. Great to have you both back on the show. It's been a while and I thought this would be a great time to get back together since you wrote a new book. So I guess Gaspar and Seb, before we get into it, is there anything I missed in either of your bio that you want the Guild to know more about?

Well, I want to first say I've actually been writing commercial software for 41 years, but I started when I was a little bit older than five. So there you go.

Hard to believe. That's awesome.

Yeah, probably. I just have to think about making it a little bit shorter because as you just said all those things, it was a little Bit too long maybe.

That was awesome. Good to hear. It seems like cucumber is growing. I guess I'm going to start off the topic and maybe I'll edit this out. It's just curious to know. BDD started off as, I guess with cucumber or gherkin as a movement to get teams involved in writing better, having better communication about software. And it seems like vendors have gotten more and more involved in this as well. Is there a reason why some of these Cuban governor implementations have been acquired by different vendors? Or is there a push for customers that are causing vendors to get more involved in bdd?

Yeah. So I mean, I think the basic momentum behind this has been to coin a cliche shift left and a desire for test automation. BDD has benefited from all the wrong buttons being pressed. I don't know. Kashbo, do you. Do you have anything to do you disagree with that?

No, no, no, definitely not. But I see that. I think all these acquisitions is a little bit of a symptom or maybe an indicator that BDD has stepped forward and now it's somewhat more mature, which has also, of course, all these disadvantages as well. But I think with these movements there is a chance that reach a wider audience maybe.

Absolutely. So you've both been involved with BDD for a while and you've written a few books on BDD as well. So why this book? This book's on formulation. I'm not even sure what that means. So maybe explain why you wrote this book and what formulation is. Gasper, let's start with you or Sebi, the one jump in.

I think there are some books about bdd, but particularly books which are focusing on this topic that how to write good BDD scenarios. That's the very simple way of saying what is the topic of this book? There is not so many. And I think we have seen that there is a lot of practice gathered by the different BDD practitioners and then good ideas and good practices. Good. And we thought that let's try to put them into one place where you can find all these things in a single book. I think that's why we did that. Of course, historically how it happened, that's maybe a little bit of different story. But at the end, I think that's why we are really happy that we have this book.

Yeah. So I'd like to sort of just. I mean, I understand why Gashwa doesn't want to go into the history as such, but you know, I just wanted.

To give it to you that.

Yeah. Give it straight so definitely is a. You know, we think it's a really valuable book and luckily so do people that have reviewed it and read it. So, you know, that's a good place to start. But that's not why we wrote it. We actually started off from a, from a quote or a statement that Liz Keogh made. It must be getting over a decade ago where she said, you know, BDD is not about automation. First off, you need to get to a shared understanding, have the conversations, then you need to capture the conversations. And once you've got good at capturing the conversations, then you start using the tools to automate them. And our first book was called Discovery, and that's all about having the conversations. And this formulation is the second practice of bdd. So discovery is the first practice and formulation is the next practice. And that's where you take what you learned when you're having those conversations and you capture that in business readable language. And if you're going to use tool like Cucumber or specflow, you use the given when then Gherkin format. And so it was a logical place to go. You start with the first practice, you write a book about it and then, oh, well, we've got a series coming on, haven't we? So now we're going to write a book about the second practice. What I think is really is good for us is that there is no other book that quite covers this field. There's a couple of books that come close, but this is the first book to cover using Gherkin to capture the shared understanding that comes out of discovery in the shape of concrete examples.

So why do you think there is that gap or why was there this gap? Is it because it's an area where people aren't necessarily informed about, or do they skip it or is it usually muddled between discovery and it gets confused in that process?

Yes. So a lot of people try and when they're doing discovery, they go straight to give and when then the folk that don't go straight to give and when then. Well, it just seems really easy on Opus, doesn't it? You just take the examples and you just write given and you think of all the contexts that you could possibly have. When you do something, then something happens. You go and you look at your test scripts in, I don't know, one, in whatever test script database you keep them in, and you go, well, you know, this is the setup we'll call this given. This is the actions that the manual tester used to make. So we'll just Turn these into whens and this is what they check at each point and we turn these into thens. So the thing is, it's really, it's really simple to do. It's just really quite hard to do well in a way that's maintainable and understandable, which anybody that's read through test scripts that have been lurking at the bottom of an ALM for a decade will know. You look at these tests, you go, who wrote this? Why did they write this? What does it mean? What does it test?

Yeah, absolutely. In addition to that is that in many cases the BDD concept comes through the developers or the test automation engineers. And I think developers are typically assessing the complexity of something that, how complex the language is. And Gherkin is an extremely simple lang. It has I think less than 10 keywords or so and there are minimal constructs that you can really have in that. And therefore that gives that feeling that writing a scenario with given when then is easy. Actually it's not that hard, but I think it's not in that way easy how people would think. And you really need to get these small tricks and tips into your fingers to be able to make that better.

Absolutely. In theory, it is very simplistic. You can just open up a text file and you can write your specifications in it. So where does the complexity come in? Where, like I say, it gets perverted. I don't know why. I guess we'll, we'll dive into this. But it seems like a lot of teams I've worked with, it's used just for an automation framework rather than, you know, where I think it really shines is communication finding issues. Like you said, as we shift left before, we actually build bugs into the software and it allows the team to get a shared understanding. So is there a disconnect between it, when is it like whose fault is it and what phase? You know what I mean?

Oh, you want to point fingers at.

People, not point fingers.

But what's, oh, Joe, you bad man.

How can we make it better?

So I think the biggest, the first disconnect we cover in the book and it's that a scenario, you know, a structure that is a, is called scenario in Gherkin. And you can create big scenarios that cover end to end journeys of a user or an actor in the system and they then turn into these hard to read, hard to maintain, brittle encapsulations of a single flow through lots of connected pieces of functionality in the system. Whereas the way BDD and cucumber work really well is where the majority of the scenarios you write are what we call illustrative scenarios, illustrate a single business requirement or business rule. And this is a realization that actually has only manifested itself in the cucumber community, you know, in the past four or five years or so. It really started, and I give credit where credit's due, it really started when Matt Wynn discovered, created example mapping. So he was, he went, he was visiting a client and they were having real problems during discovery, not formulation, doing discovery. And he happened to have magically in his pocket one of those packets of five by three index cards where it's in four colors. And he just sat people around a table with these index cards. He wrote the story on a yellow card. And then he said, what are the acceptance criteria? What are the rules that govern this story? And he wrote those on the blue cards and he put them on the table and he said, does everybody understand what these acceptance criteria, what these rules mean? And it turned out they all had subtly different understandings of what those rules were. So we encouraged them to use the green cards to write out examples that illustrated their understanding of each of those rules, each of those acceptance criteria. And that's where we got example mapping. And it was only Gashboy, you'll correct me here, but it's only three or four years ago that the rule keyword got added to the Gherkin language. Up until we did that, there was no way to take an example map which has rules and it's illustrated examples and convert that or transpose that into a feature file because we had no way in Gherkin to indicate what rule an example was illustrating. We just had, you know, free form text. Now in Gherkin you can say this is the rule that we want to understand. And here are the scenarios that illustrate that rule. And lo and behold, we've now got a really smooth flow through from the discovery which where the conversation leads us to create concrete examples through to formulate scenarios where they are structured around the rules that they are designed to illustrate.

So the scenario so far before the rule concept coming in was basically just flying around and where they weren't really connected to the requirement. And I think that highlighted a typical testing problem as well, that at least those kind of tests that we typically having with VDD are functional tests. So testing the functional quality of the software. And I think it's easy to see that to be able to check the functional quality, I have to that the software really does what it's supposed to. And this is where people are typically stopped. But I think what is very important that what we supposed to make sense and whether what we supposed to so the expectations are properly documented. And that's the problem that was also visible I think in the BDD community that they were creating tests with BDD given and then language. And of course everyone was happy if they turned green and everyone becomes sad if they turned red. But they were really disconnected from the original expectations and therefore they weren't really useful, at least not as useful as they could be. So if you are investing the time and the money to make a proper automated test, then it just really makes it even better if you can really trace it back to the original requirements and the rule keyword and all the things that related to the better phrasing of the scenarios are somehow helping you with that.

Just mention that the first chapter of the book is on formulation. Then the section we're in now basically seems to land in chapter two. When you talk about cleaning up scenarios and you actually talk about example maps, which I've never heard about before. And I guess why did you start as a second step, cleaning up old scenarios? Because it implies that people are already doing BDD and I think it'd be a whole mess already. Rather than start with a brand new scenario, why start with cleaning up scenarios as the second chapter?

So that's a really good question. And the answer is we decided not to do that. We decided to do exactly what you said, which was start with a greenfield site. And when I came to write that, start writing that chapter, it just seemed more natural to go and show a team struggling with something that we have, we both have seen so many teams struggle with already. So part of the problem of getting behavior driven development accepted in organizations is that many people have heard about behavior driven development and a lot of them think that it's test automation using given when then to get people sucked in, we need to show them straight away that's not what it is. And that what you can do is you can use process of discovery, maybe with example maps or with other forms of structured conversation to get to a place of shared understanding so that everybody is pulling in the same direction and then capture that understanding not just for the team today, but for the team in the future and for product owners and customers that come along in the future. Because one of the thought experiments that I think that I use at one point in the book is asking people, you know, which they prefer, do you prefer, you know, conceptually this is, it's a thought experiment. Would you prefer to have unreliable documentation or no documentation. It doesn't take people long to think about it to come up with a set answer that, you know, honestly, unreliable documentation is completely useless. It would better have no documentation at least then we have to go to the single source of truth, which is the running system, to work out what it does. And so then I follow that up and ask you, ask the people, well, which do you have? And the answer is always unreliable documentation. Right. And so although discovery and formulation don't get there yet, when you've read our third book, which we're working on at the moment, which is about automation, you get to something called Living Documentation, where the scenarios that you formulated in business language, which document how the system is supposed to behave on a requirement by requirement basis, actually guarantee themselves to be correct because underneath them there's automation code that verifies that the system behaves as described. And honestly, when you get to a point like that, you're living in nirvana land. This is cloud cuckoo. Everybody gets happy.

And I think one part of that, and we were really thinking about it, how to structure the book, but we have found that going through this scenario, like taking an old bad BDD scenario and fix it, is a very easy way to get straight to the point and give the readers a kind of good high level understanding. And actually when we were having discussions whether we should start with that or not start with that, we finally realized that both 7 and we are teaching BDD and having trainings and this is what we were doing for many years, that we have to explain people how BDD works and how to do proper formulation. And we have realized that, okay, what are the tools? How do, what is the, what was the easiest way for us to get this concept through the audience? And we realized that this was such a good strong example which was helping the people to get straight to the high level concept that we should really start with that. And yeah, this is how we are able to introduce of these six principles that are afterwards detailed and work through the rest of the book.

Absolutely. You talk about six principles. It makes up the acronym brief, actually. And that's a big part of chapter two. Really quick, can you just talk about what makes up the acronym brief?

Yes, we made this acronym that people can better easily or more easily remember. And this is also true for ourselves as well. So B stands for business language. So that means that you should use the business language instead of the technical solution language. R means for real data, which means that it's good if these scenarios have concrete illustrative data which are really showing of how the system is going to be used. I means intention revealing. Maybe that's the most tricky one. But basically it's that whenever we are phrasing the scenario, we should rather focus on what our intentions were for those different things that we are doing there and not so much on focusing on the mathematical steps. How do you achieve that? In earlier people were calling it declarative versus imperative scenario. That was a word that was used. But when we were talking through the book, we wanted to get rid of this too technical word. And that's why intention revealing was basically found. E stands for essential. So that we want to keep only essential details in the scenario and push down to the automation layer all those incidental details, all those details that are not relevant for illustrating that particular rule down to the automation. And F means focused, that the scenario itself is focusing on a single rule and we want to solve all the problems with a single Oracle scenario or something like that. And the good thing is that briefness itself so that you have a concise and small scenario that fits onto the screen that you can easily share to the stakeholders. That also seems to be a good principle. So yeah, that makes altogether the sixth one.

Absolutely. And as a good practice, I used to recommend that if you can't read it on a screen, you have to scroll down. It's probably not as concise as it could be or as descriptive in a way that makes it really helpful for everyone. So that's a good point. Yes.

It's not brief.

Brief brief, exactly. I guess when people hear brief, especially when you work in an enterprise like, oh no, these scenarios are requirements. They need to be very FDA needs to come in here and it needs to be really on. So is there an issue with people getting confused with what is even a scenario in this point? Is it a requirement? And do you have to cover every conceivable point of what can happen with that particular scenario? Does that make sense?

The question makes sense. So first off, there's a section in the book where Gaspar makes it really clear that this is not about testing. Right. So we're not looking for every edge case to be covered here. What we're trying to do is that the scenarios are illustrations of how a particular business requirement or business rule is supposed to behave. Behavior is the key here. And what we need is just enough scenarios so that there can be no misunderstanding about what that rule means. You know, what we expect the system to do and therefore what work we expect our developers to implement in the cause of making that Making that rule part of the system. So we're in a space, you know, a Goldilocks space. If there are no examples, then, well, you just have to read the business language of the rule and understand it. And my experience tells me, or has shown me that pretty much any rule in any requirement can be misunderstood by somebody. And so you have to then say, well, what should happen in this condition, which is maybe edge case. And then you create an example to demonstrate how the rule should behave. Maybe it's a rule based on dates or times. We want to think about time zones, right? How many bugs have there been in the world based on a misunderstanding of time zones and daylight saving? So you have an example to show it and you get to the point where everybody in the room agrees that there can be no more misunderstandings, because the examples cover all the possible questions they could have. And at that point you then think about formulating them as scenarios. And every one of the examples that you came up with can become a test, can be formulated as a scenario. But we need to remember, and the teams need to remember that feature files and the scenarios that live in them are there to help document a shared understanding. So they're really, they're business facing. Maybe some of those edge cases that you went through, they're not really that interesting. To your product owner or your project manager, the examples are still valid. But get your developers to code them up as programmer tests in Junit or RSpec or whatever, or get your testers to run them as exploratory tests the first time around. You just want enough in the documentation so that the ambiguity from a business perspective has been covered. Because we definitely want our product owners to read these feature files and these scenarios and product owners are always very, very busy because they're very, very important people. So you don't want to make them read too much. You want to make them read just enough that they give you feedback.

Yeah, I get many times the question that, okay, I understand that the scenario that you show me in that simple business, this is so simple, but our domain is much more complex than that. And interestingly, when we start digging into that and we start working with their own user stories and breaking it down to the rules at the end, even in very complex business, the examples doesn't have to be really complex. And that's the key to accept and to get practice on the focus and the decomposition of the problem. Actually, this is what we are doing there in some ways. And the good thing is that this is anyway useful. So it's not because it's BDD and not because it fits to the brief principles. Because decomposition of the problem helps the team to write better software at the end. Because if you to describe something over 12 lines and there is no developer who can remember 12 things at least, definitely not me, but never really since others as well. So that will not work anyway. That code will be buggy in some ways.

Absolutely. And this book follows like a fictional team working through this whole process. Questions or what we've been covering here fits I think nicely in your third chapter on our first feature file. Is anything else people trip up on features or I guess a thought that just came to me and I know why is Covid so in a Covid world, like how much of a compet advantage would a team have if they actually had nice brief, clean readable features where the team is no longer now in the same location all over the place, but because they did the feature in a way that has a shared understanding that they were able to create better software quicker and faster because they put the effort in. And when this terrible Covid came around, the team was set up nicely to still be able to successfully deliver software that wows their customers.

Mno, that's absolutely like that. So I think teams are, even if they are co located and even if there is no Covid, they are overestimating their capacity of remembering things. And it's not only about remembering because maybe we have heard the same thing, but because we have different background and different contexts, we have interpreted it differently. And at the end that will be causing those clutches of whether it's a bug or a feature or whatever. So those kind of issues and having those little decisions documented is useful to avoid that. And as you said, it really helps to work distributed because then you have the core agreement, those pinpoints in the net of the implementation where at least if those pinpoints will be all green at the end, then there is much less chance that we get the things wrong.

You know, there's more as well in the sense that one of the main pushbacks against any sort of front loaded process is that it takes. It feels like it's more expensive to have meetings and understand something rather than just go and do it and well, it's only software, right? We can change it later. And it turns out that it's been said for many decades that this is not the cheap way of doing it, this is the expensive way of doing it. Shift Left has tried to capitalize on that or at least promote this idea that learning early through deliberate discovery is going to reduce the amount of defects that get into the software and therefore reduce the total cost of ownership of the software. But when you then move on to what you see a lot in this day and age, which is teams that come and go quite quickly because there's a lot of churn in the industry and products that live for quite a long time and need to be enhanced and maintained as the business world and the regulatory framework changes around it. Now you get to the point where you've got bits of software and people who've never worked on them before come along and go, well, wtf what's this doing? How did it ever work? What was its requirements? And if there is any documents, and sometimes there aren't any documents at all, if there are any documents, well, they're unreliable. So this, there's, you know, in your question, Joe, you talked about is it cheaper, faster and better? And the answer is yes, it is. Getting that convincing people of that is still very hard. And people ask why is there no definitive case study with, with dollars and cents added up? And the truth is because it's really hard to have a control case because the life of time of a product isn't weeks. You can't do it in a lab and see this saving play out over a five day controlled experiment with students. You need to have product owners coming and going, board members changing direction, teams being outsourced to one location, then brought back in and products changing.

And you need to have done.

Yeah, exactly.

You know, absolutely. I actually lived through this. I try to fight the good fight with the BDD together, done correctly. And then they got rid of the whole division, they laid everyone off, they outsourced it. And the people got back to me and said, hey Joe, can you help us? We want to have a new framework to write. And I'm like, they totally missed the point. They're going to start over, missing the point. And like you said, if they put the extra effort up front when they did this sort of transition, you know, it would have been smoother and they would have done get the benefit over time for sure. So I guess the next part of this is writing stories. So chapter four, what do people get wrong when writing stories that you think maybe trip them up as well?

Yeah. Okay, well, I think the problem with user stories is long.

There's no problem with the user stories.

Well, I mean, where do you start? User stories are also, well, misunderstood. User stories come with an acronym, invest. The INVEST acronym is one that I've taken to task in a number of presentations and conference talks, because even the acronym INVEST is quite difficult for people to get their heads around. I'd suggest that the main problem about user stories is that people don't appreciate the fact that they were created as a way to defer detailed requirements analysis. So if you go back to the XP world, people used to say a user story was a placeholder for a conversation, and that's what discovery is. So BDD takes user stories in and the conversation happens during discovery. The bit that I think most people may be not very keen on doing and avoid is that as part of that conversation, the user story should change. Now you've got a detailed understanding, you want to split it up into something that's small. There's a migration from a large user story, which Jeff Patton in his memorable asteroids metaphor calls a large asteroid. And over time, as you discuss it and understand the complexity, you break it down into smaller asteroids until eventually you end up with really small, fast moving asteroids. And those are the user stories that you want to bring into your iteration or sprint backlog and deliver really quickly. So the biggest problem with user stories is people don't use them in the way that they're intended to be. We talk about user story and people reckon, well, if we use the standard Connextra structure, which talks about who's going to get the value and what we're going to do and what the value is going to be as a I want so that, well, that's a user story and it never changes. But actually the point is we should have the conversation and create many smaller, more detailed user stories that each allow us to deliver incrementally and iteratively another thin slice of functionality so that we can eventually, in a low risk way, deliver what our customers want.

I guess one thing that you pointed out in this chapter, I know I have it in my notes, is there's a few things. First one is something about readability trumps automation and like you said, it's not about automation. Automation is a benefit of this. So I guess where's the happy medium then? For people that know ultimately they want to use it for automation, but they want to get the readability and the communication as well.

Yeah, that's a very hard question. But I try to watch myself when I implementing something through BDD in a way that I'm the one who is imagining the thing, I'm the one who is formulating the scenarios, and I'm the one who is actually automating it. And I realized that if I try to totally forget about automation for a moment, which is really hard because of course I'm a developer, I know that it is going to be automated. But try to forget about that for a minute and try to describe what I really want and then try to capture that as quickly as possible and then see whether it really makes any conflicts with the automation. Then that's the thing that was working for me. So for me there is no compromise. So you really have to forget about automation at least for a moment. And of course then once you have a clear picture what you want, you can let it verify whether we are able to make that. And we are able to make that of course means that whether I will be able to make the software and we are able to make the tests for that which are verifying that. And that's a very good feedback channel. But I think for writing the scenarios for me that really worked the best. If I really try to forget about automation and I tested this with a couple of teams who were brave enough to try that and it worked for them. You happen to see the two sides of the coin, otherwise it just doesn't work.

Yeah. So I mean, just wondering, I'm going to labor the point here. It's not a trade off. Do not let the automation intrude into the scenarios. It's not necessary. Cucumber and specflow both have many various under the hood automation techniques that allow you to do all the things that you thought you wanted to put into the scenario. That's where you know this is just basic software engineering, abstracting away the details. The scenarios are formulated to talk about the intent, the behavior, the details. You don't need them there, you need them somewhere. Right. But you don't need them in the formulation.

Absolutely. We dive into that. We're going almost over time, so I want to get to the rest of it. But that's a great point. Hopefully when you get to your book on automation you'll join us and we'll dive into that as well. Yes, I guess chapter 5 is. It seems trivial, but when I worked for a Lodge once again enterprise with eight to 10 sprint teams, it became a really tricky point and that is organization and documentation. So why is this so important? I know from my experience it was hard because you'd have different Sprint teams that weren't able to find where things live so they would create the same scenario, the same type of thing over and over again and because they just didn't have time to find it. So I'm curious to know, is that something that you've seen as well or why did you write this particular chapter?

Well, because we wrote this chapter because there was a perennial problem. So the basic problem again, I'm afraid, comes back to user stories, which is that the de facto behavior of teams is to have a one to one mapping between user story and feature file, which is an anti pattern. And we go into details in the book about why that is bad. But if that's not the right way of doing it, how should you split things up? And you know, I'm not a very organized person. If you ever see me on a webinar, you'll see a very black background behind me and it looks like I'm in a wonderful laboratory. But if you taunt me, I'll go and pull the cord and the black background will go up into the, into the roof and you will see the chaos and mess that is my library. And that's how many people's documentation is they. You know, they're used to having wikis with lots of information that's out of date and links that are broken and things that should be together in separate places that you can't find. And it's a nightmare. So like so many things in the world, if you do a little bit of tidying things up every time you make a change, then they stay tidy. And the same is true of organizing scenarios and feature files. Come up with a structure, make it logical, base it on a simple metaphor, which is, you know, the one we suggest is chapters with sections and subsections and put things in the correct place when you write them. And then as you add to the documentation and add more functionality, refactor that documentation to ensure that you keep it in a structure that makes sense to the people that are specifying it and implementing it.

It's very funny that I think people are anyway judging, for example, tools based on how good their documentation is. So I have heard many times, oh, this tool is great because it has a great documentation, or this tool is not so good because it's impossible to find anything. So generally it looks like that we know that a structured, easily searchable, meaningful documentation is a value. But whenever it gets to our own specification, our own documentation of the software that we are building and we are going to build for several years more, we somehow don't necessarily see that the same kind of structure and the same kind of values are also applying here. And again, it's not so complex to make that. It's a few little tricks that you need to follow. And then you get basically, with the same investment, you get much more value out of that.

Great. And the last chapter we touched on this a little bit is Coping with Legacy. As I mentioned, a team I worked with, we were doing BDD for about six years. They got rid of the team, they moved overseas. And I'm just curious to know how that transition went. So they have to deal then with legacy of these bdds that have been around for five, six years, and the original team's no longer there. So some quick takeaways from this chapter to help people that maybe are in that situation. Like, oh my gosh, now what? How do I deal with Legacy?

I think this was the most tricky chapter in the book because there are so many problems with Legacy and so many interesting challenges. And we could have made a full book about that. But unfortunately, Michael Feather's book is still very valid, by the way. So we really try to focus on the thing which is related to BDD formulation. And I think the most important thing that is related here is that somehow people think that whoever is transitioning to BDD and they already have some manual test scripts, then one easy way, I mean, they say one easy way to transform to bdd, to take those manual test scripts, simply transcribe them to BDD scenarios and automate them. Unfortunately, this is something which is not working. The core difference between what is the cost factors and what are the problem manual test script and what are the cost factors and the problems with an automated scenario, if you just try to draw them, then it will look like that they are totally different. Manual test scripts are more focusing on the human who needs to execute them. And of course, the human can check so many things at the same time, because that's what we are good for. On the other hand, for automation, the biggest cost factor is to maintain and create those automation code. And because of that, this focused and illustrative scenarios that we were mentioning are working much better. Which means that unfortunately, you cannot simply one to one trans translate or transcribe a manual test case to one BDD scenario. You need to go through that, think it over, which kind of business rules we were validating there and maybe making many smaller scenarios out of that, if this is really what you want. But in many cases we have seen that actually looking into the one topic of the code or one part of the code and trying to come up with the key business rules that are the most important ones that we want to cover, maybe that's a better, better way to go.

I just want to emphasize one Thing. So Gasp said you can't transcribe, you can't take a manual test script and automate it using Gherkin and given when then actually just to correct. I mean you can do that and people do do that and they get into awful trouble doing that because you end up with something that is just as incomprehensible. But now you have to maintain automation code that is incomprehensible as well. So you can do that. But please don't do that. Please don't.

We should end it with that because that is like one of the biggest points there because that is a nightmare. I've lived it there myself. So great book. Like I said, it takes a team that actually works with the whole process of what we talked about so far. So I guess to end this, any quick takeaways or best practices you can give to someone? Actually actual advice you can give to someone listening to this that they can implement right away to help make their bdds better. I will start with you, Gasper, and then we'll end with Seb.

I think one thing that you can maybe try to take from the book is that try to listen to yourself and try to make practice. And this is also why we have this imagined theme in the book that you see that these are real discussions and you can make options and you figure out which one works better for you and then inspect and adapt. That's a good way to go.

I guess. I'm going to go for a twin takeaway. Sorry, Joe. The first is please read discovery first. So the core practices of BDD are discovery, formulation and automation. And you really will get much more value out of them by applying them and learning them and applying them in that order. And then the actual takeaway that I want to give you is that behavior driven development is about shared endeavor. It's about reaching shared understanding. This means it's about collaboration. So it's not something that the QA or test department can do on its own. You need to have development teams involved and you need to have your business or your product owner bought into it as well. If you have any people that are just going, nah, it's not my business, I'm not interested, I'm not going to get involved. You're going to have a painful time of it.

Absolutely. Thank you so much, Seb and Gasper for joining us today. And I highly recommend everyone check out the book formulation document examples with given when. Then there'll be a link to this in the show notes. You just need to go to testgill.com.

And we'll also have a link to Discovery there as well. So thank you guys so much and you're welcome back anytime. And hopefully once that Automation book is out, you'll be one of the first to be on the show to talk about that as well. So thank you so much.

Thanks Joe.

Thank you very much.

Cheers.

Thanks for listening to the Test Guild Automation podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.