Testing to find defects is waste

Have you ever heard someone say that testing to find defects is waste?  I’ve heard it and I’ve said it when teaching courses. But people aren’t hearing the whole message!The other half of the message is that testing to PREVENT defects is ESSENTIAL!  I recently read a comment to a question posed on LinkedIn which stated “Sufficiently professional and motivated development teams should (must) be able to produce defect-free code without the need for testing. All testing to find defects is waste!”  I’m sorry, but this comment is absolutely crazy.  This person is lumping ALL testing into the testing to find defects bucket.

Remember, there are two agile practices around testing that are both important.  They are unit testing and acceptance testing.  Both can be done in test first ways which give us UTDD and ATDD (unit and acceptance test-driven development respectively).  In UTDD the developer is testing that the code they wrote does what they expected it to do.  In ATDD tests are created to ensure that what the developer expected the code to do actually matches the requirement or user story.  You simply can’t have developers do both, or a misunderstood requirement will never generate an error!  The code will work, it will do what the developer expects, and amazingly what they expect it to do will also match the requirement.  Duh!

UTDD and ATDD are both examples of testing to PREVENT defects.  We can’t prevent a developer from writing code that has a defect in it, but we can prevent that defect from getting into the system.  That is the purpose of any sort of TDD.  Once the code passes all the tests the developer is done and as far as anyone knows the code works.  Now if anyone ever refactors the code, or changes something in another area that affects the code the automated tests will catch it before it gets to a verification stage or production stage.  Testing to prevent defects is a bit of a wrong phrase – it should be testing to prevent defects from being checked into the code base.  That’s really what we are trying to do.  When we use that definition it becomes clear that the testing MUST be done early and there is no “throw it over the wall to QA” mentality.

Figure out how to use both UTDD and ATDD in your organization.  Figure out how to automate both.  Figure out how to have continuous integration, nightly builds, etc.  If you can’t figure it out, invest in bringing in some consulting help to get over the hump.  The investment in time, training, tooling and dollars will be well worth it in a very short period of time.  Just ask yourself how many dollars are spent on support staff and defect fixing for production code, then determine how the organization would change if there were 50% fewer defects.  UTDD/ATDD will reduce defects in most cases by even more than that, but for most organizations a 50% reduction makes the investment in using the practices have a very short payback period.  Remember too that it is usually the best people in the organization being used to fix the most egregious defects – isn’t it worth a lot of money to have those same people be writing the next generation product rather than fixing the previous generation?

If you want to know more about one possible ATDD tool, go to our resources page and check out the book titled “FIT For Developing Software.”  It is a book about the open source tool FIT (Framework for Integrated Testing) available here.  It works for .NET languages and Java.  Some teams are incredibly effective with this tool, but it takes making the effort.

Again, if you need help with any of this, please, please call or email us.  We can provide assistance or point you to someone else that can help.