Disclaimer, following article is my own writing based upon the ISTQB Foundation Level Syllabus, which is owned and copyrighted by the ISTQB.

The following are my notes for Chapter 3 - Static Techniques

3.1 Static Techniques and the Test Process
Dynamic Testing: Testing that involves execution of the software of a component or system
Static Testing: Testing of a software development artifact without execution of that artifact
---
Reviewing code and documentation without execution is useful because it can be done very early in the lifecycle, before the code is written. The sooner faults are found, the easier they are to correct. Reviews can also find omissions, which wouldn't necessarily be revealed by dynamic testing (as there would be nothing to execute).
Reviews can be done manually, but there is tool support for some tasks. Reviews of documentation are more commonly done manually, while tools are used for code analysis.
Where dynamic testing generally finds failures, static testing finds the source faults.

3.2 Review process
Entry criteria: The set of conditions permitting a process to go forward into a specific task. The entry criter prevents a task from starting if more effort would be wasted than the cost of fixing the broken criteria.
formal review: A review characterized by documented procedures and requirements
informal review: A review not based on a formal documented procedure
inspection: A type of peer review that relies on visual examination of documents to detect defect (violations of development standards, non-conformance to higher level documentation. Very formal, always based on a documented procedure (ie, the thing you are making a visual comparison to).
metric: A measurement scale and the method used for measrement
moderator: The leader and main person responsible for a review process
peer review: A review of a software work product done by a colleague of the producer of the produt, for the purpose of identifying defects and improvements.
reviewer: The person involved in the review who identifies and describes aomolies in the product under review. Multiple reviewers might be chosen to represent different points of view.
scribe: The person who records each defect mentioned and any suggestions for process improvement during a review meting, on a logging form. The scribe should ensure that the logging form is readable and understandable.
technical review: A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.
walkthrough: A step-by-step presentation by the author of a document in order to gather information and to etablish a common understanding of its content.
---
A formal review typically includes he following activities:
Planning (choosing roles, defining overall objectives and entry/exit criteria, choosing work products to review)
Kick-off (distribute documents, explain objectives, process and work products to participants)
Individual preparation (Participants review documents, note potential defects and other comments/questions)
Examination meeting (discuss and record results, note defects, make recommendations and decisions)
Rework (Fixing defects, record updated status of defects)
Follow-up (Check defects have been addressed, gather metrics, check exit criteria)

A formal review would usually include the following roles:
-Moderator (leads the review)
-Author (responsible for the product being reviewed)
-Reviewers (individuals capaable of analyzing the product for defects)
-Scribe (records all issues and open points identified during the meeting)

An informal review does not use a formal process, and will produce variable results depending upon the participants. The purpose is to get some review benefit at a low cost.
A walkthrough is led by the product author and can vary from informal to very formal. The purpose is for the audience to learn about the product and (sometimes) find defects.
A technical review must involve technical experts. Ideally the review is led by a moderator (not the author), and these reivews can range from informal to very formal. At the end, there should generally be a report of findings and recommendations. These reviews have many purposes, from finding defects to checking regulations to evaluating alternatives and making decisions.
An inspection is led by a moderator (not the author), usually conducted as a peer examination with defined roles, and uses a formal proces involving pre-meeting preparation and entry criteria, and a formal follow-up and exit criteria. The main purpose is to find defects.
The best reviews share several success factos: Clear objectives, the right participants for the objectives, positive psychology and an emphasis on learning and process improvement.

3.3 Static Analysis Tools
Compiler: A software tool that translates programs fro a high order language into their machine language equivalents
Complexity: The degre to which a component or system has a design or internal structure that is difficult to understand, maintain and verify.
Control Flow: A sequence of events (path) in the execution of a component or system.
Data Flow: An abstract representation of the sequence and possible changes of the state of data objects (creation, usage or destruction)
Static Analysis: Analysis of software development artifacts without execution of those artifacts. Usually carried out by a supporting tool.
---
The goal of static analysis is to find defects in software source code and software models. This is performed without actually executing the software being examined. Some static analysis will analyze generated output of the software, meaning the software had to execute at some point (just not during the static analysis itself)
Static analysis can find defects which would be hard to find in dynamic testing, and (like reviews) it finds defects rather than failures.
Static analysis is valuable for finding defects early (before code is ready for full execution) and warning about suspicious aspects of the code (ie bad complexity) via metrics. In general, static analysis finds different defects than dynamic testing, and leads to improvements of non-defect issues within the software.
Some specific commonly-found issues are:
-references to undefined values
-inconsistent interfaces
-bad logic (loops)
-improperly-declared variables
-unused variables and unreachable codes
-overly-complicated constructs
-syntax violations
-security vulnerabilities
Static analysis tools are typically use by developers before and during conponent and integration testing. Designers may use the tools as well during software modelling.
Static analysis tools may generate a large number of warnings, which must be managed well in order to be useful.