Exploring TDD’s Role in Software Quality Assurance

In this lesson, we’ll take a critical look at what TDD has brought to the testing table, and what remains human activities. While TDD undoubtedly has advantages as part of a test strategy, it can never be the entire strategy for a successful software system.

Understanding the limits of TDD

TDD is a relatively recent discipline as far as mainstream development goes. The modern genesis of TDD lies with Kent Beck in the Chrysler Comprehensive Compensation System. The project began in 1993, and Kent Beck’s involvement commenced in 1996.

The genesis of TDD

The Chrysler Comprehensive Compensation project was characterized by extensive use of unit tests driving small iterations and frequent releases of code. Hopefully, we recognize those ideas from the preceding chapters in this course. Much has changed since then—the deployment options are different, the number of users has increased, and agile approaches are more common—but the goals of testing remain the same. Those goals are to drive out correct, well-engineered code and ultimately satisfy users.

Human-driven testing

The alternative to test automation is to run tests without automation, in other words, run them manually. A better term might be human-driven. Before test automation became commonplace, an important part of any development plan was a test strategy document. These lengthy documents defined when testing would be done, how it would be done, and who would be doing that testing.

This strategy document existed alongside detailed test plans. These would also be written documents, describing each test to be performed—how it would be set up, what steps exactly were to be tested, and what the expected results should be. The traditional waterfall-style project would spend a lot of time defining these documents. In some ways, these documents were similar to our TDD test code, only written on paper, rather than source code.