Three Key Strategies for Supporting Test Driven Design

Test Driven Design

The adoption of agile development is clearly on the rise and with it comes–at least the consideration for–Test Driven Design (TDD). Although the decision to embrace TDD in your development strategy is independent of the decision to adopt an agile methodology for execution, TDD's popularity was encased in the agile movement of the 1990s. So if you're practicing TDD, you're likely working within some sort of agile methodology. Why does this matter to you, the business analyst? Because you're the critical link between the end users and the developers. And if your developers are taking a TDD approach to developing, you'd best take a TDD approach to writing the functional requirements. Here are three key strategies to keep in mind.

Strategy #1: Understand Unit Testing in a TDD Environment

In TDD, your developers write unit tests before they write executable code. It may seem a bit odd at first, but that’s how it works. Imagine part of what your new data system will do is lift and shift some data from a legacy system. You’d be forgiven if you thought the developer responsible for this piece of code would start by writing a load script, but that’s not how it works in TDD. In TDD, your developer would start by writing a test script that would likely load a test source system with some known data, call the (nonexistent) load script, and then assert that the data made it over properly to its destination. Of course, this test script will fail when first run–that’s the point. It’s the developer’s job now to make the test pass. That’s the essence of TDD.

Strategy #2: Get Serious with Functional Assertions

Functional assertions are statements about the functionality that must hold true when the system is working properly. In the same way developers write assertions in their unit tests to drive the development of their code, the business analyst should write assertions about the functionality to drive the overall design of your new data system. This puts an additional burden on you when writing the functional requirements document; however, it's consistent with what your developers are doing and it makes their job much easier. You can start by documenting your functional assertions in the functional requirements document, but I suggest you take it a step further. I suggest you code system tests with assertions (or grab a developer to help you) before the design starts.

Strategy #3: Take One Functional Step at a Time

If you're on an agile project, embrace the spirit of agility and start small. You shouldn't write the whole functional requirements document in one sitting–that would be a waterfall approach. Instead, just document one small piece of functionality that will add value to the end users. For your first iteration, keep the functional scope exceptionally small to balance the exceptionally large amount of technical challenges you should expect to face. Remember, a step only counts if it actually puts your end users in a better place than where they are today. Our staging example earlier wouldn't meet these standards–users can't do anything with staged data. Learn how to break a data system down into small, valuable chunks. It's not always easy, but it's the best skill you can learn as a business analyst.

Conclusion

Test Driven Design feels awkward at first, but after you get used to it, it's hard to go back. And although it may seem like something only the developers need to care about, there's a very valuable role and responsibility in TDD for the business analyst. Take some time to really understand how unit tests work in a TDD environment and extended these ideas into your world with functional assertions that lead data system architecture and design. Your developers will appreciate you for it and you'll end up with a much better data system.