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, 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.

@MarkShead

5 жыл бұрын

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, 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...

@MarkShead

5 жыл бұрын

Thank you for taking the time to comment. I'm glad it was useful!

Great explanation and simplification to ease understanding. Great job

Great Video. Love the animations.

Nice Presentation. Please continue with your great work...!!!.

Thank you Mark for you great explaination. WE need more contents like that.

Excellent explainer videos. Thank you

Fantastic job on the animation.. seriously..

Thanks Mark, I think I got the idea more into a fully version to explain it with more of an "normal language". Greetings!

Super cool explanation

Hi Mark, how did you create your animations? I find them to be very helpful. Thanks for putting this together.

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.

simple & informative thank u

Best explanation 🙌

Thanks mark 😄

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?

@MarkShead

5 ай бұрын

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.

excellent

Cool!) thanks

simple and easier to understand.

So TDD and BDD can be used separately? As in they are not a technique in the same space? TDD -> Development BDD -> Feature?

@MarkShead

3 жыл бұрын

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.

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?

@MarkShead

2 жыл бұрын

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.

@aadilsiddiqui89

2 жыл бұрын

@@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.

@MarkShead

2 жыл бұрын

@@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.

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.

yayyy

how this is different than "user stories" in agile?! who, what and why template.

@MarkShead

5 жыл бұрын

User stories are not executable. They also aren't granular enough to make executable.

@leeamraa

5 жыл бұрын

@@MarkShead : if this is the only difference then, just make user stories more refined.

@MarkShead

5 жыл бұрын

@@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?

@leeamraa

5 жыл бұрын

@@MarkShead : let me watch the video more carefully and see.

@leeamraa

5 жыл бұрын

@@MarkShead : I see the difference now. Thanks.

Very Good !. Why not translate another languages ?!

@MarkShead

4 жыл бұрын

Which languages would you like to see?

so you have half of the minute to JUST celebrate BDD?

@MarkShead

3 жыл бұрын

Well we were pretty excited about it. :)

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?

@MarkShead

3 жыл бұрын

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

@redhotbits

3 жыл бұрын

ofcorse