BDD/TDD vs JAD? [closed]

Question

I've been proposing that my workplace implement Behavior-Driven-Development, by writing high-level specifications in a scenario format, and in such a way that one could imagine writing a test for it.

I do know that working against testable specifications tends to increase developer productivity. And I can already think of several examples where this would be the case on our own project.

However it's difficult to demonstrate the value of this to the business.

This is because we already have a Joint Application Development (JAD) process in place, in which developers, management, user-experience and testers all get together to agree on a common set of requirements.

So, they ask, why should developers work against the test-cases created by testers? These are for verification and are based on the higher-level specs created by the UX team, which the developers currently work off.

This, they say, is sufficient for developers and there's no need to change how the specs are written.

They seem to have a point.

What is the actual benefit of BDD/TDD, if you already have a test-team who's test cases are fully compatible with the higher-level specs currently given to the developers?

Roybn

Answer 1

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

What is happening in your situation that you think this would improve?

The main benefit of BDD is in improving communication between stakeholders and developers.

If you're producing code that fails these verification tests, then the developers have understood your spec differently from the testers, which means the specification lacks clarity and BDD could definitely improve the situation.

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

Sulfathiazole

Or he could employ context specification framework's like MSpec instead of TDD. Get into the mindset of BDD and the English language reports it produces. If people see unit test reports and wish they had such expressive reports for their higher-level tests, you may just sell them BDD that way. – Sears

Yeah totally agree. I used MSpec as an example of one such tool that I am familiar with. If you work with ruby, you get a lot of community support with RSpec compared to MSpec in .NEt. – Sears

Answer 2

This is an excellent question, infact it's the "bottom line" question when it comes to BDD. One of the major challenges of TDD or writing unit-test is that developers never seems get the bigger picture and business perspective of things. The excercise of writing the specs and generating units tests to test the actual 'business' scenarios helps developets raise above their 'craftsmanship' and grasp the business perspective. Check out this post on for more details,

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

Meza

Answer 3

It might help to think of BDD in its lightest form; as discussions around particular scenarios.

You've got your use cases. You've got your requirements. Now you want to verify that you've got a really good understanding of those. So someone - maybe a developer, maybe a tester - says, "Okay. Just to verify that I understand... given that we start with <this>, when a user does <this> then <this> should happen. Is that right?"

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

Then the UX or analyst says, "Well, it's right unless <this other context exists>".

By having discussions around the scenarios, the time taken to ensure that everyone has a common understanding is cut down drastically. We normally gloss over the obvious scenarios and focus on the edge-cases; on new domain terms, concepts which differ between departments, difficult interactions with legacy systems.

The developers don't really work off of the test-cases. They work from requirements and acceptance criteria in exactly the same way that they always do. The test-cases just become an example of the kind of thing they might expect; scenarios in which users get to benefit from, or pass on, the value of the system. Automating those test-cases can be useful because the effort of testing increases roughly proportionally to the size of the code-base.

BDD works best in projects where there's high uncertainty around the requirements or the domain, and people's understanding differs greatly. If your project works already then stick with it. Maybe you could have a look at where the biggest gap between coming up with ideas and implementing them is, and if BDD helps you in that space, use it; otherwise pick something else. What you're doing sounds very similar to BDD processes anyway.

Churchwarden

Answer 4

I just came across this question and thought I'd weigh in because it really is a very interesting question.

The methodology is only broken if the entire team feels it's broken, and if the end result is a failed project.

If the present system works well, then you really need to ask yourself, "can I work like this, even though I might prefer to BDD/TDD?". If your answer is no, and you feel you might be unhappy working to any other system, then perhaps that indicates that your career needs to move elsewhere. If yes, then embrace the system.

Actually, if it were me I'd embrace a new system anyway. For one, if gives you a chance to become intimately familiar with it, and that would then allow you time to make a more informed judgement about the relative pros and cons, and with that knowledge you could suggest possible improvements at some later date if they were necessary.

At the end of the day, a methodology is only as good as it's end result. Working software, and the satisfaction of all of the stakeholders.

:-)

Amando