Teaching Developers how to be better Testers

I have been to several companies where the only test placed on a development deliverable was the unit test. Granted, these are all in-house, custom development departments whose products never see a shelf beyond the walls of their own corporation. However, several of these companies have asked me, “Could you please teach these developers how to write a better test case? We are tired of them missing defects.” The answer is hopefully obvious. Teaching the developer how to test their own work is the wrong approach. Try teaching a writer how to edit their own novel without an editor. In most cases a second, un-biased eye needs to be placed on the work in order to see the flaws.

The problem with editing one’s own work is that humans have a tendency to assume that the work they have done is correct and complete. A good tester is a third party, someone who has not completed the piece of work they are testing. A better tester is someone who enjoys testing and most importantly has the time to test the product. Expecting a developer to test their own work within the same development timeline is setting both you and your developer up for failure.

The problem here is not that testing is or is not being done. The problem is that custom, in-house development groups are not giving their in-house clientele the same respect they would a paying consumer. It is much easier to throw a defect ridden product to an internal user and ask them to live with patch after patch. No external customer would ever allow that treatment to continue because they could move on to another software company.

The question is how does an in-house group start the change? How do you begin to do the right thing by your colleagues and apply appropriate processes to custom development projects? Is starting with teaching your developers to be better testers really the answer?