We need more automated tests
During the end of the the 20th century, IBM had a TV commercial that I’m quite fond of. I can’t find it on YouTube, but its quite short. There are two suites talking, one reading a magazine. The one with the magazine says “We need to be on the Internet”, the other asks, “Why?” the first replies “It doesn’t say”.
I’ve seen this approach applied to Software quality several times now.
Allot of managers are hearing good things about automated tests. This results in allot of in house improvement projects trying to solve the question “How can we get more automated tests”.
The problem is that the question is asked all wrong. What the question really should be is “How do we improve software quality?”.
The end result might as well be more automated tests. But if you have a team of developers whom have never worked with testing. Your product isn’t going to be testable, and they will need allot of help. Help to set them up, but first and foremost help to understand why it is important to, not test but, to produce High Quality working software.
Most developers do not believe that there is a problem with their quality of the software. Without getting the team to think about software quality while their working, automated testing will take a long time to get in place. Above all the investment on automated tests will have a longer Return of Investment.
Now automated tests might be a part of the end solution for improving the quality of software, but getting the discussion about software quality going in a well behaved manner can have so much more Return of Investment.
I think you should start with asking how you define quality. Is quality running code, changeable software or what?
One of the reasons for developers not seeing a problem with their code is that it works. There and then. Their concept of quality in software does not include their future colleague, trying to understand why this old code stopped working. Legacy code is always someone else’s code.
But does managers want to pay for that decreased cost in development? That might be a cost which affects the company in five or ten years when he plan to be far away in the hierarchy. Perhaps the whole program has been changed by then. Who knows?
Automated tests has perhaps is some minds become just like all those other buzz words. You want to say you have it. But you don’t know why and you are not really up to paying for it. Like those guys on the bench. Immature software development leaders of course fall into this trap and start whining about metrics they don’t understand (code coverage, for example) and don’t, like you point out, have a good idea about what they mean with quality.