Static Testing And Dynamic Testing: What Are The Differences

Learn about the differences between two fundamental testing methodologies: Static Testing and Dynamic Testing:

The importance of Verification and Validation in testing cannot be overstated. It’s common knowledge that these two elements are vital for a successful testing procedure.

In this piece, we will concentrate on Static testing, otherwise referred to as Verification. We will examine it in-depth, as Dynamic testing is often given more attention and has many articles devoted to it.

But, understanding static testing alone is insufficient. We need to grasp its counterpart too, dynamic testing, also known as Validation. In this article, we aim to throw light on the critical contrasts between these two methodologies.

Comparing Static Testing and Dynamic Testing

Dynamic testing involves interactive work with the system rather than merely handling a representation or model of the said system. It encompasses providing input, procuring output, and comparing this output with the expected behavior. The primary aim is error detection through direct interaction with the system.

During this process, we will debunk two prevalent myths about testing:

1. Testing is a task performed solely at the conclusion of the development process.
2. Only testers perform testing, with other team members having no engagement in the process.

Let’s start with a quick overview of the V-model:

• The left-hand side of the V-model consists of activities that are not performed by the QA team.
• The right-hand side comprises activities undertaken by the development team, testers, and users.

We move on to Requirements Gathering. The Business Analyst and other top-tier management personnel execute this task. The resulting document from this stage is the Business Requirement Document (BRD).

The next stage, System Design, converts business requirements into the Functional Requirements Document (FRD).

During this conversion process, the development team, as the primary actor, scrupulously reviews the BRD document. While the main aim is to decode the business requirements, review of the BRD document occurs simultaneously.

For instance: Let’s assume that the BRD for a banking website emphasizes security. One section elaborates the password rules for users when establishing an account. One rule mentions: Users are not allowed to recycle passwords from other accounts.

This requirement is impractical because a website can only suggest password directives but cannot impose such a restriction. Therefore, it’s impossible to incorporate this requirement into the software.

Reflect on the following points based on the given example:

4. How do we conclude that this requirement is unrealistic? Our judgement is based on an analysis of the BRD and common business sense, rather than testing it on the actual site.
5. Are we testing this requirement? Yes, we are. But the test is grounded in theory and concept, not on the actual Application Under Test (AUT).
6. This sort of testing involves a simple reading or a formal overview of the BRD, or even conducting a feasibility study based on the business requirements.

Dispelling the myths:

4. The primary review of the BRD is done by the development team and other technical teams associated in product development, not by testers.
5. This review happens at the onset of the project development, not towards the end.

Static Testing Approaches:

In essence, static testing signifies the verification element of software testing. It employs methods such as:

• Document reviews
• Walkthroughs
• Inspections
• Feasibility checks or any other forms of analysis to determine if the software satisfies the stipulated requirements
• Code critique

According to the CSTE CBOK, verification settles the question, “Did we build the correct system?”, while validation resolves the question, “Did we construct the system correctly?”

The tasks associated with static testing occur on the left-hand side of the V-model.

Note: The above piece of information is applicable to projects that adhere to any development formulation, as the steps are mostly alike.

Validation is represented on the right-hand side of the V-model.

Dynamic Testing Methods:

• Unit Testing
• Integration Testing
• System Testing

The unit, integration, system, and UAT stages involve formulating tests to be executed on the AUT at various stages of its development. Though the tests serve to validate different types of requirements, all pertain to the domain of testing.

Hence, any form of testing that encompasses executing a test on the AUT and utilizing its output to conclude the result (positive or negative) is considered validation.

Is it right to infer that there is no verification on the right-hand side (RHS) of the V-model? The answer is no.

All tests established on the RHS are scrutinized numerous times during the test formulation and finalization phase. To learn more about the detailed procedure of test documentation review, refer here.

On the RHS:

• Developers review Unit and integration tests.
• During documentation, peers review System tests, and after completion, the dev team, and Business Analyst review them.
• Both the QA team and the users review UAT tests before the commencement of UAT.

Contrasting Static Testing and Dynamic Testing

Now, let’s break down the differences between these two crucial testing methodologies:

The Final Word

To sum up, static testing is a vital testing methodology that comprises actions like Business requirement review, Functional requirement review, design audits, code walkthroughs, and test documentation review. It is a continuous procedure, not restricted exclusively to testers.

Conversely, validation, a part of dynamic testing, is more interactive. It encompasses rigorous procedures like identifying test case/condition, considering coverage, execution, and reporting of defects.

About the Author: Swati S., a member of the STH team, authored this article.

Feel comfortable to share your remarks, queries, and experiences related to static and dynamic testing.

PREV<<