Kicking Off Regression Testing

3916110518_ff3401ba71

What do you do if you are stuck with legacy code and you want to start doing regression testing? A good friend of mine asked me this exact question yesterday and I think my answer to him might be of interest to others, too.

The biggest problem when introducing regression testing is that usually the benefits of testing are accruing only slowly, while the pain of writing functional and unit tests is felt immediately. If developers themselves are not motivated to do regression testing (e.g., if they are forced to do it by the management), the initiative will work for some time, but the moment the manager starts looking away the developers will regress to their old ways. Only if regression testing becomes a part of company culture it has a chance to survive in the long run.

In my opinion the most effective tool an engineering manager has at his disposal for introducing changes in development practices are code reviews. This is even more so in the case of introduction of regression testing. While the manager could set rules that all new code must be unittested, or that all resolved bugs should also have a regression test written, or even dedicate time to write tests for legacy code, he will not instill the value of tested code in his development organization. The moment some important project or deadline will occur, it will be the manager himself who will be the first to relax the requirements on regression testing. Only if developers hold each other accountable thru code review does regression testing stand a chance.

My friend was not particularly satisfied with my answer. He doesn't see any option that they could introduce code reviews in their organization. I guess will have to discuss this issue soon, while having a beer or two.

Enhanced by Zemanta