Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
|
Like any QA bigot, I can be critical of developers who seem to favor speed over quality when it comes to tracking bugs and testing during development. But, as in most cases, there are two sides to this story, and once you understand each perspective it makes the coder’s conundrum clear. In a nutshell, programmers are not trained, scheduled, or rewarded for testing. Testing is not taught as part of the computer science curriculum–it’s a distinct discipline from both design and development. Schedules rarely allocate time for unit or integration test, and since problems are seldom tracked by developers, there is no reward for delivering well-tested code.
“I’m measured by what I produce” in terms of lines of code, says a seasoned developer in a mutual funds company, “not by the number of bugs” in the code. “My schedules are always aggressive, so if I take extra time to test more thoroughly, I will be penalized.” How does this happen? And, more importantly, what can you do about it? Say what Before we can expect developers to unit or integration test, we have to define what they are and explain it to them. Take the time to answer questions such as: While it may not be practical to launch a full-scale developer’s education and training program, small steps can make a big difference. For example, one financial services company developed a simple unit test template that called for a list of each of the categories of input and output, the rule(s) that affected them, the selected test values, and the expected results. The developer completed the template for each unit, then–and this is key–it was reviewed by a cross-functional team of user representatives, QA staff, and development managers. This basic process yielded many benefits. Incomplete or missing requirements were uncovered, thereby improving the programmer’s understanding. The test templates brought a consistency to the process and provided continuity to new developers whose task is to maintain existing code. Perhaps most importantly, quality increased and the cycle time to complete projects declined…but it wasn’t free. Say when The cost of better unit and integration test is, of course, time. Unless time is allocated and dedicated, testing won’t get done. In the case above, the formalization of unit testing added about 12% to the development schedule but decreased overall cycle time by 30%. Why? Because the problems were found early, so they were easy to correct. So if you expect your developers to do a credible testing job, allocate the time for them to do it. Say thanks I have always been bewildered by managers who refuse to track errors back to the individual developers. I know all the reasons–we don’t want to play the blame game, it will discourage developers from taking on complex tasks, it won’t reflect the variances in difficulty among modules, and so forth–but I don’t buy them. Ironically, testers often know who the culprits are, but their own managers usually don’t. If you really believe that it’s cheaper and faster for developers to find problems than it is for testers or customers, then you should encourage them to do it. Measurement is a great motivator. Recognize and reward those who produce the cleanest code. Add quality objectives to their annual reviews. Create a culture that values quality. While I don’t advocate the use of error counts to hold anyone up to scorn and ridicule, I do think they are excellent indicators of the need for training or discipline. At one global consulting company, for example, the test group for an outsourced application development project determined that almost 90% of the problems found during testing originated with a single programmer. Upon investigation it became clear that the individual had misrepresented his skills in order to receive, in effect, on-the-job training. Whether the right decision is to remove the person or train him is not what’s important: what matters is that it’s the wrong decision to simply ignore the numbers and thus pay the penalty down the line in support and rework costs. Say so So instead of complaining about coders, come to their rescue. Help them help you. Teach them about testing, give them the time to do it, and reward them when they do. You’ll probably be surprised to discover that they’ll participate enthusiastically, since I’ve never met coders who didn’t take pride in their work…once they understood what it was. // |
