While manufacturing a computer, would one go about developing the motherboard, RAM, power source, display tube et al, assemble them together, and then try running them? In the event of even one of them not working properly, the entire system would falter, and it would take an eternity to find out in which part the problem lay.
Similar is the case of software testing. Though developers have always shied away from testing the code they write, today, with escalating costs, and shrinking cycle-time, there is a pressing need for them to realize testing as an integral part of code writing. True that there is a dedicated QA testing team for finding the bugs, but the questions they will ask about the product is entirely different from the questions a developer will ask of the code. Only the developer will know what he expected the code to do in the first place, so only the developer can say the code is working as expected.

Testing at the developer level, unit-testing in other words, will reduce cycle time because there will not be the inevitable going-through-the-entire-system-to-discover-erring-part conundrum that is characteristic of bugs discovered in the QA phase. I call this the bug dance, where the bug passes from developer to developer as they try to ascertain where the fault lies. Also, if developers do not take that extra effort to test the code they write, as and when they do it, they will probably spend five times that time-span trying to rectify the errors detected by the QA team.

I have often heard developers say why they should test at all, it is someone else’s job and doesn’t help them. Most developers will agree that they hate debugging more than anything else. Unit-testing will ensure the software reaches the QA team with far lesser number of errors, and that would mean less of debugging.
Once developers have understood the importance of unit-testing though, another obstacle pops its head. How do they begin doing it?
The answer is simple: They just have to start doing it. To begin with will be difficult, but the more they do it, the better they will get at sending the software off to QA with lesser errors.

The QA, on its part, can collect metrics on the types of defects particular kinds of software have, the parts where the bugs reside, the characteristics of such bugs, and the cyclomatic complexity level at which the bugs occur. This, when forwarded to the developers will help them ask appropriate questions to the code during the creation phase itself.

Lastly, for testers to be efficient in their jobs, they must be well equipped with bedrock skills. What I mean here is that 10 years ago, object-oriented design was a hot topic. Today, nobody even talks about it, but it is an essential armament in the repertoire of a tester. There are many such topics that testers need to be aware of, and the only way they can do it is by looking outward from their specific jobs, reading books and materials related to their field of operation, and talking to seniors. And of course, they must pass on their skills; teaching after all is the best way to realize where the limits of your knowledge lie!.