In a nutshell, programmers are not trained, scheduled or rewarded for testing. Testing is not part of the computer science curriculum, yet it is a distinct discipline from design and development. Schedules rarely allocate time for unit or integration test, and since problems are seldom tracked by developer there is no reward for delivering well-tested code.

?I?m measured by what I produce?, said a seasoned developer in a mutual funds company, ?not by number of bugs. My schedules are always aggressive, so if I take extra time to test more thoroughly I will be penalized.?

How does this happen? What can you do about it?

Say What

Before we can expect developers to unit or integration test, we have to define what it is and explain it to them. What constitutes a unit test? Where does integration test begin and end? Must each developer verify all classes of input and output, valid and invalid, as well as all error handling? Is 100% coverage required? Is it reasonable? Is it measured by lines of code, or must it include all possible pathways and states?

While it may not be practical to launch a full-scale developer 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 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 and development management.

This basic process yielded many benefits. Incomplete or missing requirements were uncovered, improving the programmer?s understanding. The test templates brought a consistency to the process and provided continuity to new developers who were tasked with maintaining existing code. Perhaps most important, 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, it 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 earlier problems are found, the easier they are 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 the refusal to track errors to 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 is cheaper and faster for developers to find problems than 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 test 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 them is not what is important: what matters is that it is 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 time to do it, and reward them when they do. You?ll probably be surprised to discover that they participate enthusiastically, since I?ve never met a coder who didn?t take pride in their work?once they understood what it was.