Types of Static Testing

Testing process is categorized into two types : Static testing and Dynamic testing. Static testing is different from Dynamic testing in a way that static testing does not involve execution of the program or the software. However, dynamic testing is performed by executing the code of the software product.

By definition, static testing is a human testing technique that does not involve executing or running the program or software product. Instead it involves, checking or monitoring the software at each phase of Software Development Life Cycle (SDLC) with the requirements or standards mentioned in the Software Requirement Specifications (SRS) of the software product.

Why is Static Testing required ?

• Detection of Bugs/ Flaws at earlier stages –
  While making a software, one can not solely depend on Dynamic testing as it uncovers the bugs or flaws of the software product at a later stage which could cost the developer a lot of time and efforts to debug.
• Increased size of software –
  As the size of the software product increases, it becomes difficult to handle it as the efficiency of code coverage decreases. That is why static testing is required as it helps to get rid of errors or bugs earlier in the software.
• Dynamic Testing is time-consuming –
  Although dynamic testing uncovers the bug and provides some details regarding the bug, however, it is still time and effort consuming to fix the bug as it comprises detecting the failure from the test case to the root cause, making it a difficult process altogether.
• Dynamic Testing is expensive –
  As mentioned earlier, dynamic testing requires test cases and doing that in itself is expensive because test cases should first be created, then executed and validated and also have to maintained, resulting in a lot of work from the testers.

Benefits of Static Testing :

• Decreased SDLC cost –
  As the bugs are identified in earlier stages of SDLC, it therefore requires less efforts and time to modify the product and resolve them, hence decreasing the overall SDLC cost.
• Increased Product quality –
  When the flaws are detected in the software, they are fixed then and there which leads to an increased quality of the product.
• Exact location of bug is traced –
  In static testing, the exact location of the bug can be traced whereas the same is not easily possible in case of dynamic testing.
• Immediate evaluation & feedback –
  Evaluation of the product happens frequently making the product of better quality as immediate feedback is received during each phase while developing the product.
• Increased effectiveness of Dynamic testing –
  As the code gets cleaner and better after static testing, it requires less efforts and time to create and maintain good quality test cases, thereby making dynamic testing more effective.

Types of Static Testing :

1. Software Inspection :

Inspection process is performed in the earlier stages of the SLDC and is applied to a specific part of product like SRS, code, product design. etc. It involves manually examining the various components of the product at the earlier stages. The software inspection process comprises six phases which are as follows :

• Planning for Inspection Meeting –
  • This phase focuses on identifying the product to be inspected and the objective of this inspection.
  • A moderator – who manages the entire inspection process, is assigned in this phase.
  • The assigned moderator checks if the product is ready for inspection or not. The moderator also selects the inspection team and assigns them their roles.
  • Moderator also schedules the inspection meeting and distributes the required material to the inspection team.
• Overview –
  • In this phase, the inspection team is given all the background information for the inspection meeting.
  • The author – who is the coder or designer responsible for developing the product presents his logic and reasoning for the product including the product’s functions, its intended purpose and the approach or concept used while developing it.
  • It is made sure that each member of the inspection team has understood and is familiar to the objectives and purpose of the inspection meeting that is to be held.
• Individual Preparation by members –
  • In this phase, the members of the inspection team individually prepare for the inspection meeting by studying the material provided in the earlier phases.
  • The team members identify the potential errors or bugs in the product and record them in a log. The log is finally submitted to the moderator. The moderator then compiles all the logs received from the members and sends a copy of it to the author.
  • The inspector – who is the person responsible for checking and identifying errors and inconsistencies in the documents or programs, reviews the product and records any problems found in it (both general and area-specific). The inspector records the problems or issues on a log along with the time spent on preparation.
  • The moderator reviews the logs to check if the team is ready and prepared for the inspection meeting or not.
  • Finally, the moderator submits all the compiled logs to the author.
• Inspection Meeting –
  • This phase involves author’s discussion on the issues raised by the team members in the compiled log.
  • Members arrive at a decision of whether the issue raised is an error or not.
  • Moderator concludes the meeting and provides a summary of the meeting – which is a list of errors found in the product and are to resolved by the author.
• Rework –
  • Rework is carried out by the author according the summary list presented by the moderator in the previous phase.
  • The author fixes all the bugs and reports to the moderator
• Follow – up –
  • Moderator checks if all errors have been resolved or not. The moderator then prepares a report. If all errors are fixed and addressed, the moderator releases the document.
  • Otherwise, unresolved issues are added to the report and another inspection meeting is scheduled.

2. Structured Walkthroughs :
This type of static testing is less formal and not so rigorous in nature. It has a simpler process as compared to inspection process. It involves the following four steps :

• Organization –
  This step involves assigning roles and responsibilities to the team selected for structural walkthroughs. The team can consist of the following members :
  • Coordinator – organizes and coordinates with all the members for the walkthrough related activities.
  • Presenter – introduces the item to be inspected.
  • Scribe – notes down all the issues and suggestions put forward by the members.
  • Tester – finds the defects or bugs in the item to be inspected.
  • Maintenance Oracle – focuses on future maintenance of the product.
  • Standards Bearer – evaluates conformance to the standards and guidelines.
  • User Representative – represents the needs and concerns of the user.
• Preparation –
  • In this step, focus lies on preparing for the structural walkthroughs which could include thinking of basic test cases that would be required to test the product.
• Walkthrough –
  • Walkthrough is performed by a tester who comes to the meeting with a small set of test cases.
  • Test cases are executed by the tester mentally and results are noted down on a paper or a presentation media.
• Rework and Follow – up –
  • This step is similar to that of the last two phases of the inspection process.
  • If no bugs are detected, then the product is approved for release. Otherwise, errors are resolved and again, a structured walkthrough is conducted.

3. Technical Reviews :

It is a higher level technique as compared to the inspection or walkthrough technique because it also involves management. This technique is used to assess and evaluate the product by checking its conformance to the development standards, guidelines and specifications.
It does not have a defined process and most of the work is carried out by the moderator as discussed below :

• Moderator gathers and distributes the material and documentation to all team members.
• Moderator also prepares a set of indicators to evaluate the product with respect to the specifications and already established standards and guidelines :
  • consistency
  • documentation
  • adherence to standards
  • completeness
  • problem definition and requirements
• The results are recorded in a document which includes both defects as well as suggestions.
• Finally, the defects are resolved and the suggestions are taken into account for improving the product.