Agile Myths - Part 4

October 15th, 2014 by inflectra

Today we look at whether test-driven development (TDD) a good technique for specifying how a user story should operate, and whether it means that user story is fully tested (hint: these do not have the same answer!)

In this item we continue our examination of various Agile methodology ideas and ask whether they are valid or whether they are in fact, industry myths.

Myth 4: Test-driven development is a good testing technique.

Addressing the possibility that this statement might be a myth is fairly straight forward, because it’s all about the way the statement is written; specifically the use of the word ‘testing’. The key here is to realize that test-driven development (TTD) is not a testing technique at all, but a development technique and so if we say, “Test-driven development is a good development technique,” then we have something demonstrably true and not a myth.

How Test-driven Development Works

Some might call it pedantic to quibble over whether test-driven development (TTD) is a testing procedure or a development procedure, but getting it wrong can lead to serious consequences. The objective of TTD is to provide the software engineer the clearest possible understanding of success criteria for the code being written. Tests are written before the code and then the developer writes something that will pass those tests. Initially, new code may well fail the test or pass with conditions; perhaps its behavior is awkward or confusing. The code is modified and the tests run again. This is repeated until the tests pass unconditionally. The process is quite straightforward; however treating the code as fully tested at this point would be a mistake. Because the writers of the code work so closely with the writers of the tests, it is possible for them to both make the same incorrect interpretations of user stories or stakeholders needs.

Agile Practices Improve Quality

Agile development practices help reduce the risk of this type of slip-up by advocating the inclusion of the entire team in the interaction with stakeholders. With all eyes on the problem, there is less chance of a coincidental mistake. Even so, we must be aware of the possibility of common mistakes or even the effects of collective or group behavior, which is a relatively well understood phenomenon and could lead to errors. To overcome problems not picked up by anyone in the team, acceptance tests should be written and executed outside the Agile team framework.

So, it may be true that test-driven development provides benefits in the testing domain, but its main objective remains to help produce better, higher quality code and so is more accurately seen as a development technique, or perhaps even a ‘Quality Assurance’ activity.

You may also be interested in:
Testing in Agile Projects: Familiarity Breeds Consent
Testing Lifecycle: Don’t be a fool, use a proper tool.
The Cost of Quality Assurance

Agile Testing Test Driven Development Quality Assurance

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial