Static Testing And Dynamic Testing: What Are The Differences

Learn about the two important testing techniques Static Testing And Dynamic Testing and the differences between the two:

Testing is Verification and Validation. We all know that it takes 2 Vs to make testing complete.

In today’s article, we will shed some light on Static testing. It is also called Verification. We will learn all about it and pay special emphasis on this because Dynamic testing often receives maximum attention and has innumerable articles detailing it.

However, no discussion on static testing would be complete without an explanation of what its counterpart dynamic testing means. Dynamic testing is validation, the other “V”. We will also learn about the key differences between the two techniques.

Static And Dynamic Testing

Dynamic testing is when you are working with the actual system (not some artifact or model that represents the system), providing an input, receiving output, and comparing the output to the expected behavior. It is hands-on working with the system, intending to find errors.

During this process, we will understand how the following two common misconceptions about testing are not true:

1. Testing is an activity that comes at the end
2. It is performed only by testers and the rest of them have nothing to do

Let us start with a quick reference to the v-model:

• On the left-hand side of the V-model, we have activities that are not performed by the QA team.
• On the right-hand side, we have some of them that are taken care of by the Dev team, some by the testers, and some by users.

Let’s start with – Requirements Gathering. The Business Analyst and other high-level management performs it. The output document for this phase is the Business requirement document, BRD.

The next stage is System Design. System design is a phase where the business requirements are translated into the Functional requirements, in the FRD (Functional Requirements Document).

When the translation is happening, the Dev team (who is the main actor in this step) is going to go over the BRD document step by step, page by page, and line by line. Even though the primary goal is to consume the business requirements for the sake of translation, the BRD document is getting reviewed in turn.

An Example: Say this is the BRD for a banking site that is big on security. There is a section in the BRD that talks about the password rules for the various users creating an account with the online banking site. One rule is that a user cannot use a password that he/she uses for other accounts.

This is not doable. Because a site can merely suggest how the user should set login credentials, but there is no way this restriction can be imposed. The software cannot accomplish this requirement; it is not feasible.

Let us now consider the following points based on this example:

1. How is it determined that this requirement is not buildable and so cannot be tested (not feasible)? Do we have the bank’s site and then do we set the login and password – and then realize that this is not possible? No, we are simply basing this on our review of the BRD and, of course, some common business sense.
2. Are we testing this requirement? Sure, but purely based on the theoretical, conceptual sense, not on the actual AUT (Application under Test).
3. What is the physical form of this test? A simple reading or a formal review of the BRD, or an even more formal feasibility analysis of the business requirements.

Coming back to our misconceptions:

4. Who is performing this review of the BRD? – Mostly the dev team and other technical teams that create the product. These are not testers.
5. Is this review going on at the end of the product creation? No, in the earliest stage of project development. So, it’s more than just the ending.

Static Testing Techniques:

To summarize, static testing is the verification part of software testing that follows the following methods:

• Document reviews
• Walkthroughs
• Inspection
• Feasibility analysis or any other form of analysis to determine if the software is what it should be or not
• Code review

To quote the CSTE CBOK, “Verification answers the question, “Did we build the right system?” while validations address, “Did we build the system right?”

The following are all the static testing activities that happen on the left-hand side of the V-model.

Note that you can extrapolate this information for projects following any development methodologies, as the steps will be more or less similar.

On the right-hand side of the V-model is validation.

Dynamic Testing Techniques:

• Unit Testing
• Integration Testing
• System Testing

The Unit, integration, system, and UAT phases are all about creating tests to be performed on the AUT during various stages of its development. Even though the tests are targeted at validating different kinds of requirements, they are all tests all the same.

So, any form of testing where we have a test that needs to be executed on an AUT and its output is required to determine the outcome of the test (successful or not) – is validation.

Now, would it be ok to generalize that on the right-hand side (RHS) of the V-model, there is no verification at all? The answer is, No.

During the test creation/finalizing stage, the team reviews all the tests that are created at each stage on the RHS several times. Read about the detailed process of the test documentation review here.

On the RHS:

• The developers reviewed tests and code in the Unit/Integration testing stages.
• System Tests undergo a peer review during their documentation and upon completion undergo a review by the dev team and business analyst.
• UAT tests undergo a review by the QA team and the users before the UAT begins.

Static Testing Vs Dynamic Testing

Let us now understand the differences between these two important testing techniques.

Conclusion

In conclusion, static testing is an important testing technique that takes the form of Business requirement review, Functional requirement review, design reviews, code walkthroughs, and test documentation review. It is a continuous activity and not done just by testers.

Validation, the dynamic testing part, is more hands-on and happens on the product itself and not on an artifact or a representation of the product. The dynamic testing methods are characterized by a much more formal process of test case/condition identification, coverage considerations, execution, and defect reporting.

About Author: This article is written by STH team member Swati S.

Please share your comments, questions, and experiences on the static and dynamic testing topic.

<<PREV