To me, TDD is like a framework (Backbone, React etc). You can do it well and get a lot of value, and you can do it poorly and it serves no purpose. Ill provide

To me, TDD is like a framework (Backbone, React etc). You can do it well and get a lot of value, and you can do it poorly and it serves no purpose. Ill provide an answer to your question, from a business perspective. The value of TDD when done well is that you are ensuring (to a relatively strong degree, but not perfect) that you don't regress on issues. This isn't something that a human being can do when your system becomes sufficiently large and your introduction of features/deliveries accelerates. For example, if it takes 1 hour for your QA team to 'system test' your application, and you introduce a new feature every day, that consumes a huge volume of resource over the course of a year. You also run the risk of human error, forgetting steps etc. At the end of the year, your QA team now take 4-5 hours per day to 'system test' your application. Its all they are doing all the time. This is pretty demoralising work. If it takes 1 hour for one person to write tests that serve the same purpose. Those tests can run within in much smaller time frames and use far less resources than a manual 'system test'. That is a massive saving to the company as over the course of a year you will save hundreds/thousands of man hours and wont degrade morale. TDD should give you confidence that your application is working as you intend it to be, its a tool and it can be used poorly, but when used well you should see the benefits.