Quality development is about quality assurance and zero defects not about having testing departments. Developers are the ones who inject defects into the code and therefore they are the best line of defense to remove them. The developer has the best information on what needs to be tested in his code at the time that he writes it. The longer it takes for testing or a customer to discover a code defect the longer the developer will spend in a debugger chasing down the problem.
We got rid of as many defects as we could find before management forced us to release this product, however, we really have no idea how many other defects are in the code”. This is not assuring quality; at best you get negative assurance out of this.
To compound problems, many testing departments don't even receive proper requirements against which to test the code and/or sufficient tools to work with. Large testing departments and/or large amounts of manual testing are not healthy or efficient.
Humphrey Watts was emphatic that calling defects “bugs” trivializes the issue and downplays the negative impact that defects cause on a development organization.
- don't understand the requirements or architecture
- misunderstand how to use their peer's components
- misunderstand 3rd party libraries
- having a bad day because of home troubles or work environment
- are careless because someone else will test their code
No one is more aware of how code can break down than the developer who writes it. Any line of code that is written without concentration and planning becomes a potential defect. It is impossible for testers to understand every pathway through the code and make sure that every possible combination of variables is properly taken care of.
There are many techniques that can increase code quality and dramatically reduce the amount of testing that is necessary:
- test driven development (TDD)
- database driven testing
- design by contract (DbC)
- pair programming
- minimizing cyclomatic complexity
- using static and dynamic code tools
- proper code planning techniques
Test Driven DevelopmentProperly written tests require a developer not only to think about what a code section is supposed to do but also plan how the code will be structured. If you know that there are five pathways through the code then you will write five tests ahead of time. A common problem is that you have coded n paths through the code when there are n+1 conditions.
TDD is white box testing and can reach every pathway that the developer codes. TDD is proactive and can test pathways from end to end, it does not just have to be used for unit testing. When TDD is hooked up to a continuous integration engine then defects are located and fixed before they make it to testing.
Database Driven TestingUsing actual test data to test existing routines during development is an excellent way to make sure that there are fewer production problems. The test data needs to be a copy (or subset) of production data.
Database driven testing can also be hooked up to a continuous integration engine and prevent defects from getting to testing.
Design By ContractThe Eiffel programming language introduced design by contract (DbC). DbC is orthogonal to TDD because its goal is to ensure that the contract defined by the preconditions and postconditions for each function call is not violated. DbC can be used in virtually any language for with their is an Aspect Oriented Programming (AOP) solution.
During development, the minute a developer violates the expected contract of any function (his or a peers) then the developer will get feedback to fix the problem before it gets to testing.
InspectionsInspections are not Optional and Software Professionals do Inspections.
Pair ProgrammingPair programming can be selectively used to prevent and eliminate defects from code. When developers work in pairs they not only review code as quickly as possible but also learn productivity techniques from each other. Pair programming should only be done on complex sections of code. Pair programming not only eliminates defects but allows developers to get enough feedback that they can prevent defects in the future.
Minimizing Cyclomatic ComplexityThere is evidence that routines with high cyclomatic complexity will have more latent defects than other routines. This makes sense because the number of code pathways goes up dramatically as cyclomatic complexity increases and increases the chance that the developer does not handle all of them. In most cases, testing departments can not reproduce all of the pathways in routines of high cyclomatic complexity.
Use Dynamic and Static Code CheckingThere are many code problems caused by a careless use of pointers and other powerful language constructs. Many of these problems can be detected by having the development team use dynamic and static code checking problems.
Proper Code Planning TechniquesThere are developers that try to write code at the keyboard without planning, which is neither efficient nor effective. This is like having to do errands in 5 locations and driving to the locations randomly -- you might get your errands done, but odds are it won't be efficient.
Watts Humphrey talks directly to the idea of planning in the Personal Software Process. In addition techniques like diagramming with UML or using decision tables can go a long way to thinking through code structure before it is implemented.
Developers are the ones who inject defects into the code and therefore they are the best line of defense to remove them. The developer has the best information on what needs to be tested in his code at the time that he writes it. The longer it takes for testing or a customer to discover a code defect the longer the developer will spend in a debugger chasing down the problem.
preventing and eliminating defects. Developers who learn to get the code correct the first time will reduce and eliminate effort in testing.
One goal of development should be to catch defects early; this is the only way to assure quality. Hence quality assurance starts and finishes in the development department, not the testing department.