Adopting TDD initially can involved overcoming the objections of others in your organization. In this episode, and the next few that follow, we will examine these concerns and how to address them
Adopting TDD initially can involved overcoming the objections of others in your organization. In this episode, and the next few that follow, we will examine these concerns and how to address them
Know the Benefits of Test-Driven Development
If you believe in Test-Driven Development and hope to promote it within your organization, you are likely to run into objections that must be overcome if you are to succeed. Most of these objections are reasonable and should be treated as such. Everything has costs and if you want anyone to embrace something new you have to prove that the value of it is high enough to merit those costs.
This is true in general. I always hold myself to this standard: "I should be able to demonstrate the value of what I am proposing. If I cannot, then maybe I’m wrong." In this tip I will briefly list some of the benefits of TDD (this includes the unit test version that developers engage in, and the acceptance-tests that everyone should participate in writing) and then in subsequent tips I will provide details for each.
1. TDD will speed up the development process. Most people think it will slow you down. I thought so too when I first heard about it. But the truth is that once a team adopts TDD fully they will report a 20% increase in velocity at minimum. My very next tip (next week) will explain why.
2. TDD will capture enterprise knowledge that is otherwise often lost over time. The damage that lost knowledge can do is hard to over-estimate. If done properly, TDD addresses this problem in a way that nothing else I know of can do. I'll explain why this is.
3. TDD improves the quality of your products. Testing up-front forces quality issues to the forefront of all development decisions. Why this is and how it works is interesting and perhaps surprising. I will try to elucidate this in a way that is not overly technical.
4. TDD fundamentally improves communication and collaboration, which in turn ensures alignment of effort with business value. Quite often the software we develop is misaligned with what is actually needed, sometimes fundamentally so. Making the wrong product creates waste even if the quality of that product is high. TDD addresses this in a uniquely concrete way. I'll explain how.
Finally...
5. TDD does not replace traditional testing but it will contribute to it in a myriad of ways. The synergy between up-front testing (TDD) and after-development testing (QA) yields constant value to both processes.
Again, each of these benefits addresses a potential objection and will be the subject of its own "agile tip" in future weeks. If any of you run into objections I am not planning to cover please let me know and I'll do my best to help you out. I constantly learn from all of you, of course.