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
@wilfredderksen2 жыл бұрын
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 :-)
@cleberneri17546 жыл бұрын
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...
@MarkShead6 жыл бұрын
Thank you for taking the time to comment. I'm glad it was useful!
@kacpercencelewski722211 ай бұрын
Thanks for good explanation and animation.
@TheDudeWithSome4096 жыл бұрын
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.
@MarkShead6 жыл бұрын
I'm glad it was useful. Thanks for taking the time to comment.
@NguyenNguyen-ly2yt2 жыл бұрын
Thank you Mark for you great explaination. WE need more contents like that.
@yazanal-tamimi11454 жыл бұрын
The video is very useful, thanks for the explanation and for highlighting the differnece between the TDD and BDD aproaches.
@1993eML2 жыл бұрын
Thanks Mark, I think I got the idea more into a fully version to explain it with more of an "normal language". Greetings!
@LuisBlancoAustin3 жыл бұрын
Hi Mark, how did you create your animations? I find them to be very helpful. Thanks for putting this together.
@gggg-rf8en3 жыл бұрын
Great explanation and simplification to ease understanding. Great job
@michellegabrielle2026 Жыл бұрын
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 Жыл бұрын
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.
@warriorfb20102 жыл бұрын
Fantastic job on the animation.. seriously..
@leonsky64333 жыл бұрын
Super cool explanation
@richardhaw97572 жыл бұрын
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.
@madirajuchaitanya4 жыл бұрын
Nice Presentation. Please continue with your great work...!!!.
@phildevry21295 жыл бұрын
Great Video. Love the animations.
@aadilsiddiqui892 жыл бұрын
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?
@MarkShead2 жыл бұрын
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.
@aadilsiddiqui892 жыл бұрын
@@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.
@MarkShead2 жыл бұрын
@@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.
@jaber_courses5 жыл бұрын
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.
@suryark2 жыл бұрын
simple and easier to understand.
@lissau33 жыл бұрын
Excellent explainer videos. Thank you
@GiggityGlen3 жыл бұрын
Best explanation 🙌
@limychelseafc4 жыл бұрын
So TDD and BDD can be used separately? As in they are not a technique in the same space? TDD -> Development BDD -> Feature?
@MarkShead4 жыл бұрын
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.
@MariemMili Жыл бұрын
Thanks mark 😄
@leeamraa5 жыл бұрын
how this is different than "user stories" in agile?! who, what and why template.
@MarkShead5 жыл бұрын
User stories are not executable. They also aren't granular enough to make executable.
@leeamraa5 жыл бұрын
@@MarkShead : if this is the only difference then, just make user stories more refined.
@MarkShead5 жыл бұрын
@@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?
@leeamraa5 жыл бұрын
@@MarkShead : let me watch the video more carefully and see.
@leeamraa5 жыл бұрын
@@MarkShead : I see the difference now. Thanks.
@soniyakc93545 жыл бұрын
simple & informative thank u
@buweiliao3 жыл бұрын
so you have half of the minute to JUST celebrate BDD?
@MarkShead3 жыл бұрын
Well we were pretty excited about it. :)
@sharmarahul17 Жыл бұрын
excellent
@Ricky387004 жыл бұрын
Very Good !. Why not translate another languages ?!
@MarkShead4 жыл бұрын
Which languages would you like to see?
@Mel0nMauler4 жыл бұрын
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?
@MarkShead4 жыл бұрын
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.
@geekaffairs64753 жыл бұрын
yayyy
@澳贼4 жыл бұрын
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