Introduction of Static Testing:
Can you imagine finding defects without conducting the actual testing i.e. either manual or automation testing on just developed software product? There is a testing which is known as Static testing with which we can test the software without actually executing the code. The static testing technique involves the following two concepts.
I) Review of Supporting Project Documents:
This technique involves the method to catch and remove errors, redundancy or ambiguities in the different supporting documents such as software requirements specification (SRS), technical design document (TDD), business requirements document (BRD), functional requirement documents (FRD), test cases document, etc.
II) Static Analysis:
This technique involves the evaluation of the code quality written by developers. There are different tools such as PMD, Sonar Cube, etc. which can analyze the code and compare it with the standard practices, identify the unused variables, dead code, infinite loop, etc. It helps to identify the structural defects quickly which may later result in actual software defects.
I) Types of Reviews of Supporting Project Documents:
The types of reviews can be explained with the help of the following simple diagram.
1) Informal Review:
This is a kind of review where presentation is given by the creator of documents such as software requirements specification (SRS), technical design document (TDD), business requirements document (BRD), functional requirement documents (FRD), test cases document, etc. to the wide audience. The audience could be senior management, business clients, development team, internal audit team, etc. During such reviews and after the reviews, the audience can put forward their opinion and can share their experience in order to outline the review defects. Such static testing type is very useful as it helps in the early identification of the defect and we can restrict it propagate down the line into development or testing phase where it may cause a delay in the project deliveries depending on the severity of the defect.
2) Walkthrough:
Documents walkthrough is usually done with the expert or the senior member of the team. For example, Software Requirements Specification Document (SRS) will be reviewed with the Business lead who have provided the requirements, Functional Requirements Document (FRD) will be reviewed with the technical team who is going to write the solution, test cases document will be reviewed by the testing team who is going to execute those test, etc. Such walkthrough is useful in two ways first is that the lead is aware of the quality of the documents and second the target team comes to know about what exactly is going on are they are on the right track?
3) Peer Review:
It is the review with the peer to ensure maker and checker. A team of two or more can review each other work to outline the common mistake such as spelling mistake, workflow mistake, requirement gathering makes scheduling mistake, etc. Here the colleague is included as the peer who tests the work at the document level.
4) Inspection:
It is the technique to validate the documentation work by the dedicated governance team. For example, the BRD (Business Requirement Document), TDD (technical design Document), change ticket, etc. are reviewed by compliance, tollgate team, and change governance respectively. This comes under inspection. Inspection can straight reject the execution of the document if they find it inappropriate as they are given the power to make early go or no-go decision.
II) Static Analysis – by using tools:
We can outline the defects in the code before we can start the actual testing with the help of tools which cover the following types of defects during static analysis.
1) No value assigned to a variable:
As a good programming practice, it is always recommended to assign an initial value to a variable as it is very difficult to handle default values which are assigned to the variable with undefined values by compiler depending on its data type. Most of these data types are assigned default values as null and it is very difficult to handle null value as they often cause “Null Pointer Exception”.
2) The inconsistency of interface between modules and components:
The tool helps to outline the inconsistencies between modules and components as it may result in wrong output. This practice helps to mitigate unwanted defects in the code.
3) Variables which are declared but never used in the program:
Sometimes while building the code logic, developer use temporary variables which at the point of final logic creation are never used. Though such variables do not cause any issue in executing the program logic it is still an overhead on compiler and memory usage. Therefore, the variables which are of no use should be either commented out or completely removed from the code.
4) Unreachable code or Dead Code:
Sometimes developer develops a block of code which gets triggered at a particular condition but that actual condition will never have gone to happen or become true. In such scenario, such a block of code is considered as a dead code or unreachable code. Such code should be removed as it plays no role in the application building logic.
5) Infinite loop:
When we loop within a program we should be mindful of the exit condition of the loop. It should not happen that the condition on which loop depends is always going to be true and never ends. Such situation will result in an infinite loop and cause the application to fail. Such a defect will be a fatal defect as the entire application may get halted to operate.
6) Coding standards Practices:
There are standard coding practices which are enforced by an organization or the vendor which supplies the compiler. Such practices will result in the least overhead on the compiler and the code become easy to understand by another developer.
7) Security vulnerabilities:
There could be many security breaches in the code which may be dangerous to the organization. It could happen especially when loggers are used by the developer. It should be made sure that the loggers are not publishing passwords or any business critical information on the application logs as it may result in the application security breaches.
8) Syntax violations:
Syntax should be properly used while writing the application code. In other words, if we expect a function is going to return a string value we cannot simply code to assume it to an integer or float. Such syntaxes should be well kept in mind.
Over to you:
In this article, we discussed static testing which could be performed through two approaches i.e. by reviewing the documents and static analysis by using tools.
If you are not a regular reader of this website then highly recommends you Sign up for our free email newsletter!! Sign up just providing your email address below:
Happy Testing!!!