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 out.
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.
What You Will Learn:
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 with the intent of finding errors.
During this process, we will understand how the following two common misconceptions about testing are not true:
- Testing is an activity that comes at the end
- 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. It is performed by the Business Analyst and other higher-level management – 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 of the rules is: 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. So, this requirement is not feasible – in other words, it cannot be accomplished through the software.
Let us now consider the following points based on this example:
- How is it determined that this requirement is not buildable and so, cannot be tested (in other words, 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 being possible? No, we are simply basing this on our review of the BRD and of course some common business sense.
- Are we testing this requirement? Sure, but purely based on the theoretical, conceptual sense but not on the actual AUT (Application under Test).
- 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:
- Who is performing this review of the BRD? – Mostly the dev team and other technical teams that are responsible for creating the product. Not testers.
- Is this review going on at the end of the product creation? No, at the very initial stage of project development. Hence, not just the end.
Static Testing Techniques:
To summarize, static testing is the verification part of software testing that follows the methods of:
- 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 addresses, “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.
| SDLC stage | Output | Verifies | Actors |
|---|---|---|---|
| Business requirement gathering | BRD (Business Requirement document) | Scope document (if any) | |
| System requirement design | FRD(Functional requirement document) | Reviews/verifies the BRD | Dev, Technical teams |
| Technical requirements design | TDD (Technical Design Document) | Reviews/verifies the FRD | Dev, Technical teams |
| Design (code) | Code | Reviews/verifies the TDD. Code review by the dev team for completeness, format etc. | Dev, Technical teams |
Note: This information can be extrapolated for projects following any development methodologies as the steps are going to 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) – it 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.
All the tests that get created at each stage on the RHS are reviewed several times during the test creation/finalizing stage. Read about the detailed process of test documentation review here.
On the RHS:
- Tests and code are reviewed in the Unit/Integration testing stages by the developers.
- 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 as well as the users before the UAT begins.
Static Testing Vs Dynamic Testing
Let us now understand the differences between these two important testing techniques:
| Static Testing | Dynamic Testing |
|---|---|
| Also known as Verification testing. | Also known as validation testing. |
| Does not require execution of the source code. | Requires execution of the source code. |
| Static testing is all about prevention of the defects | Dynamic testing is all about detecting the defects |
| It involves the documents, checklists, and a process to be followed | It involves the source code and the test cases for execution |
| No code compilation needed | Code should be compiled and in executable situation. |
| Cost of fixing the defects found is less | Cost of fixing the defects found is more |
| Done in early stages of the development life cycle | Done in later stages of the development life cycle. |
| Requires lots of meetings | Requires fewer meetings |
| This testing is done before code deployment | This testing is done after code deployment |
| Performs a dry run on the code as part of the static analysis of the code. | Code is fully analyzed for different paths by executing it. |
| Static testing covers the structural and statement coverage testing. | Dynamic testing covers the executable file of the code. |
| It includes the following items for testing: | It includes the following items for testing: |
| ? Requirement document | ? Unit tests |
| ? Design documents | ? Integration tests |
| ? Program specifications | ? System tests |
| ? GUI wireframes | ? Security tests |
| ? Performance tests | |
| ? User acceptance tests | |
| It consists of reviews, walkthrough, inspection and static analysis of code. | It consists of functional testing, non-functional testing and data/control flow analysis. |
| Some of the tools used for Static testing are: * Soot * Eclipse * Checkstyle * Clang * Sonarqube * Source meter | Some of the tools used for dynamic testing are: * ValGrind * Procmon * DroidBox * Diakon * BoundsChecker |
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. A much formal process of test case/condition identification, coverage considerations, execution, and defect reporting all mark the dynamic testing methods.
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.
Good one as always.
nice and clear explanation
Good article
Thanks for posting such types of article.
I have one question here-
You say static testing not done by tester.
Pls tell me who perform this type of testing in v model, who test all of the documents(BRD, FRD, TDD).
You’re welcome
Hi Amit Sharma,
In the article, mentioned as “Static testing is not done JUST by testers”.
QA Team plays major role in Static and QC Team plays major role in Dynamic.
Even in Dynamic Testing, experts (who are not testers) in a particular domain do the Testing(Exploratory Testing or Adhoc)
do we need test the operating system for ecommerce website for compatiblility.?
@Amit Sharna: thank you for your question. Anybody who is reading or reviewing the document might be considered as static testers. This might be dev, ba or client also
@all: thank you for your readership. Thanks rajkumar for your answer
Hi,
Nice Article!
Actually the Topic is too deep and wide to elaborate, but you did the good job with it.
I wanted to know –
in the table of (activity done in Static Testing) you didn’t mention tester/QA anywhere, why so?
As per my knowledge tester (at least Leader/Manager) play vital role in a review meeting (walkthrough, Inspection..)
Please explain!
Really valued article
and I see that any good QC member should seek to involve him self on both testing, static and dynamic
Please check ur definitions for verification and validations here … i think it should be as … Verification answers the question, “Are we building the system right?” while validation addresses, “Are we building the right system?”
Hi Swati,
Thanks for sharing this
Following action, you meant QA’s responsibility? Word “not” should be removed here?
“On the left hand side of the V-model we have activities that are not performed by the QA team.”
With your point as above, i assume that documents such as user guide, manual should be conducted by QA team?
@ Sachin: Normally, we are not involved in the code walkthroughs and reviews. This is because, as testers it is not our place to tell the dev team, how to conduct their business…
@Mayur Rathod : Our definitions are correct Mayur. We double-checked 🙂
Please let me know if you differ and also why
@Thao : I meant the statement as it is on the article. We do not formally review the BRD and FRD. We consume them or use them for our testing and in the process read them as well- so its a review that is not intended to be so.
Thanks for the article, it clarifies a lot, but I think Mayur is right. Verification answers the question: “Are we building the system right?” while validation addresses: “are we building the right system?”.
You can find this in many sources:
http://en.wikipedia.org/wiki/Verification_and_validation_(software)#Definitions
http://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/
http://www.hq.nasa.gov/office/codeq/software/ComplexElectronics/p_vv.htm
And so on…
@Swati …. the following definitions are taken from SWEBOK …
Verification is an attempt to ensure that the
product is built correctly (can i here not say i m concerned with building the product in a right way), in the sense that the output products of an activity meet the specifications imposed on them in previous activities. Validation is an attempt to ensure that the right product is built (can i here not say i m concerned with building the right product, that means i m checking whether i have built a right product)—that is, the product fulfills its specific intended purpose.
I have also been through CSTE CBOK Definitions — they are — Verification ensures that the system (software, hardware, documentation, and personnel)
complies with an organization’s standards and processes, relying on review or non-executable
methods. Validation physically ensures that the system operates according to plan by
executing the system functions through a series of tests that can be observed and evaluated.
Verification answers the question, “Did we build the right system?” while validations
addresses, “Did we build the system right?”
CBOK Definitions contradict to SWEBOK definitions. I Would also like to conform my adherence to the SWEBOK definitions bcos SWEBOK is governed by IEEE
pls check this post as well …. https://www.softwaretestinghelp.com/what-is-verification-and-validation/ … note the distinguish section … the definitions on this link contradict to the definitions u have mentioned in this blog. Either of them has to be wrong.
Hi,
I believe the following quote is written the wrong way around:
To quote the CSTE CBOK, “Verification answers the question, “Did we build the right system?” while validations addresses, “Did we build the system right?”
Verification: tests against design requirements to ensure the product will work correctly under all anticipated user conditions, i.e. did we design the product right?
Validation: tests against the user requirements to ensure that the customer received all features and attributes requested, i.e. did we design the right product?
Cheers, Peter
Lead Test Engineer
ResMed Ltd
Hi Swathi, I am beginner to testing and find this article as very helpful one..Can you please help me with some good testing courses to try and join work in Testing?
Thanks,
Sridhar