You hit the mark exactly. This same type of thinking I used for over 15 years working for a major So Calif Utility Company. Since I had previous engineering design experience combined with my computer background I was usually the designated Liaison/Developer between Engineering and IT. A good understanding of your users is the first step and your attitude and ability to listen to your users and stay the course with IT and lots of on going acceptance. Good job and I have forwarded your well done overview to others who need it ! Sgt Dave
I really like the video and you're explaining the technical concept very nicely. But .. it contributes to the confusion that BDD is 'just' the writing in Gherkin style; BDD is way more than that. In BDD you want all disciplines (traditionally analyst, developer, tester) to interview the requestors on what they actually want. The 3 amigo sessions. Due to their own daily work, they have different viewpoints and ask different kind of questions and trigger each other to the next questions. This helps to get a way better picture of the Why and What of the desired features. With that come the use cases and with that you have the gherkin style to also automating (acceptance) tests in advance. Maybe if you like to make an extended version :-)
Thank you Mark, your videos are cutting edge and give us a framework of what else to study related to the subject. They are an excellent introduction into an entirely new philosophy.
How is software quality guaranteed with this approach? I imagine there are scenarios where an application's behavior may be correct, but the quality of the code may still be suboptimal. Are additional practices such as peer reviews needed to prevent long-term problems?
The approach lends itself well to pair programming which is basically real-time peer reviews. But the big benefit you may be overlooking is that when you can quickly prove that the application does what it is supposed to do, developers are much more free to fix things as they go. A good portion of what developers do on existing systems without tests is try to figure out how to make a change with minimal risk of breaking something. Often times the way that has the least risk of breaking something is what pushes toward poorly designed code. When developers have the freedom to refactor, the code tends to stay higher quality.
I liked the video and I really thank you for your informative video in such a attractive and awesome way. Please keep posting other videos related to Software engineering .. Keep up the good work.
in my experience bdd can bring a product out faster, with less fuss. with careful coding and understanding if the requirements it can beat tdd in almost every ground. of course, this in only in the context of the domain im in.
When exactly do we need to use BDD. In an agile methodology, where does it fall? I completely understand it benefits, but I need to understand that when does it come in picture?
When someone announces they have capacity to start on the next story, the next step should be to meet to write examples of what it means for that story to be complete using BDD. At least that is where I've seen it work for teams that have been successful with it.
@@MarkShead Thank you for your reply. So one can either go in the traditional way of completing the user story(first the developer developing the system and then the tester testing it out) or a tester could write the scripts using gherkin and try to complete the requirement. If the second scenario is correct, what does the developer do, does their role comes into picture when the tc's through cucumber are run, meaning the whole concept of BDD is just to streamline how the system has to be developed in a more efficient way.
@@aadilsiddiqui89 Behavior Driven Development is where you take the user story and get the developer, tester, and business together to create examples before you start writing the code. Then the developer makes the examples executable and uses that to drive the development process.
They work well together, but using TDD doesn't require BDD and using BDD doesn't require TDD. Your chart makes sense and you can also say that TDD is usually more about defining methods and making sure they work while BDD is more about defining business requirements and making sure they work.
@@leeamraa I assume you are talking about the stories that look like: As a web user I want to change my email address So I can keep it up to date Making these more refined still won't allow you to make them executable because they aren't setup in a format for executing and they aren't examples. To make an executable example you need: 1. the state the world needs to be in, 2. the action that you are trying to give an example of, 3. the resulting state that you want to confirm. No matter how "refined" you make the As a, I want, So I can, stories, it isn't going to make a very good example that you can actually execute. That is where the BDD style of giving examples is helpful because they can be made executable. And by "make them executable" I mean make them where they will actually run against the code. Does that make sense?
The difference is that you actually write code that makes each line executable and the Cucumber framework runs it on every build and gives you feedback on what passed and if there are any errors. So kind of like TDD, but everything is tied back to what the customer asked for.
You hit the mark exactly. This same type of thinking I used for over 15 years working for a major So Calif Utility Company. Since I had previous engineering design experience combined with my computer background I was usually the designated Liaison/Developer between Engineering and IT. A good understanding of your users is the first step and your attitude and ability to listen to your users and stay the course with IT and lots of on going acceptance. Good job and I have forwarded your well done overview to others who need it ! Sgt Dave
Thanks for good explanation and animation.
I really like the video and you're explaining the technical concept very nicely. But .. it contributes to the confusion that BDD is 'just' the writing in Gherkin style; BDD is way more than that.
In BDD you want all disciplines (traditionally analyst, developer, tester) to interview the requestors on what they actually want. The 3 amigo sessions. Due to their own daily work, they have different viewpoints and ask different kind of questions and trigger each other to the next questions. This helps to get a way better picture of the Why and What of the desired features. With that come the use cases and with that you have the gherkin style to also automating (acceptance) tests in advance. Maybe if you like to make an extended version :-)
Thank you Mark, I've just read about it in a book, but this explanation kind of clear my mind about how does it works in real life...
Thank you for taking the time to comment. I'm glad it was useful!
Thank you Mark, your videos are cutting edge and give us a framework of what else to study related to the subject. They are an excellent introduction into an entirely new philosophy.
I'm glad it was useful. Thanks for taking the time to comment.
The video is very useful, thanks for the explanation and for highlighting the differnece between the TDD and BDD aproaches.
Thank you Mark for you great explaination. WE need more contents like that.
Thanks Mark, I think I got the idea more into a fully version to explain it with more of an "normal language".
Greetings!
Great explanation and simplification to ease understanding. Great job
Fantastic job on the animation.. seriously..
Hi Mark, how did you create your animations? I find them to be very helpful. Thanks for putting this together.
Super cool explanation
Excellent explainer videos. Thank you
Nice Presentation. Please continue with your great work...!!!.
How is software quality guaranteed with this approach? I imagine there are scenarios where an application's behavior may be correct, but the quality of the code may still be suboptimal. Are additional practices such as peer reviews needed to prevent long-term problems?
The approach lends itself well to pair programming which is basically real-time peer reviews.
But the big benefit you may be overlooking is that when you can quickly prove that the application does what it is supposed to do, developers are much more free to fix things as they go. A good portion of what developers do on existing systems without tests is try to figure out how to make a change with minimal risk of breaking something. Often times the way that has the least risk of breaking something is what pushes toward poorly designed code. When developers have the freedom to refactor, the code tends to stay higher quality.
simple and easier to understand.
I liked the video and I really thank you for your informative video in such a attractive and awesome way. Please keep posting other videos related to Software engineering .. Keep up the good work.
Great Video. Love the animations.
Best explanation 🙌
in my experience bdd can bring a product out faster, with less fuss. with careful coding and understanding if the requirements it can beat tdd in almost every ground. of course, this in only in the context of the domain im in.
Thanks mark 😄
When exactly do we need to use BDD. In an agile methodology, where does it fall? I completely understand it benefits, but I need to understand that when does it come in picture?
When someone announces they have capacity to start on the next story, the next step should be to meet to write examples of what it means for that story to be complete using BDD. At least that is where I've seen it work for teams that have been successful with it.
@@MarkShead Thank you for your reply. So one can either go in the traditional way of completing the user story(first the developer developing the system and then the tester testing it out) or a tester could write the scripts using gherkin and try to complete the requirement.
If the second scenario is correct, what does the developer do, does their role comes into picture when the tc's through cucumber are run, meaning the whole concept of BDD is just to streamline how the system has to be developed in a more efficient way.
@@aadilsiddiqui89 Behavior Driven Development is where you take the user story and get the developer, tester, and business together to create examples before you start writing the code. Then the developer makes the examples executable and uses that to drive the development process.
excellent
simple & informative thank u
So TDD and BDD can be used separately? As in they are not a technique in the same space?
TDD -> Development
BDD -> Feature?
They work well together, but using TDD doesn't require BDD and using BDD doesn't require TDD. Your chart makes sense and you can also say that TDD is usually more about defining methods and making sure they work while BDD is more about defining business requirements and making sure they work.
so you have half of the minute to JUST celebrate BDD?
Well we were pretty excited about it. :)
Cool!) thanks
how this is different than "user stories" in agile?! who, what and why template.
User stories are not executable. They also aren't granular enough to make executable.
@@MarkShead : if this is the only difference then, just make user stories more refined.
@@leeamraa I assume you are talking about the stories that look like:
As a web user
I want to change my email address
So I can keep it up to date
Making these more refined still won't allow you to make them executable because they aren't setup in a format for executing and they aren't examples. To make an executable example you need: 1. the state the world needs to be in, 2. the action that you are trying to give an example of, 3. the resulting state that you want to confirm.
No matter how "refined" you make the As a, I want, So I can, stories, it isn't going to make a very good example that you can actually execute. That is where the BDD style of giving examples is helpful because they can be made executable.
And by "make them executable" I mean make them where they will actually run against the code.
Does that make sense?
@@MarkShead : let me watch the video more carefully and see.
@@MarkShead : I see the difference now. Thanks.
Very Good !. Why not translate another languages ?!
Which languages would you like to see?
yayyy
I don't understand how this is is anything new. Using words in a structured format to explain functionality is not new. What am I no getting?
The difference is that you actually write code that makes each line executable and the Cucumber framework runs it on every build and gives you feedback on what passed and if there are any errors. So kind of like TDD, but everything is tied back to what the customer asked for.
another bullshit. it's just how it should work, now, they spent a lot time to make a word BDD to look fancy. what a bullshit
ofcorse