BDD / TDD vs JAD?

Question

I suggest that my workplace implement Behavior-Driven-Development by writing high-level specifications in a script format and so that a test can be written for it.

I know that working with test specifications tends to increase developer productivity . And I'm already thinking of a few examples where this will take place in our own project.

However, it is difficult to demonstrate the value of this for business.

This is because we already have a collaborative application development (JAD) process in which developers, managers, users, and testers come together to agree on a common set of requirements.

So they ask, why should developers work against test cases created by testers? They are intended for verification and are based on higher-level specifications created by the UX team that the developers are currently working on.

This, they said, is enough for developers, and there is no need to change the way they write specifications.

They seem to have a point.

What is the actual benefit of BDD / TDD if you already have a test team whose test cases are fully compatible with the higher-level specifications that are currently provided to developers?

Answer 1

If you want to convince them that this will help, the main thing you need to do is identify the problem that it will solve.

What happens in your situation when you think it will improve?

The main advantage of BDD is the improved interaction between stakeholders and developers.

If you create code that fails these tests, the developers understood your specification differently than testers, which means that the specification is not clear, and BDD can definitely improve the situation.

There are also parts of the process that, as a developer, you can work without changing the entire team process. If you focus on the unit testing level and do traditional test development, it can make you more productive.

Answer 2

This is a great question, remind him of the "bottom line" of the question when it comes to BDD. One of the main problems with TDD or unit-test writing is that developers never think they have a big picture and business perspective. Exercise writing specifications and unit tests to test real "business scenarios" helps developers to increase their "mastery" level and understand business prospects. For more information, visit this post,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 3

This can help think of BDD in its easiest form; like discussions around specific scenarios.

You have your use cases. You have your own requirements. Now you want to make sure that you have a good understanding of these. So someone, maybe a developer, maybe a tester, says: "Okay, just to make sure I understand ... given that we start with <this> when the user does <this> then <this> Is it correct?"

And the tester will say: "Yes, that's right."

Then the UX or analyst says: "Well, that’s right, unless that other context exists>."

Speaking of scenarios, the time taken to provide a universal understanding has been drastically reduced. Usually we smooth out obvious scenarios and focus on the edges; on new domain terms, concepts that differ between departments, complex interaction with outdated systems.

Developers really do not work with test cases. They work on the requirements and acceptance criteria in the same way as always. Tests simply become an example of what they can expect; Scenarios in which users benefit from or transfer system value. Automating these test cases can be useful, as the testing effort increases in proportion to the size of the code base.

BDD works best in projects where there is high uncertainty around the requirements or domain, and people's understanding is very different. If your project already works, then stick to it. Maybe you could see where the biggest gap is between ideas and their implementation, and if BDD helps you in this space, use it; otherwise select something else. What you do is very similar to BDD processes.

Answer 4

I just stumbled upon this question and thought that I would weigh it, because it is really a very interesting question.

A methodology is destroyed only if the whole team considers it to be broken, and the end result is a failed project.

If the present system works well, then you really need to ask yourself: "Can I work this way even if I prefer BDD / TDD?". If your answer is no, and you feel that you may be unhappy with work in any other system, perhaps this indicates that your career should move elsewhere. If so, hug the system.

Actually, if it were me, I would have adopted a new system. Firstly, if you give you the opportunity to get to know him closely, and this will give you time to make a more informed judgment about the relative pros and cons, and with this knowledge you could suggest possible improvements at a later date, if necessary .

At the end of the day, the methodology is only good, as is its end result. Working software and the satisfaction of all interested parties.

:-)