BDD/TDD vs JAD?

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?

Answer 1

You're probably getting push-back because you are viewing (and therefore communicating to your team) the two as mutually exclusive, and they aren't.

What you have in place is a good model. It would be a mistake to "abandon" something that works. Fortunately TDD is just about when the test specifications are written. It doesn't mean the testers write the product specs.

If you want to do TDD, your product specs should be written the same way they are now. Then the testers should write test cases according to these specs. Then your developers develop passing code for these test cases (they don't need to be blind to the product specs - while your team is new to it, your test cases may not be sufficient to help illustrate the product specs).

This shouldn't feel uncomfortable to your team at all. In fact, it should give management and your UX team more comfort - 1) knowing first that their specs have been validated and make sense in testable scenarios before code had to be written, and 2) knowing that the code that is written is actually well tested. (Advantages to this already answered).

I worked for several years on a team that had the exact process you describe (what you called JAD), and gradually added TDD, and for us combining the two concepts was definitely the best approach.

Answer 2

TDD has little to do with QA testing or creating specifications. TDD is a programming process style that narrows focus on what and how to develop, given a spec. The end result is 'just enough' code to pass a test. This ensures two things. First that your application is 100% tested to the specs as the developers understand them. Second, and more importantly, with that set of unit tests you can now refactor with confidence when working on the next thing.

QA is as much about making sure the system does what users expect as it is about making sure the code is bug-free.

Answer 3

Honestly, I feel like these multi-lettered acronyms simple describe a specific sub-set of the entire development process. It is nice that are formalized so that they can be talked about, but the reality in my opinion is that successful software organizations implement some hybrid of all of them. Though, I think formal implementations of JAD are garbage as design by committee is unproductive. It certainly would not work in larger organizations.

To answer your question more specifically, I think there is a lot room for misunderstanding in functional requirement documents. Specifically on the management side. We counter act this by having two components in our requirements documents.

1. High level requirements implemented in plain English that are often none detail specific. The specifically describe typical use cases. Requirements written in this fashion tend to more digestible by none technical types such as sales or marketing. I would call this BDD
2. Functional requirements. These are explicitly defined requirements that can be tested against. Typically, our QA department and some times support are the target audiences for these. I would call this TDD.

So if had to pitch the case for BDD, I would argue that it limits the possibility that "management" misunderstands exactly what the product will do.

Answer 4

First questions you should ask yourself:

• Are your company's products selling?
• Are your customers satisfied?
• Is the product profitable?

If you can answer "more or less yes" (or better) to those questions, then I hope you can understand why there's little enthusiasm for rocking the boat. If it ain't broke... as the saying goes.

That said, if you are still bound and determined to make a case, then focus on determining exactly how the define -> design -> build -> test loop gets closed within your current system. Meaning, when do the people who write the high level specs verify that the system behaves according to what they wrote?

If the answer is: "that's the job of the test team", then you potentially have something around which you can make your case because the loop isn't being being closed. And even if the process states that the original spec writers must perform "acceptance testing", make sure that this is actually done.

BDD is about closing the development loop by reducing communication impedance between definers and implementers via clearly structured mechanisms for capturing requirements.

That's your argument in a nutshell, if it's necessary.

The bonus is that you can also show them the "shiny toys" that have been produced by the BDD world (e.g. Cucumber/Gherkin) which you can then use to demonstrate the benefits of automating the process (i.e. reduced mis-communication, increased productivity, increased test-suite maintainability, etc...).

(BTW. When I say BDD, I mean BDD/TDD as they're two sides of the same coin, imho. Where BDD is focused on black-box testing and TDD is focused on white-box testing.)

Answer 5

So, they ask, why should developers work against the test-cases created by testers?

Great question. TDD doesn't suggest that the test cases be written by testers. The fact that you're folks are suggesting it indicates that all y'all aren't comfortable with TDD and are inserting extra steps in the process.

Their question points up something important about TDD.

Testers don't write all the tests. Indeed, they shouldn't write many of the tests. Some folks say they shouldn't write any tests.

[Tests] are for verification and are based on the higher-level specs created by the UX team, which ... is sufficient for developers

Yes, but.

Those "higher-level specs created by the UX team" aren't always the best description of a system. That claim -- "[Tests] ... are based on the higher-level specs created by the UX" -- is suspicious and often wrong.

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?

That involves a false assumption, again. Specifically "test cases are fully compatible with the higher-level specs currently given to the developers".

Concept -> JAD -> Specifications -> Tests -> Code

is what you have in place now. Multiple, linear transformation steps. Each step introduces some error.

Concept -> Expected Test Results -> Code

Has fewer transformation steps and fewer errors introduced along the way. The users (or the users with some help from facilitators) can write the test results directly.

I did this for the first time a few years back and it was wildly successful. At first they wanted design documents -- which we all wrote and passed around. But I demanded specific test case results. I created sample test results in spreadsheets. It took a while (weeks actually) but the users eventually corrected my mistakes and sent me hugely expanded spreadsheets. They added necessary clarifications in the form of test cases.

They also wrote notes and comments. A bad habit.

I wrote a little utility to transform the spreadsheets directly into unittest code.

At the end of the first attempted release, the users had numerous complaints and corrections and bugs to fix. There was lots of IT trouble-ticket and status reporting going on. Change control. All that stuff. All largely useless.

We walked through the spreadsheet with the test cases. They fixed the errors in their spreadsheets (there were one or two). They kept trying to explain their notes and comments. I kept asking for examples instead of explanations. Eventually, they started revising and expanded the spreadsheets to cover the bugs and features completely.

Eventually every note and explanatory comment was backed up with a concrete example.

At this point, we -- the users and I -- were doing full TDD. Spreadsheet test cases to unittest code to production code. IT managers were fumbling around with change control documents and specification updates. All that documentation simply described the spreadsheets which had the test cases.

Once that first release was in production, the "Phase 2" requirements were entirely provided as test data on spreadsheets. 100% example-driven. No comments, no notes, no explanations to speak of. IT got out of our way and stopped trying to write English specifications.

Concept -> Expected Results -> Code

That's one benefit of TDD. You didn't ask about refactoring, so I save that long, boring war story for someone else's question.