Welcome to Software Testing Unleashed, the podcast for testers, developers and software makers who live quality as an attitude. Get fresh ideas and sharp insights to grow your mindset, to learn new methods and to drive real change in how we build software. software and better teams for a better world. Hi, I'm Richie, software quality coach, keynote speaker and author. My guest today is Gáspár Nagy.
Gáspár is the creator of SpecFlow and RacknRoll, and he brings more than 20 years of experience as a coach, trainer and test automation expert. He's one of the top experts for behavior-driven development and co-authored the BDD book's discovery and formulation. He's also a key figure in the open source community driving the Rack'n'Roll project and sharing his experience at conferences worldwide. In this episode, we talked about his passionate topic, behavior-driven development.
Why is it that a simple example often reveals more truth than a carefully written specification? What happens when teams confuse BDD with just another testing technique and miss the real value? And how can executable specifications change the way we collaboratively deliver software? We explored how BDD helps bridge the gap between business and technology, how examples drive understanding and how tooling like Rock'n'Roll or SpecFlow supports this process in practice.
You will hear how teams can start small, collaborate better and deliver with more confidence. And now enjoy the episode. Hi, Gáspár, nice to have you here on the show. Thanks for inviting me and I'm really happy that we have this recording today. Yeah, I'm happy too because when I saw you were in my backlog and then I got the recommendation from another guest too that I should invite you and that was my double check that I have to do the episode with you.
You are well known for an advocate for BDD and so it's a good topic to start in there and to talk about this testing method and to give the community some insights there. I'm really happy that we have the conversation. I think we will see us at the HUSTEF this year too, so we can chat in person there too. Yes, HUSTEF is kind of my home conference, so I'm trying to be there all the time. For me, it's the first time and maybe not the last time. Maybe I will join every year now.
Let's get into the topic. So if we say BDD, how would you describe it in one or two sentences for whoever has no idea what BDD is? So yeah, I would say that BDD is a software development methodology or approach. And basically this approach is focusing on having better understandability of the requirements, also having better verification of the requirements, and maybe also a little bit better documentation of what we wanted to do, better documentation of the expectation,
the behavior, this is where the behavior comes to this topic. So that's the three key elements of that. So we would like to have a better understanding of the requirements, better verification of them, and better documentation of them. And I think the thing that is most visible to the people who have seen BDD already is these BDD scenarios. These are basically textual
descriptions of a piece of behavior with these given-and-then keywords. And they are typically used with tools like Cucumber, SpecFlow, Rack and Roll, whatsoever. So I like the idea very much that it's more about understanding what we have to do in coding and testing. So because this is often the real gap, this transformation from a thought of a requirement to the technical part, there we lose a lot of things often on this way. So I think this can can help a lot.
So, and you said the structure, but how can BDD fulfill that, that we get this better understanding of requirements and of user stories or G?
So, basically the idea here is that we would like to, so when you need to understand the complex topic, not necessarily software, whatever, then typically humans understand it in a way that you are showing them a couple of examples and based on the examples people just learning that and maybe after that you also read the the abstract specification whatever but but but basically the examples are helping our understandability as humans the very basic example is if you want to play
football or soccer then then never nobody's is learning that by reading the the game book there is a book and everything is properly described there Nobody's learning it by then, but everyone's just going down to the field, see how others play. And they are just catching up with the game and understanding the things.
And after they have some good answer, maybe they will have some additional questions and maybe sometimes they even need to open the book as well, but especially if they are doing it in a professional way. But basically we are learning through examples and you can see many, many other cases of that. It doesn't matter whether you learn something as a child or as an adult, Learning, by example, is a human thing. And somehow, we have forgotten that with software development.
Somehow, we have this common misbelief or something that if we are able to write down the specification in a proper document with proper sentences, every word is really carefully selected, then suddenly, people will understand the problem and will be able to provide a solution for that. But unfortunately, those things are very valuable and good. So it's nothing bad about them.
But to be able to make sure that we really understood the same words in the same way how the one who has written that did, we need to work on that. We need to collaboratively thinking about that. Coming up with a couple of examples that, yes, this is how we imagined it. Here is an example how we imagine this application to actually behave once it is going to be implemented. This seems to be a very effective way of having a
better understanding of the requirements. And I think for the testers for sure, but for everyone, I think it's pretty clear that if we have a better understanding of the requirement, then that's altogether making our entire process much more smooth. Because if you have a good understanding of the requirements, you can write better test cases, tests for that. The developers be able to make it immediately the right way and they don't need to do so much rework.
Everything is, you will not have the kind of problem that you are working a lot as a team and at the end the end result is not exactly what we wanted or what the customer wanted. So altogether this could improve the situation and the key thing is the examples and that's And that's what BDD is based on. I mean, there are some other technologies or methodologies as well that are using examples. Examples are generally good.
And basically, those BDD scenarios that I mentioned, the give and bend them things, should be seen and can be seen as a properly written down example. Basically, when I say that given I have like $20 in my account, when I try to withdraw $100 to the ATM, then the transaction will be rejected because I don't have enough funds. That's an example which is showing the rule that I can only withdraw as much money as much I have in my account.
And basically, everyone thinks that this example is very basic, right? I think the typical immediate reaction that, oh, this is trivial, this example is trivial. But it looks like that if you just keep doing that and keep coming up with examples, then sometimes the example is triggering very interesting questions that, OK, what did you say? You said that trying to-- what does that mean?
And those discussions are very valuable because those discussions basically will help the team to have the understanding of those small little details that are always causing the trouble throughout the development process. So that's how I feel that better understanding of the requirements is generally good. And of course, it's also very important, also are very much related to the testability as well. >> How do we create these examples?
How can we get use of them that we have then written down in this structure? Who is in charge of this doing that typically for a good team? >> That's a very good question because I think there is a typical misunderstanding about that. Because most of the people when they first see such a BDD scenario with a tool like Cucumber or whatever, then their immediate reaction that, "Oh, this is just another form of a test," which is not bad.
But if you have seen my description, basically that's just the end result. This is not the starting point. Of course, there are some similarities between a test and a BDD scenarios, but the things are not working exactly in the same way.
For example, how you come up with those scenarios is different from how you come up with an additional test because in testing, if you want to make a new test case, then you can use some techniques, you can use some test analysis techniques that was also shown, I've seen the episode in the show as well. For example, boundary analysis and such kind of things. It's more like an engineering work so that based on the knowledge and based on your heuristics and whatever your
knowledge about testing you can make test cases. But for B2B scenarios that's different because this is even earlier in the process where we don't really know too much. We don't really know enough about the problem so that we could make a test case. So the good approach is or the best
approach is if we are really trying to come up with these scenarios or examples together. So If you would try to do it in a way that the product owner is just writing down these scenarios and would come to the team that, hey, I have made you 20 scenarios. Please work and come back when you finish.
Then basically, we would jump back to the same point where we started so that there is something which has been written down from the perspective of the business, only from the perspective of the business. And we don't have this verification whether the team really understood that. For this understandability, we really to do this together, which sounds a little bit weird, especially nowadays, because we want to
optimize the things. And if we are sitting together, even virtually, that sounds like an expensive thing. It is maybe an expensive thing, but it's a good investment. And therefore, so that's basically people are sitting together and trying to think about that there is a business rule. OK, what kind of examples could we imagine for that? And maybe they are just coming up with one or two examples. Maybe this is just done in one minute because everything seemed to be clear and the rule was
anyway understood in the same way by the entire team. And maybe it will trigger some very interesting discussion and maybe it will turn out that the rule, the business rule, how we describe is not even fully proper and they would need to make some changes of that. So the collaborative nature is very important and we need to really start that with by sitting together and trying to discuss it through what kind of examples we have, what kind of scenarios we are going to have.
Example mapping is one particular meeting facilitation technique that you can use, but there is also feature mapping. There are other things as well and some teams are just inventing their own meeting facilitation technique. It's really a simple thing so you don't really need to do much, but this collaborative nature is very, very important. Otherwise, the value doesn't really come out.
Yeah, I think it's so important, as when I see when I work with my teams and my clients, too, they all talk about, yeah, we have to do the shift left thing and going more shift left, putting the quality in there. But as you describe it, it's a real shift left because it's so much in the beginning where we try to get the same understanding, which is a foundation for a good quality in the whole process afterwards.
So I think it's really important to discuss these things in the team as early as possible. And sometimes it's really providing very wonderful results. So even though I'm in this now for many years, but sometimes I was even really surprised that, okay, what kind of knowledge we have gained, what kind of discovery we have made
how much better the end result has been. In the beginning, actually for us in the teams where we were working, it was just really started in a way that in the meetings where we wanted to discuss the user story details, we were always coming up with the question that, okay, this is great, but could you please give us an example? It's a very innocent question. You can make this question even without mentioning BDD or even without knowing about BDD. That's a very natural question.
And just by using that fashion often is doing the magic part of that. And definitely this is the level one of applying BDD, so to say. Yeah, yeah. One comes to my mind, it was a situation, one client a few years ago, where I had a hard discussion with the test manager there, because I said, okay, you can use BDD if it fits, and it's okay to use this structure of
given when then. But he was, his opinion was that he has written down in his test plan that all has to be in this BDD style, but this leads to test cases which are not, were not readable anymore, because they had a given when, when, when, then, then, when, when, when, when a lot of lists to to build on this, all this complexity, where I see no really benefit anymore. What's your opinion of using this methodology and granularity of these examples?
- So yeah, so the concept of given-when-then is basically nothing new to testing, right? So if any tester is making a test case with different steps, then you have some steps that are some sort of preparation steps. There are some steps you are actually testing something and obviously you also have some verifications attached to
those things and this is just another way to express that. So therefore the structure of give and bend feels natural to everyone who is in the testing field and obviously if it feels natural then people can also use it for describing their own test cases as well which are not related to BDD. Again, this is a natural movement because maybe writing down it with given band then is still more convenient than making it in an Excel sheet. I don't know. I'm just so it's a
tooling question, so to say, at the end. Obviously, for BDD, it's very important that that these scenarios are describing examples that are properly describing the behavior of the system and to be able to make sure that they are really describing what we wanted, they have to be readable. Because if it's very complex and you need to really have 10 people sitting together to try to figure out what this scenario wanted to do, then that kind of validation of the thing wouldn't work.
So the business readability is super important to be able to make sure that those are not just tests and don't take the just word in a bad way. So these are not tests, but this is the specification. This is the specification, and based on that, we will make a lot of other tests. If you don't understand this, all the other tests that we make out of that will also not necessarily be doing what we wanted. So the readability of them is very, very important.
Some teams are also using the same tooling, the same phrases with normal test cases as well. This is not necessarily bad, but could be a problem with the confusion, so that somebody is just looking at that and they are confused. Why do you say that this is a BDD scenario if it looks much more different than this one?
My recommendation is that if you really want to do that, then make a very clear separation, put it into a different folder or whatever, mark it with some special tag that, okay, this is not specification, This is just some additional test cases that we did to be able to with the same tooling, but somehow make the distinction clear to the entire team to avoid confusion, basically. Yeah, yeah.
And you mentioned it now because there's not only the magic in creating these examples, but also in using that for testing then. So if I have my example, it's possible to create test cases out of that and connected to the code in a way. Can you tell us about this procedure a little bit more? >> Once we have these scenarios and just to give some impression for the listeners.
Obviously, there is no average size of users, so but if you can imagine an average size of users, so then we could say that an average size of users can be broken down to three or four acceptance criteria, some rules. For each rule, we would have one, two, or three examples. Altogether, for one user story, you should think about these 10-15 examples. That's the magnitude. If someone did proper testing, they know that for an average size user, so you need to have much more tests than that.
This is really just the, you can also imagine these like you have a safety net, and there are different points where the safety net is and basically the rest is more or less covered. You don't need to have some hanging for every part of that, but at least a few, which is making a good balance of your safety net. BDD scenarios are just holders for your safety net and of the understandability of the requirements.
And obviously, if we have this, and if we have discussed it, then it's very natural that, okay, why not verify that at the end, what we have implemented is really fulfilling those cornerstones or key examples, so to say. And there are many tools, these Cucumber family tools, that are basically making these given-when-then-based scenarios somehow automatable. There is no magic. So it's not like that Cucumber is reading the English sentences and it's automatically making whatever some
Selenium driver, which is, no, that's not working. But it just gives you a little bit of help in a sense that once you have these give and then steps, for every single kind of step, you can tell the cucumber that, hey, if you see a step that I try to withdraw $100 from the ATM, this is how you should automate this particular step. And you have another step like, then the transaction fails because whatever,
this is how you should automate this step. And once you have made these small automation blocks, like legal blocks, then QCumber is seeing your scenario with whatever three steps and they are putting these automation blocks together and making it an executable test. So at the end, what we will have, it's very again very wonderful if you want to say it like that, because you have
the written specification and now suddenly you can run it. In software development there is this this term of executable specification as a concept. Basically, BDD is one implementation of this executable specification concept. This is very good because it means that if those scenarios are passing at the end, then there is a high probability that actually our system is going into the right direction and we have implemented it in the right way. Now, there is an additional twist.
It's also important from the testing perspective that actually what we would like to encourage teams to do is that they shouldn't do it in a way that, okay, they read all the scenarios, they do the code, and at the end, they do the automation of that and happy if everything is turning to green and unhappy if any of them failing. But we encourage people to do it in a way that they should do it step by step. They should just take the first example, which is maybe the most simple one, right?
A successful withdrawal. Try to implement the code until they fulfill that. Okay, it's of course will be a half-baked, half-finished something, but at least we have one scenario which is already blessing. And take the second scenario, which is maybe a special case when somebody is trying to withdraw a negative number, I don't know. Try to implement the code that it provides the right solution for that, the right error message. Move on to the next scenario, next scenario, next scenario.
And basically, once all the scenarios of the user stories are turning to green, that means that your solution for that user story is complete. And this is very important because when to stop, when we can say that something is complete, and how to track the progress of the implementation is a very hard thing. I have worked a lot with projects before, and probably anyone who is listening to that is all remembering those discussions that are we now at the 70% or the 80% of the end?
At the end it turned out that we were only at the 20%. So it's very hard to see the progress of the user story implementation, very hard to make some guesses when we are going to finish. But if you are doing it such a scenario by scenario thing, then all the things will be much more predictable. Sometimes this is very hard to achieve because people think that okay, why should I do a half-baked implementation if I anyway know that there will be a negative number
check?" So you have to overcome this kind of mental thing. But if you do, then you will see that there will be a twist. Because once your implementation is going to be much more driven by the requirements, and it will find its own shape by doing that, and altogether that final design, the final solution, is going to be better than what would you flesh out immediately.
This is in software development called a vertical slicing. That means that you really try to complete your solution in a kind of end-to-end way for one particular aspect of the functionality and then you move to the next aspect. So basically if you do BDD in a way that you are really doing, this is where the driven word comes to BDD. So these scenarios are driving your implementation, you are just moving them one after the other. And then, then all together,
the end result is going to have a pretty good design and pretty good shape. Basically, this is the same technique as is being used in test-driven development. But just test-driven development is more about the technical aspect. And this is about the requirement aspect of that.
And I think it's, it's, it's, it solves a big issue of a lot of agile teams who are building in their iteration some mini waterfalls where you have the planning and then the development phase in the last two days you are trying to test and test automate everything which is then created but if you go to this PDD behavior driven methodology you have always these small slices and build a real iteration in an agile way of thinking so you have not the stress at the end
of the sprint and you see always where you have this progress. Exactly, and in the meantime you have the full transparency so that your product owner also knows that you have 10 scenarios scheduled for this user story and they will always see the daily report that three of them is already passing. They can read those scenarios because
those are readable. So maybe on a Tuesday morning your product or just checking the thing, oh these three scenarios is already green so I'm just going to make a manual check, some exploration on on the demo server and they can already provide feedback. They don't even have to wait until the full user story is going to be finished. So there are a lot of extra benefits that you can get from these things. Yeah, absolutely.
- Yeah, and it's really a nice connection between the business view and the technical view. So we have always the situation where the product owner wants to know what is going on with you developers, what are you doing here? and telling everything in their code view, but there is no really match between them. And with BDD, you can create this connection between the business and the technical view and get more transparency, as you said, and information out of it, yeah.
- One of the earlier books about behavior-driven development, there are some other names that are basically meaning the same thing, except test-driven development is about the same concept or specification, by example, is also essentially the same concept. So Goyko Ejic had his first book on specification by example, and with the title that bridging the communication gap.
So basically that making a bridge between the requirements and the actual technical assets, the code that you are actually building. I think this metaphor works pretty well. So it really makes a strong connection between those two sides. And when we talk upfront, you also mentioned that you are also investing a lot of time in your history with BDD in tooling, in the tool part of BDD. So maybe you can give us there some insights, what is usable and what are you doing there?
So I think the history of BDD is very interesting. I don't want to go into too much of the details, but I think BDD in this form, that's typically how people see it, become successful because there was a good tooling support provided for that. So Eslech Hellesoy in 2008 created the tool called Cucumber.
There have been some tools before and there have been some alternative tools after, but still really this tool was the one that helped to open the doors for this methodology for too many of the teams. So even though the concept is about requirements and understandability, the tooling that supports the automation aspect is also very important for that. So Cucumber has been created in 2008 and I was first encountered BDD in a project in 2009, so one year after.
And when we started to do that, we were trying to use Cucumber as a tool, But there were just some platform problems because it was for Ruby and we were working on Microsoft.net. So we basically made a port of Cucumber to.NET. It's basically trying to match it to the ecosystem. And we made it also open source. Cucumber was also an open source project called it's SpecFlow. And basically I became the kind of the owner or whatever, the core maintainer of SpecFlow within the company I worked for.
And I kept working for that, making conference talks and many other things, trainings for for SpecFlow. And then because of some other reasons, I moved a little bit away from the SpecFlow as a tool. I was not really part of the maintenance teams anymore. And because of some company political things, I don't want to go into that. Basically, the SpecFlow name and the code base was abandoned by its owner. But we needed to have some tool which is up-to-date with the latest.NET framework.
Basically, one and a half year ago, I thought that, "Okay, let's do a fork." This is how in open source called the action, where you just basically copy the code base and start it from scratch. Copying is allowed. That's the beauty of open source that you have all the licenses to modify to work on the code base. That's very valuable in this case. We had to rename it because of again some legal and trademark issues.
Now the new name is called Rack and Roll, and we have a nice team of voluntary contributors who are helping to move on with this. It's a lot of work, but it's really very enjoyable because it's very good to see that people are also putting their free time, their enthusiasm, their ideas into that. We have some interesting discussions because of course it's in many cases it's not so easy to decide whether A or B is the right way to do and many other things. And so that's what I'm doing.
So but it's still for.NET. It's a.NET framework for BDD. - Exactly, exactly. Still the kind of the.NET version of Cucumber. I think the obvious question would be that why didn't we call it Cucumber then? I just, trademarks and wrong timing. That's the answer. So we had to find another name. And once you have a name, it's very costly to change the name. And so whatever, it's called Rack and Roll, but it's kind of the official.NET implementation of Cucumber.
And there is a very strong collaboration between the Rack and Roll team and the Cucumber team. So we are talking with each other on Discord and they are contributing to the Cucumber source code as well and they are also giving some suggestions for the Rack and Roll code base. So it's an interesting inter-open source project collaboration as well. - Yeah, yeah.
I think it's a very nice environment to work in this international, with international people who are working together on an open source project like this. Sometimes they don't even know where they are from and what's their real name. You just need to see their handle and see that they are making some good progress. Yeah, yeah. And so we will put the link to the project also in the show notes. So if everyone, if someone wants to join or wants to use it.
So there is the link so you can follow that. Yes, Gáspár, thank you very much for all these insights into the BDD methodology and also the tooling stuff. I think it's a very good view to BDD to not see it just for testing or for implementing something but for understanding requirements and this is a huge benefit for teams, I think. So thank you very much for this perspective and for your time here. And we see us in Budapest in a few weeks. And yeah, hopefully then we have chat too there.
Exactly. Thank you very much and I'm looking forward to also personally meet you. And maybe we'll make another episode. Yeah, we will see. Thank you very much. Bye bye. Okay, bye bye.