I’ve never heard of the term “static testing”. I have only heard of the term “static analysis”, which refers to any time a work product is examined without being used. This includes code reviews as well as using tools such as lint, FindBugs, PMD, and FxCop.

Here is some information from sources that I have available:

• Section 5 (Software Testing) of the Guide to the Software Engineering Body of Knowledge does not reference “static testing”. It refers to “static software quality management techniques” described in Section 11 (Software Quality). Section 11 only has a single mention of tools being used to support these activities, stating that the analytic static activities may be conducted “with or without the assistance of tools”.
• Ian Sommerville’s Software Engineering, 8th Edition’s glossary specifically mentions static analysis as being a “tool-based analysis of a program’s source code to discover errors and anomalies”. However, in Chapter 22.3, Sommerville does refer to inspections as “one form of static analysis”. There is no reference to “static testing”. This book is considered one of the canonical references about the breadth of software engineering and is often cited as recommended reading before both IEEE certification exams.
• Roger S. Pressman’s Software Engineering: A Practitioner’s Approach, 6th Edition makes no references to static analysis or static testing that I could find in the index or the chapters on testing.
• Steve McConnell’s Code Complete, 2nd Edition makes no specific references to either static analysis or static testing. However, Chapter 30.2 has a section about analyzing code quality. Tools to automatically check syntax and semantics are called tools that “examine the static source code to assess its quality”. A specific example is Lint, which is frequently referred to as a static analysis tool by other sources.

Analysis tools can only be used to verify the product. Human reviews of artifacts can be used to perform both verification and validation. Testing that involves the software’s execution can be verification, validation, or both, depending on the context. The key difference is that verification is concerned with finding mistakes and defects. In contrast, validation is concerned with ensuring the requirements adequately describe the customer/user’s needs, and the work artifacts (design, implementation, and tests) correspond to the requirements (and the products that they are derived from).

It’s (S)QA, not Testing!

It doesn’t actually perform any testing, so I’d be surprised why this would be treated and refered to as such. Except if you expect the reviewers to test the program along with their review of the code.

Code reviews nowadays may, on occasion, pick up bugs. But they are more about reviewing the quality of the code rather than the quality of the product.

But there was a time when static testing — stepping through the code with an eye to catching bugs — was a justifiable technique. That time was when compilation was something you put in a VMS queue and waited four hours for it to run. Then you’d set up a test run and put it at the back of the same queue. Or, earlier, you’d print the code out on cards and carry them over to an operations room, expecting to be able to test it in a couple of days.

Spending an hour running through the code before (or, often, while) waiting for that was a very good idea.

Now you can compile in seconds and run instantly, so the benefits of static testing have long gone. But those days were less than 20 years ago, for some of us, and that might be why you’re still seeing reference to code reviews as an application QA activity.