If a project getting difficulties with writing requirements, there is Test Driven Development (TDD) often referred to as the solution. Is that really the solution? If so, why TDD has not really become widely accepted in the software development up to now? In this blog I will express my thoughts about this topic.

Test Driven Development (TDD) – What is it?

TDD was developed in the early 2000 by Kent Beck and Ron Jeffries in a project at Chrysler. In TDD, the test is put into the centre, not the source code. These means tests are developed first – before the source code is written. The source code development is only finished when the test is “Passed”. The idea is, that the test replaces the typical requirements. The test is something like an executable requirement. The acceptance criteria of the source code are the test.
Wikipedia lists the following advantages of TDD:

• Boolean metric for compliance with the requirements: Test is Passed or Failed
• It can be tested without great expenditure of time hence the programmers work most of the time in a correct system.
• The stock of unit tests documents the system. These tests represent an executable specification.
• A test-driven approach results in the tendency to program code is more modularized.

Test Driven Development (TDD) – Challenges!

I find the idea behind TDD very good! Anyway it is also true that TDD is not used in the majority of the software projects. The reason is, that the core idea behind TDD is far too radical. Much more promising are evolutionary approaches.
If you look at the last 20 years of software development, then you recognise that testing has been viewed almost continuously as burdensome, expensive, poor quality and ineffective. The testing did not come out of this negative view until today. TDD puts this “unloved child” of software development in the centre of the development process. This is radical! On the other hand the software projects  do not accept this approach.
A significant drawback of TDD is the relatively high cost, which must be plugged into the test preparation. In the normal development of the source code is improved in many iterative steps. Most of this effort needs to be put into change of tests if TDD is applied.
Secondly, having no requirements in TDD does cause the following problems:

• The traceability to the customer requirements can not be set up.
• The detailed purpose of the software can not be identified.

Moreover, it is doubtful whether TDD saves really development costs. Also no real reason can be identified, why TDD should shorten the development time. Last, but not least, a higher product quality is not necessarily guaranteed by TDD.

Reviews are the solution!

From my perspective, consistent review of requirements (especially in the early phases of the project) is an almost ideal approach to achieve the objectives of TDD. The most important checklist point for the review is, whether the requirement is verifiable. Also it should be asked for the verification strategy. The implementation/product development is only started if satisfactory answers have been found to these questions.
The advantage is that requirements reviews are much faster and cheaper than corresponding tests.
Source code reviews are a second mean, to ensure the correct implementation of requirements in a very effective way.
The advantages of this approach towards TDD are obvious:

• Lower costs, with the same quality
• Requirements reviews and code reviews are in principle well known in today’s development process and make no revolution in the development. The awareness of the power of this method in software engineering is more of an evolution.

Conclusion:

The requirements and source code reviews should no longer be seen as a necessary evil to process satisfaction. Reviews are a very efficient and effective step in software development, if they are probably applied. However, the employees must obtain the necessary social and technical competence to be able to benefit from the power of these techniques.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.