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 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 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).
Source: Link
Author: Alex Goodyear
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 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 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).
Source: Link
Author: Alex Goodyear