Before a single line of code is written, testing can and should begin. Static testing is the first phase in software quality assurance, but unfortunately nearly 80% of the companies out there don’t perform this vital step. So why should you by reviewing requirements for thoroughness as they are gathered, defects related to requirements can be eliminated before the next steps in the SDLC are taken. As designs are mapped out, static testing can identify potential usability issues or deviations from industry standards. When defects are found and fixed before they’re actually coded, they are less expensive, less time consuming, and much easier to fix. The cycle of manual testing, defect entry, defect fixes, and retesting is reduced to simply modifying documentation. Additionally, in this phase, defects are much easier to identify than they are when in production.

Studies have shown that nearly half of the defects found in dynamic testing could have been identified and fixed in a proper static testing phase. Projects with aggressive deadlines and tight budget constraints will notice the most benefit from this testing phase. It’s much faster and cheaper to have a meeting and identify issues than to let those issues surface months later while executing code, or letting them slip into production where the costs to fix them multiply. With nearly 100% coverage, static testing has proven to be many times more effective than dynamic testing alone.

In this phase, defects are much easier to identify than they are when in production. Studies have shown that nearly half of the defects found in dynamic testing could have been identified and fixed in a proper static testing phase.

The static testing phase starts with all team members reviewing documentation for thoroughness and appropriateness for the end goal of the product. Both formal and informal reviews are done for all documentation by developers, QA staff, business analysts, and managers. These reviews can be walkthroughs, technical reviews, or formal inspections. Some types of documentation that are commonly reviewed are:

• Business Requirement Specifications
• Functional Specifications
• Design Documents or Mockups
• Prototypes
• Prototype Specifications
• Test Plans
• Test Cases
• Manual or Automated Test Scripts
• Unit Test Cases
• System Use Cases
• Field Dictionaries
• Help Documents or Training Guides

If you’re part of the large group that feels static testing is too expensive to implement, or if you just don’t know how to get started, give QA Mentor a call to talk about our unique Static Testing and Inspection Services. Our experts will help to educate your IT team on how static testing can be implemented and integrated into your SDLC. We can walk you through real-world examples on how this phase of testing was adapted for other organizations and the impressive ROI they were able to achieve. With QA Mentor’s help in this phase, you can achieve full test coverage with lower production defects rates, shorter dynamic testing cycles, and an amazing ROI.