Unit test benefits from the management perspective
I'm new in this forum, and I thought I would start with asking a bit of a complicated question.
Imagine the following situation: management has invested in a project to educate the developers, so that they unit test their software and start moving towards test-driven development (working close with the QA team). The project went through, the developers are writing unit tests in all the new projects (not the old ones), the QA team gets coverage and code quality metrics and everyone is happy. But the project has cost an enormous amount of money, and management wants numbers to make sure they got their money's worth.
How do you quantify (in dollars, if possible) the benefits of introducing unit testing into the company's development process? There are no comparison metrics to reach for, as all the projects using unit tests now are brand new, and the closest to measures we have been able to come up with is to aproximate how long it takes for the QA team to work on a bug from the moment it's found until it's closed, put it together with the time to fix a bug from development, and spice it with a "we think there are less bugs of this and this kind released to QA now". But that's not very satisfying for the management people, is it?
So, anybody has a better approach? Thankful for all contributions!
The bitterness of poor Quality remains long after the sweetness of meeting the schedule has been forgotten
Re: Unit test benefits from the management perspective
Your challenge for quantifying benefits would be the standard against which you measure the costs if no unit testing were performed. Let's go the other extreme and pursue test-driven development, where the developer first establishes the testing collateral (say a JUnit framework with test cases to drive the code module yet to be written). This enables the developer to think about the code and imagine what it does with the input data to give the right results. That means when the code gets written it is focused and tested along the way, a virtual no-cost option if you can use an already established framework. It pays off to create such a framework if necessary so long as you make it properly reusable. The unit code will be correct, so the errors that end up in system testing tend to be more integration errors, and easier to find and fix (unit code is often buried an hard to get at using black box testing techniques).
The benefit to management is that the test inputs for the framework can be vetted by the end-users as valid input/output parameters, so that you are more secure in what code you end up writing. That should be sufficient. If you go the cost/benefit route there is always some joker who starts the argument that programmers are paid to write clean code and to not produce errors, so there is no net benefit. You are absolutely correct in your assumption that reducing the number of times you have to send code back for fixing will reduce the cost of development, most sane people will see it has to be beneficial if you can reduce the number of times you need to do that in the course of the completion of a development project.