Getting management approval to invest more in unit testing

Question

I'm a big proponent of unit testing (I'd love to be involved in test driven development). The company I work for seems rather reluctant to spend much effort beyond largely manual end user testing towards the end of development cycles. We have a fairly large solution that has been under development for a couple of years, and I FINALLY got approval to work on an initial unit test suite.

I'd like to be as successful as possible in this effort and convince management to invest more in this area.

What have you done to help justify more unit testing investment, in terms of measured results or other data? Bug tracking results will help, but looking for additional ideas.

Answer 1

IMHO, you shouldn't be in a position where you have to justify your coding methodology. If you are more comfortable with TDD, you should do it.

As far as I know, you are not working in an assembly line where all the processes and movements are calculated and optimized. Your task has plenty of room for initiatives such as the ones your describe.

In fact, it's what I expect from my employees.

But if you really want to justify yourself, S.Lott provided you with two existing question (1 2) in the question comments that contains some arguments for your justification.

Answer 2

If you want to show ROI to management, do not unit test, unless you suspect certain specific units of being defective. Instead, test features, aka use-cases, aka scenarios, that will actually occur when the software is being used in the field. The ROI from these is threefold:

1. it catches bugs that are likely to be encountered in actual use, clearly preventing far more expensive maintenance and support issues. [see below]

2. it automates some or all of the acceptance-testing process, which saves considerable time and manpower

3. it illustrates how the components of the software are supposed to be used and are supposed to interact, which makes it much easier for new developers to understand the software system, thus saving time and money on training

I am not a fan of blind unit testing except for the most exacting of software projects. 100% code coverage may be conforting, but it may provide no significant ROI in a practical sense. I'm a big fan of TDD-style feature testing - it is easy for management to comprehend the impact of "if the user enters 1000 in the Crisis field, selects Travesty from the menu, and then clicks the Exponential button, we get an integer overflow error in the database update code", than it would be for him/her to imagine why anyone would care that "uspCrisisManagementFieldPlacementCalculator cannot handle input values over 999 in certain operational modes". It may be the case that the correct way to fix this particular problem is to disallow values greater than 999 in the Crisis field, depending on exactly what your application is supposed to do. In other words, mere unit testing runs the risk of testing things that cannot happen and also of generating "fixes" that ignore the actual context of use. Striving for 100% code coverage, as is often lofted about as a goal of unit testing, may waste serious amounts of time and money, both by testing things that cannot actually happen in practice, and by encouraging fixes and scope creep that do not consider the context of use.