Agile Quality Tip #3 - Catch as Many Errors as Possible Before QA

Posted on Feb 17, 2011

As we wrote previously, our current series of posts is covering 10 brief quality tips designed to help you extend well-known agile development quality practices to ensure that your software satisfies business needs—effectively and efficiently.

Tip #3 is "Use Automated Test & Analysis to Catch as Many Errors as Possible Before QA."

If defects stemming from poorly-implemented code are constantly being passed on to QA, this ultimately results in:

  • Less thorough acceptance testing by QA,
  • Frequent/lengthy QA cycles that impact the iteration deadline and scope, and/or
  • Defects slipping into the released products, then requiring fixing/patching during the time allotted for a subsequent iteration,


Many such defects could be caught by completely automated development testing—testing that can be performed on the integration server or from the desktop with a single click.

The starting point is having an effective coding policy and implementing it with static code analysis. Static code analysis checks for known anti-patterns in source code constructs and reports each occurrence of a match.  It can be performed quickly and is guaranteed to find all cases of code that match a pattern.

Defensive coding can make code immue to many categories of defects, including many defects that are extremely difficult to detect in testing, by eliminating their root causes. 

For instance, you can prevent many causes of:

  • Exceptions
  • Deadlocks
  • Race conditions
  • Missed notifications
  • Infinite loops
  • Initialization issues
  • Memory usage issues
  • Serialization issues
  • Data corruption
  • Resource & memory leaks

Not every type of defect can be prevented by static code analysis. But every defect that you can prevent is one less defect that slows the team's iteration. QA is relieved from having to find and document the defect. Development is relieved from having to stop whatever they are doing, refresh their memory of the problematic code, fix the code, and verify that the problem is solved. And QA does not have to re-test the developer's modification.

To find the types of defects that are beyond the scope of static analysis, try the following techniques—both of which require no additional manual effort:

  • Run data flow static analysis overnight. Data flow analysis statically simulates application execution paths, which may cross multiple units, components, and files. It’s like testing without actually executing the code. With data flow, you can "test" a large number of execution paths without having to write or run a single test case.
  • Enable runtime error detection as your existing functional tests execute (unit tests and manual or scripted tests). This helps you expose critical defects that surface only at runtime (for example, file overwrites) and zero in on the root cause of the application crashing, running slowly, or behaving unpredictably. The results indicate errors that actually occurred during execution. Thus, defects are reported with unprecedented accuracy.

Static Analysis - Data Flow

Runtime Error Detection Java

 

 

 

 

 

 

 

 

 

In addition, we strongly recommend peer code review, which does require effort, but is the only effective way to expose high-level defects related to logic, design, etc. Tip #10 will discuss some ways to use automation to streamline code reviews.

 

***

Want to learn more ways to control defects during development? Read about Parasoft's Development Testing platform.

ctbook-cta.jpg