Static Techniques: CTFL Tutorial

3.1 Static Techniques

Hello and welcome to the Certified Tester Foundation Level (CTFL®) course offered by Simplilearn. 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 course map in the next screen.

3.2 Course Map

This lesson is divided into three topics. They are static and dynamic techniques, the review process, and static analysis by tools. Let us discuss the objectives of this lesson in the next screen.

3.3 Objectives

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 screen we will begin with the first topic, ‘Static and Dynamic Techniques.’

3.4 Static and Dynamic Techniques

In the next few screens we will discuss the static and dynamic techniques. Lesson 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 screen.

3.5 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. The key difference between static and dynamic techniques is that static techniques are used to examine the output or other project artifacts without executing it. Alternatively, dynamic techniques are used to examine code through its execution. Static techniques can be executed manually or through an automated tool. While dynamic techniques can be conducted manually or through an automated tool. While both techniques share a common objective of finding defects, 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. Dynamic testing helps in identifying functional and non-functional defects. Both techniques are complimentary and should be used together for best results. 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. Riding the bicycle on plain surfaces, rocky grounds, slippery surfaces, and at high speeds to test the level of control and comfort it offers is similar to the dynamic testing technique. These tests are conducted through the execution of the system under test. It is important 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 screen.

3.6 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, and defect implications. All of these defects are caused by improper specifications or poor code structure. Examples of static defects are 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 of 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 screen, we will find out the roles these techniques perform in the software development life cycle.

3.7 Roles of Techniques in a Software Life Cycle

The Software Development Life Cycle, also known as SDLC, was discussed in the second lesson. The afore-mentioned techniques can be applied within the SDLC. Static testing should be carried out early in the project life cycle 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 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 testing can be implemented only when the logical part of a 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 life cycle. Let us discuss the importance of early testing in the next screen.

3.8 Importance of Early Testing

Testing in a graphical form is extremely important. The cost of fixing defects is 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 on the screen, the software development phases is mapped in X axis. 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 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 a code is ready for testing. Therefore, these techniques are primarily used during the later phases of SDLC. As observed on 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 screen, we will discover what can be examined using static techniques.

3.9 Components of Static Techniques

Static techniques can be used as early as the definition phase of the software development life cycle. 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, and even status reports. When used for reviewing these documents, the techniques check for various parameters such as application of standards, completeness of information, and mapping to requirements. In the following screen, we will further classify these testing techniques.

3.10 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 on the screen. There are a number of 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 screen.

3.11 Review Process

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

3.12 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 plans and strategies, test specifications, test cases, test scripts, and user guides. In the next screen, we will list the benefits of review process.

3.13 Benefits of Review

Review is part of static testing techniques and is implemented at an early phase of the SDLC. Hence, it offers a variety of benefits. 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. In conclusion, 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 important 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 informal review in the next screen.

3.14 Formal vs. Informal Review

Reviews can be either informal to formal. A formal review is characterized by documented procedures and requirements such as an inspection. An informal review is not based on a formal, documented procedure. The formal review process is well-structured and regulated. Alternatively, informal reviews are not as well-structured, yet they still offer significant benefits. Although an inspection is arguably the most structured and formal review technique, it is not the only one. 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. 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 in 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 screen, we will look at the order of review.

3.15 Order of Reviews

The image on the screen depicts the order of reviews from most formal to most informal. Inspections Team reviews Walkthroughs Pair programming Peer desk checks Adhoc 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 screens. Let us discuss the various activities of a formal review in the next screen.

3.16 Activities of Formal Review

In contrast to informal reviews, formal reviews follow a specified 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 a 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 identification 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 strong, 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 Reviewer by 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’s 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 screen, we will understand the responsibilities of different roles in a formal review.

3.17 Formal Review—Roles and Responsibilities

There are a variety of responsibilities in a formal review. 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. We will continue discussion on roles and responsibilities in the next screen.

3.18 Formal Review Roles—and Responsibilities (contd.)

Reviewers, Checkers, or Inspectors assess a material for defects. They typically do so prior to 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 fewer source and reference documents are provided, more domain expertise pertaining to 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 as ‘Scribe’ must ensure the logging form is readable and understandable. Let us discuss an informal review, in the following screen.

3.19 Informal Review—Features

In informal reviews, there are no pre-defined 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 screen.

3.20 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. The main objective of a walkthrough is to gather information about the artifact under review and to establish a common understanding of its content. Other objectives of walkthroughs are 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 screen, we will discuss technical review.

3.21 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 and to establish consistency in the use and representation of technical concepts. Other objectives are to ensure, at an early stage, that technical concepts are used correctly and to keep the participants of the technical content of the document informed. Let us discuss the next type review, which is inspection in the following screen.

3.22 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 screen.

3.23 Order of Reviews

Each review has its own objective and therefore serves a different purpose in the document life cycle. 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 an 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 screen, we will examine the success factors for a review.

3.24 Success Factors for a Review

There are a variety of factors necessary for a successful review. First, a common objective in all reviews should be to place an emphasis on learning and process improvement. Also, 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. Furthermore, resources conducting formal reviews should receive adequate training, so they can conduct effective reviews. We will continue our discussion on the success factors in the following screen.

3.25 Success Factors for a Review (contd.)

There are other factors which are instrumental in conducting a successful review. First, involving the right people for the review meeting is important 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. Also, 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. Additionally, 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 screen.

3.26 Review Process—Example

One of the Development Leads in 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 screen, we will move on to the next topic, ‘Static Analysis by Tools’.

3.27 Static Analysis by Tools

The following screens examines what static analysis is used for and how it can be performed using tools. In the next screen, we will understand the concept of static analysis.

3.28 Static Analysis

As various artifacts like requirements, design, and plans are subjected to different types of review using static review techniques, 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 code; and helping to improve code maintainability. Analyzing defects found will lead to 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 improper declaration of variables, dead code, and missing or erroneous logic. In the next screen, we will look at the tools used in static analysis.

3.29 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 screen.

3.30 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.

3.31 Quiz

A few questions will be presented on the following screens. Select the correct option and click submit to see the feedback.

3.32 Summary

Here is a quick recap of what we have learned in 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.

3.33 Conclusion

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*
Phone Number*
Job Title*