Talking Shop
I think it’s safe to say that a common experience among programmers is the embarrassment caused by even the smallest oversight. I was once asked if I have a quality assurance group review my work, and I jokingly responded “yes – the customers.” There is half-truth in jest, and the frightening reality is that customers are the largest test group our software will ever see.
A dedicated QA group is not an option in my workplace, so I recently proposed that we enforce a peer review standard. This would eliminate the conflict of interest that arises out of self-policing, but does nothing to address the fact that programmers don’t think like users. We know what input the application is expecting, so we are given to testing the best-case scenario and not the application’s ability to handle the unexpected.
Those who are better versed in project management than me noted that software is the result of a development process, so the only way to ensure the software’s quality is to ensure the quality of the process used to create it – not by subjecting it to rigorous testing after the fact. That sounded a bit esoteric at first, and I was tempted to ask, “Isn’t testing part of the process?”
But really, all stages of development are susceptible to mistakes. What the users will perceive as a “bug” could just as easily have been a misinterpretation of requirements – it could a programming error or a missing file during distribution.
Only by following a development “road map” can we avoid getting lost. If a series of steps can be identified as the development process, then the repetition of these steps to design and construct application after application will yield consistent results. Validation must happen continually, rather than at the end, when the cost of fixing anything is at its highest.
Identifying the series of steps that will make up a process that works may be the most challenging part of introducing QA measures, but something as simple as putting them on a checklist will have enormous payback. This will mean that you aren’t approaching QA from square one with every new application – and when you find something that doesn’t work, the process itself gets refined.
It seems a peer review is not the most effective way to avoid exposing errors to customers, but I’m still not ready to abandon the idea. There is another side to QA that the customer never sees – at least not directly.
A well-built application is structured to facilitate maintenance of code. Asking other programmers for a critical review of the code itself ensures that it is understandable, well-documented and efficiently written. It also means that more than one person is familiar with it before it gets deployed. Code sharing may even introduce a slight competitive spirit between programmers, which will motivate the creation of a better product.
I’d be very interested to hear from anyone who has had success implementing QA, especially with small development teams. Any tips that may save me future embarrassment would be much appreciated.
Cooney works as a programmer/analyst for a major Canadian book publisher. He can be reached at robert_cooney@hotmail.com.