Why is it so difficult to claw back quality ? (III)?
Question:
The system calls for automated regression testing.
The automated testing is never set to work.
Individuals modify the system and make token efforts to test\the modified system.
Quality seems to be falling off.
Doh !
So difficult to reverse the change. (would require acknowledgement that the project had been so badly mismanaged as to allow the original change to the software development methodology)
Answer:
My sincere condolences!
You are right about the difficulty in getting quality back, especially the longer you go without it. Quality is not something that you can easily just tack on at the end, at least for any non-toy project.
Constant (which implies automated) regression testing is a good idea at both the unit and integration levels, meaning for individual classes, and at the level of higher functionality ("use cases" or "features" or just plain old requirements, depending upon your methodology).
Even constant testing is no guarantee of quality, however, especially if you have the same fellows write the tests who were avoiding them in the past. Your confidence in the code is only as good as your confidence in the test. A whole slew of bad tests can give you a false sense of security.
That being said, there is still some benefit to be gained from automated testing, even if the tests start out to be a little weak: just the process of focusing on testing and making it automatic tends to catch errors and becomes self-reinforcing. They even have a name for it: becoming "test infected". It sounds bad, but really it is quite encouraging. If you have automated regression tests preceding every committed code change to your version controlled system, you can feel confident that you at least have not broken any existing functionality. It really helps to narrow down the scope of code you have to examine for any errors that crop up, which is a real time-saver.
I hope that this helps!
More Questions & Answers...