When people think of software testing they are usually referring to the execution of a program in order to detect the presence of defects. This type of testing, that executes a piece of code which could be a program or a smaller component, is more formally referred to as dynamic testing. Dynamic testing can be performed either manually or automatically (via an automated testing tool) but it is always characterized by the execution of code.
The compliment of dynamic software testing is static software testing. Static testing refers to code walkthroughs, inspections and any review of software that does not require the actual execution of the code itself. Some web references identify this type of testing as ‘inspections and walkthroughs’, thereby leaving the general term software testing to any activity that involves code execution.
Although, in essence, a question of semantics it is useful to divide all testing activities into two broad inspection software testing categories as these activities (that is dynamic and static) form a comprehensive quality control strategy for the entire software project.
In order to allow for broad software quality control, within the typical software development lifecycle (SDLC), all project work items need to be subjected to static testing. This means that business requirements, technical specifications and even test plans themselves are the subject of static testing (i.e. inspections or walkthroughs).
Subjecting all major project work items to static testing implies that the term ‘software’ (within the broader term static software testing) refers to all project work items. Although this definition (for static testing) is broader than the scope of the term software in dynamic software testing, this scope implies that all quality control of a software project can be accomplished by either static or dynamic testing.
Just as dynamic testing can be automated there are certain static tests that can also be automated. One example of an automated static software testing tool would be a tool that measures the complexity of the code within a given program. To measure code complexity the program (being tested) does not need to be executed but the measurement can be taken using a software tool. Also the structure, paragraphs used etc, of business requirements or specifications can be verified using a parsing tool so that conformance to standards can be verified (i.e. tested).
In general, the static testing of work items (such as business requirements) implies a standard or format that can be used for reference. Many companies have procedures that facilitate a process for verifying that a given work item conforms to standards. This type of static testing (i.e. standards verification) would be documented and scheduled within the project software quality control plan.
Given the categorization of all software testing into either static or dynamic groupings a comprehensive software quality control plan can be produced at the beginning of the project and referenced to monitor and control the software delivery throughout the complete SDLC (starting with the business requirements).