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.
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.
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 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.
Our mission to helping our customers - large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development and testing lifecycles, so as to decrease the time to market and increase return on investment.
At Inflectra, we are fully committed to provide our customers with the very best products and customer service. We believe in going the extra mile to ensure that each customer is satisfied with our software products. We have the experience and the commitment to deliver the products customers need to deliver their projects and assure quality every step of the way. (Learn More)
We are so confident that you will be fully satisfied with our products that we offer a 30-day, unconditional, money back guarantee! (Learn More)