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 as 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”. Dynamic testing is when you are working with the actual system (not some artifact or model that represents the system), providing an input, receiving an 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:
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 the v-model:
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 the 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 do-able. 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, cannot be accomplished through the software.
Let us now consider the following points based on this example:
Coming back to our misconceptions:
Static Testing Techniques:
To summarize, static testing is the verification part of software testing that follows the methods of:
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.
|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:
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 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. The detailed process of test documentation review is at http://www.softwaretestinghelp.com/test-documentation-reviews/
On the RHS:
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.