Static Techniques: CTFL Tutorial

Welcome to the third chapter of the CTFL tutorial (part of the Certified Tester Foundation Level (CTFL®) course).

Static techniques will be discussed in this third lesson. The static and dynamic techniques, their differences, the review process, and static analysis using tools will be examined.  

Let us look at the objectives in the next section.


After completing this lesson, you will be able to:

  • Identify static and dynamic techniques

  • Explain the activities, types, and roles and responsibilities involved in the review process

  • Explain static analysis by tools

In the next section we will begin with the first topic, ‘Static and Dynamic Techniques.’

Static and Dynamic Techniques

In the next few sections, we will discuss the static and dynamic techniques. Chapter 1 examines the objectives of testing which are to evaluate the system under test, to reveal its defects, and to provide information on its quality.

Two techniques can be used to achieve these objectives. These are static and dynamic testing techniques.

Let us compare these two testing techniques in the following section.

Static vs. Dynamic Techniques

Various techniques are used during testing to uncover different types of defects. Broadly they are classified as Static and Dynamic Techniques. 

Below is a table differentiating static and dynamic techniques.

Static Techniques

Dynamic Techniques

  • Static techniques are used to examine the output or other project artifacts without executing it.

  • Static techniques can be executed manually or through an automated tool.

  • Static testing helps in identifying the causes of these defects such as deviations from standards, requirement defects, design defects, insufficient maintainability, and incorrect interface specifications.

  • For example, when buying a bicycle, people would first want to physically inspect it for scratches. They would also want to ensure that the parts fit properly. These examples are akin to static testing techniques; they involve visually inspecting the object without executing or using it.

  • Dynamic techniques are used to examine code through its execution.

  • Dynamic techniques can be conducted manually or through an automated tool.

  • Dynamic testing helps in identifying functional and non-functional defects.

  • Example: Riding the bicycle on dull surfaces, rocky grounds, slippery surfaces, and at high speeds to test the level of control and comfort it offers is a dynamic testing technique

These tests are conducted through the execution of the system under test. It is essential to test the cycle through both techniques to ensure it is correctly assembled and meets the requirements.

Let us list the defects identified by each of these techniques, in the following section.

Classification of Software Defects

There are a variety of defects which can be identified using these techniques.

Static analysis can identify defects behind:

  • Concurrency issues

  • Performance degradation

  • Crash causing defects

  • Incorrect program behavior

  • Improper use of an Application Programming Interface (APIs),

  • Secure coding defects

  • Defect implications.

All of these defects are caused by improper specifications or poor code structure.

Examples of static defects are an improper indentation of code, dead code, incorrect instantiation of variables, and excessive loops. Resolving such defects makes the system perform faster and ensures long-time maintainability of the system. These techniques check the software against standards and accepted guidelines for software development.

Dynamic testing helps in identifying

  • Functional defects related to the requirements of the software and

  • Non-functional defects like performance and usability.

These techniques evaluate the software against the requirements of the user. Using the same example, the bicycle being able to stop within one second of applying the brakes is a functional requirement. These requirements can be tested only by using the bicycle.

In the following section, we will find out the roles these techniques perform in the software development lifecycle.

Preparing for a career in Software Testing? Check out our Course Preview on CTFL here!

Roles of Techniques in a Software Life Cycle

The Software Development Life Cycle, also known as SDLC, was discussed in the second lesson. The techniques as mentioned earlier can be applied within the SDLC.

Static Techniques

Static testing should be carried out early in the project lifecycle to identify the existence of design flaws and to ensure adherence to standards.

An analysis of the defects found by employing static testing techniques also helps to identify root causes of common, occurring defects. This helps to improve the overall SDLC.

Static testing can be implemented early in the SDLC when the code is not logically completed.

However, it should also be implemented throughout the life cycle for better results. Static techniques should be used before dynamic techniques.

Dynamic Techniques

Dynamic testing can be implemented only when the logical part of the code is ready for testing. These techniques are first used with small pieces of code. This is usually called component testing.

As more components are completed, they are integrated and tested using both static and dynamic techniques. These levels of testing are called integration, system, and user acceptance testing.

The different levels of testing were discussed in the previous lesson. Both techniques should be used throughout the development lifecycle.

Let us discuss the importance of early testing in the next section.

Importance of Early Testing

Testing in a graphical form is significant. The cost of fixing defects is at least in the early phases of the SDLC. As one moves forward through the phases, the cost of identifying and fixing the defects rises dramatically.

In the graph below, the software development phases are mapped in X-axis.

importance of early testing

These include definition, high-level design, low-level design, code, unit test, integration test, system test, and post-delivery phases. The cost of fixing defects incurred in each of these phases is mapped in Y-axis.

On the graph, the red boxes are the phases where static techniques can be applied, and the green boxes are the phases where dynamic techniques can be implemented as part of testing.

Static testing can be implemented early when the code is not logically completed. Hence, these techniques are heavily implemented in the earlier phases when coding has not even started.

However, these techniques should also be used in later phases of the life cycle for activities such as review plans, designs, data, and models.

Dynamic testing can be implemented only when the logical part of the code is ready for testing.

Therefore, these techniques are primarily used during the later phases of SDLC.

As observed in the graph, the cost of fixing defects in the early phases is much less than fixing them later in the life cycle. In fact, there is almost zero cost for fixing defects in the definition phase.

Static techniques help to identify defects earlier in the cycle.

In the next section, we will discover what can be examined using static techniques.

Components of Static Techniques

Static techniques can be used as early as the definition phase of the software development lifecycle. There are different software deliverables that can be tested using these techniques.

Contrary to the common belief that these techniques can only be used to test code, static techniques actually can, and should, be used to review all deliverables.

These include

  • Requirement documents

  • Design documents

  • Test plans

  • Test designs

  • Software code

  • Test data

  • Test cases

  • Environment plan

  • Status reports

When used for reviewing these documents, the techniques check for various parameters such as the application of standards, completeness of information, and mapping to requirements.

In the following section, we will further classify these testing techniques.

Classification of Testing Techniques

Following is a list of the different types of techniques falling under each of these two categories.

They are depicted in the image below.

classification of the testing techniques

There are some static techniques. They are reviews, inspections, walkthroughs, desk checking, and static analysis.

Under dynamic testing, there are a variety of other techniques. These include experience based, structural, and behavioral categories.

The experience-based technique is further classified into exploratory, random testing, and error guessing.

The structural technique is classified into data flow and control flow.

Data flow is further classified into techniques such as symbolic execution and definition use. Control flow is classified into other techniques such as statement, branch or decision, and branch condition.

Finally, the behavioral technique is further classified into two techniques: functional and non-functional techniques.

Functional techniques are classified into other techniques such as equivalence, boundary value partition, cause and effect, and random state.

Non-functional techniques are classified into various techniques such as usability, and performance. These commonly used techniques will be covered in this course.

Let us move on to the next topic, ‘Review Process’ in the next section.

Review Process

The first static testing technique, which is a review, will now be discussed. Let us understand the review process in the following section.

Review Process

The Institute of Electrical and Electronic Engineers, or IEEE, standard glossary defines review as,

“A process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.”

In other words, reviews are a way of testing software work products and are performed before dynamic testing execution.

Many static testing techniques can be leveraged for conducting reviews. The list of components that can be tested using static techniques and the list of components that can be reviewed are similar.

These include

  • User requirements

  • Design documents

  • Code

  • Test plan and strategy

  • Test specifications

  • Test cases

  • Test scripts

  • User guide

In the next section, we will list the benefits of the review process.

Benefits of Review

A review is part of static testing techniques and is implemented at an early phase of the SDLC. Hence, it offers a variety of benefits.

The different benefits of the review process are the following:

  • When defects are detected at an early stage, rework expenses are relatively low, and this reduces the overall cost of software products.

  • As the rework effort is substantially reduced, development productivity is likely to increase.

  • It also helps in reducing the development timescale, testing time, and associated costs.

  • This contributes to the overall project or product lifetime cost reduction. Furthermore, a review is often conducted by a team.

  • This evaluation by a team has the additional advantage of allowing for the exchange of information between the participants.

  • Reviews also contribute to an increased awareness of quality issues.

  • Reviews are a suitable method for improving the quality of software work products.

  • While the product or deliverable under review, benefits directly from the review process, reviews are also critical as they help improve the overall quality of the SDLC.

The feedback received from the review process allows for process improvement which supports the avoidance of similar errors being made in the future.

Let us compare formal with an informal review in the next section.

Formal vs. Informal Review

Below is a table differentiating formal and informal review.

Formal Review

Informal Review

  • A formal review is characterized by documented procedures and requirements such as an inspection.

  • The formal review process is well-structured and regulated.

  • The formality of a review process is related to factors such as the maturity of the development process, legal or regulatory requirements, and the need for an audit trail.

  • An informal review is not based on a formal, documented procedure.

  • Informal reviews are not as well-structured, yet they still offer significant benefits.

  • Informal reviews come in various shapes and forms. However, they all have one characteristic in common—they are not documented.

  • In reality, the informal review is possibly the most common type of review. Informal reviews are applied at various times during the early stages of the life cycle of a document.

  • A two-person team can conduct an informal review; for example, an Author can ask a colleague to review a document or code. In later stages, these reviews often involve more people and a meeting. This normally involves peers of the Author who try to find defects in the document under review and discuss these defects in a review meeting. The goal is to help the Author improve the quality of the document.

In the following section, we will look at the order of review.

Order of Reviews

The image below depicts the order of reviews from most formal to most informal. Inspections Team reviews Walkthroughs Pair programming Peer desk checks Adhoc reviews.

order of reviews

Note that this is a sample representative list of various types of reviews.

There are other review types, and they vary in their level of formality. A number of the popular review types will be studied in the following sections.

Let us discuss the various activities of a formal review in the next section.

Activities of Formal Review

In contrast to informal reviews, formal reviews follow a detailed process.

A formal review process consists of six main steps.

  1. Planning

  2. Kick-off

  3. Preparation

  4. Review meeting

  5. Rework

  6. Follow-up

Let us understand each step.

Activities of Formal Review Planning

The review process begins with a request for review made by the Author, who defines a clear objective for the review to the Moderator or inspection leader.

A Moderator is often assigned to take care of scheduling details such as the date, time, place, and invitation of the review.

For more formal reviews, such as inspections, the Moderator always performs an entry check and defines formal exit criteria during this stage. The entry check is carried out to ensure the Reviewers time is not wasted on a document that is not ready for review.

The Moderator and Author decide on the section of the document to review. The maximum size of the section reviewed is usually between 10 and 20 pages as too much information can be difficult to properly review.

In a formal inspection, only one or two pages may be examined to find serious defects that are not obvious and which require more careful scrutiny to ascertain.

The review team normally consists of four to six participants including a Moderator and an Author.

To improve the effectiveness of the review, different roles are assigned to each participant. These roles help the Reviewers focus on specific types of defects during the analysis. This reduces the chance of multiple identifications of the same defect.

The Moderator assigns the roles to the Reviewers.

Activities of Formal Review Kick-off

An optional step in a review procedure is a kick-off meeting.

The goal of this meeting is to create a cohesive understanding of the situation among all participants regarding the document under review and to commit to the mentioned timeline.

In general, a kick-off is highly recommended since there is a robust and positive effect on the motivation of Reviewers and thus on the effectiveness of the review process.

During the kick-off meeting, the Reviewers receive a short introduction to the objectives of the review and the documents.

The relationships between the document under review and the other document sources are explained, especially if the number of related documents is high.

Role assignments, checking rate, the pages to be checked, process changes, and other possible questions are also discussed during this meeting.

The distribution of the document under review, source documents, and other related documentation is also performed during the kick-off.

Activities of Formal Review Preparation

The participants prepare individually for the review using the related documents, procedures, rules, and checklists provided. This ensures Reviewers have studied the document before participating in the review.

Sometimes, this step can be handled by sharing the artifact under review with Reviewers before the meeting.

The participants can identify defects and formulate questions and comments according to their understanding of the document and their roles in the review process.

Activities of Formal Review Review Meeting

The meeting, partly dependent upon the review type, consists of the following elements: logging phase, discussion phase, and decision phase.

During the logging phase, the issues–such as defects identified during the preparation–are mentioned page by page and reviewed by the reviewer, and they are logged either by the author or by a scribe.

Every defect and its severity should be logged. The participant who identifies a particular defect can make recommendations on the defect and its handling.

In the discussion phase, all marked issues are discussed. The final decision phase is when the decision is made.

Various types of reviews differ in their approach to the process of conducting the review meeting. Some reviews follow a roundabout pattern to record all issues before they are discussed.

Other reviews are more open and discuss any specific issue as it is recorded. Such discussions must be moderated well to ensure that too much time is not spent on discussing only one issue.

Activities of Formal Review Rework

Based on recommendations from the review meeting, the Author of the document or the reviewed product must fix the defect and update the defect status accordingly.

Not every defect found leads to rework. It is the Author's responsibility to judge if a defect necessitates fixing.

If an issue is not fixed, it should still be reported to indicate that the Author has considered the issue.

Changes made to the document should be easy to identify during follow-up. To facilitate this, the Author must indicate where changes are made. This can be done by using items such as “Track Changes” in word-processing software.

Activities of Formal Review Follow-up

The Moderator is responsible for ensuring that satisfactory actions have been taken on all logged defects, process improvement suggestions, and change requests.

Although the Moderator checks to ensure the Author has taken action on all known defects, it is not necessary for the Moderator to check all the corrections in detail.

If it is decided that all participants will check the updated document, the Moderator manages the distribution and collection of the feedback.

The Moderator gathers required metrics and evaluates if the exit criteria are met to close the action items.

In the following section, we will understand the responsibilities of different roles in a formal review.

Formal Review – Roles and Responsibilities

The different roles and their responsibilities in a formal review are the following:


  • The Manager can be considered the sponsor of the review process.

  • The Manager is involved in deciding which reviews to execute, allocating time in project schedules, and determining whether review objectives have been met.

  • The Manager will also fulfill any review training requested by the participants.

  • Depending on their background, Managers can also be involved in the review process by playing the role of a Reviewer if required.


  • The Moderator, or Review Leader, leads the review process.

  • The Moderator, along with the Author, determines the type of review to be conducted, the approach to be taken in regards to the review, and the composition of the review team.

  • The Moderator performs the entry check and the follow-up on the rework to control the quality of the input and output of the review process.

  • The Moderator also schedules the meeting, distributes documents before the meeting, coaches other team members, paces the meeting, leads possible discussions, and stores the data collected.


  • The Author is the writer of the software product under review.

  • The Author's goal is to learn as much as possible about improving the quality of the artifact under review.

  • Another goal is also to improve the ability to create future artifacts.

  • The Authors' task during the review is to clarify their doubts and to understand the defects found.


  • Reviewers, Checkers, or Inspectors assess a material for defects. They typically do so before the meeting.

  • The level of thoroughness, domain knowledge, or technical expertise required depends on the type of review being conducted.

  • Reviewers should be chosen to represent different perspectives and roles in the review process. When the artifact is under review, Reviewers receive materials such as source documents, standards, and checklists. If the fewer source and reference documents are provided, more domain expertise about reviewing content is needed.


  • Recorders are people who record each defect mentioned, and they record suggestions made for process improvement during a review meeting on a logging form.

  • Recorders, sometimes referred to as ‘Scribe’ must ensure the logging form is readable and understandable.

Let us discuss an informal review, in the following section.

Informal Review – Features

The main features of an informal review are as follows:

  • In informal reviews, there are no predefined steps. Examples of informal reviews include pair programming, peer reviews, and review of detailed design and code by technical leads.

  • Review results may or may not be documented.

  • The effectiveness of each review varies due to its nature.

  • However, informal reviews are frequently used as they are an inexpensive method for capturing critical defects.

After defining both formal and informal reviews, let us look at walkthrough as a type of review in the next section.

Types of Reviews – Walkthrough

A walkthrough contains features of both formal and informal reviews.

In a walkthrough, the Author of an artifact provides a step-by-step presentation to the meeting participants.

A walkthrough meeting is led by the author, and often, a separate scribe is present. The author may use scenarios and ‘Dry Runs’ to validate the content. Walkthroughs may require separate pre-meeting preparation for reviewers.

Following are the objectives of a walkthrough.

  • To gather information about the artifact under review and to establish a common understanding of its content.

  • To present the document to stakeholders, both within and outside the software discipline, and to gather information regarding the topic under documentation.

  • They are also used to explain, transfer knowledge, and evaluate the contents of the document and to establish a common understanding of the document among reviewers.

  • They also aim to examine and discuss the validity of proposed solutions and the viability of alternatives and to establish a consensus among participants.

In the next section, we will discuss the technical review.

Types of Reviews – Technical

This type of review is a documented defect-detection process that involves peers and technical experts. It is often performed as a peer review without management participation. Ideally, it is led by a trained Moderator or by a technical expert.

A separate review is carried out during which the product is examined, and the defects are found. More formal procedures such as the use of checklists, logging lists, or issue logs are optional.

The objectives of a technical review are

  • To assess the value of technical concepts and alternatives in the product and project environment

  • To establish consistency in the use and representation of technical concepts.

  • To ensure, at an early stage, technical concepts are used correctly

  • To keep the participants of the technical content of the document informed.

Let us discuss the next type review, which is an inspection in the following section.

Types of Reviews – Inspection

Inspection is the most formal type of review and is usually led by a trained Moderator.

It uses process defined roles and involves peers to examine the product.

Rules and checklists are used during the preparation phase, during which time the product is examined, and defects are identified. These defects are documented in a logging list or issue log.

The Moderator performs a formal follow-up by applying exit criteria; optionally, a causal analysis step is introduced to address process improvement issues and learn from the defects found.

Metrics are gathered and analyzed to optimize the process.

Let us find out which review should be conducted first in this process, in the following section.

Order of Reviews

Each review has its own objective and therefore serves a different purpose in the document lifecycle.

Following are the facts to be remembered:

  • A single document may be subjected to multiple reviews.

  • The order of the reviews conducted may vary based on factors such as the type of document and the objective of the review.

For example, an informal review may be carried out before a technical review, or inspection may be carried out on a requirements specification before a walkthrough with customers.

  • The type of review selected is based on the need, time, and budget available.

  • Informal reviews help in acquiring different perspectives at a lower cost.

  • If the criticality of the artifact or chance of defects is high, more formal review types are required.

In the next section, we will examine the success factors for a review.

Success Factors for a Review

Factors to be considered for a successful review are as follows:

  • First, a standard objective in all reviews should be to place emphasis on learning and process improvement.

  • Review objectives should be clearly defined. These are set by the Moderator for formal reviews. The objectives depend on the type of review being conducted.

    • For example, for walkthroughs, the object is to share knowledge.

  • For a technical review, the objective is to identify technical alternatives, and for an inspection, the objective is to ensure the conformance to standards.

  • Once the objective is identified, the appropriate review type can be selected.

  • Checklists can be used to ensure all pre-defined parameters have been reviewed.

  • Resources conducting formal reviews should receive adequate training so they can conduct effective reviews.

  • Involving the right people for the review meeting is essential for the review’s success.

    • For example, a Functional Tester cannot be involved in a detailed technical review meeting as it will not be relevant. Alternatively,

  • Testers should be included as Reviewers in meetings to decide aspects such as business requirements and high-level system designs. They can help Authors in getting their products reviewed by independent teams as Testers understand the requirements and workflows of the process.

  • Defects found in the review process should be expressed objectively and with all required details clearly detailed to enable closure by the document’s Author.

  • Another factor for success involves ensuring that personal issues are avoided during reviews. Typically, the Moderator prevents discussions from becoming too personal by rephrasing remarks if necessary and suggesting breaks be taken in the case of heated discussions.

  • The Author and Reviewer should have a mutual trust that the Reviewer will provide genuine feedback, and the Author will implement changes as required.

We will discuss an example of the review process in the following section.

Review Process – Example

One of the Development Leads to the project received a client requirement over a conference call. The requirement was documented and to ensure understanding, and clear documentation, one of the team members, was called for a quick look at the document. This is a form of informal review.

The informal review of the requirement revealed some important gaps.

The Development Lead documented alternative flows to these gaps and requested for a technical review of the requirement with the client. The technical review helped finalize the requirement.

Owing to the legal nature of the requirement, the client had to undergo a product inspection from government agencies, before this particular feature could be released to the market.

In the following section, we will move on to the next topic, ‘Static Analysis by Tools.’

Static Analysis by Tools

The following section examines what static analysis is used for and how it can be performed using tools.

In the next section, we will understand the concept of static analysis.

Static Analysis

As various artifacts like requirements, design, and plans are subject to different types of review using static review techniques, the code also must be tested without its execution.

This code testing without execution is called static analysis of the code.

Static analysis helps in

  • Identifying defects, not failures

  • Identifying defects that cannot be found through dynamic testing techniques

  • Identifying dependencies and inconsistencies in the code

  • Improving code maintainability.

Analyzing defects found will lead to the identification of SDLC improvement areas. This leads to the prevention of future defects.

Examples of defects not covered through static analysis over time include items such as referencing a variable with undefined values and inconsistent interfaces.

Other examples include an improper declaration of variables, dead code, and missing or erroneous logic.

In the next section, we will look at the tools used in a static analysis.

Static Analysis Using Tools

Though static analysis does not involve the actual execution of code, there are automation tools to support it. Tool support eases the process of static analysis by automatically identifying commonly found defects.

The most commonly used static analysis tool is the code compiler which identifies and sends warnings during code compilation.

Let us discuss an example of static analysis of code in the following section.

Static Analysis of Code – Example

During performance testing phase of the product, it was realized that the system was not performing at the optimum speed. The test team used different scenarios to replicate the error. However, they realized that irrespective of the scenario, the performance did not improve.

The root cause of the error could not be identified using dynamic testing techniques.

Hence the development team conducted Static Analysis of the code to check for various factors such as redundant variables, dead code, improper comments and structure, and complex logic.

Using static techniques, they refined the structure of the code and succeeded in improving the performance of the system.

Let us now check your understanding of the topics covered in this lesson.

Curious about the CTFL course? Watch our Course Preview for free!


Here is a quick recap of what we have learned this lesson:

  • Both static and dynamic techniques can be executed manually or through an automated tool.

  • The IEEE standard glossary defines review as, “A process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.”

  • Various artifacts such as requirements, design, and plans are subjected to different types of review using static review techniques, and code also needs to be tested without its execution.


This concludes Static Techniques. The next lesson is Test Design Techniques.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*