Mumbai University > Information Technology > Sem 8 > Software Testing and Quality Assurance

Marks: 5M

Explain static unit testing with the help of an example.

OR

Differentiate static and dynamic unit testing. Also explain steps in code review process

Difference between Static Unit Testing and Dynamic Unit Testing:

Static Unit Testing:

1. Static Unit Testing is kind of testing where a software product should undergo a phase of inspection and correction at each milestone in its lifecycle.
2. In static unit testing, code is reviewed by applying techniques commonly known as inspection and walkthrough.
3. Inspection is a step by step peer group review of a work product, with each step checked against predetermined criteria and Walkthrough is a review where the author leads the team through a manual or simulated execution of the product using predefined scenarios.
4. At a certain milestone, the product need not be in its final form. For example, completion of coding is a milestone, even though coding of all units may not make the desired product.
5. Static unit testing includes the code review process which consists of the following steps :

Code review process in Static Unit Testing:

Step 1 : Readiness

1. The author of the unit ensures that the unit under test is ready for review.
2. A unit under test is said to be ready if it satisfies the following criteria :
   • Completeness: All the code relating to the unit to be reviewed must be available.
   • Minimal Functionality: The code must be tested to make sure that it performs its basic functionalities.
   • Readability: The code should be highly readable in a proper format using meaningful identifier names.
   • Complexity: The code to be reviewed must be of sufficient complexity to warrant group review.
   • Requirements and Design Documents: The documents help the reviewers in verifying whether or not the code under review implements the expected functionalities.
3. The composition of the review group includes a number of people with different roles such as Moderator, Author, Presenter, Record-keeper, Reviewers and Observers

Step 2 : Preparedness

1. Before the meeting, each reviewer carefully reviews the work package. Each reviewer develops the following:
   • List of Questions: A reviewer prepares a list of questions to be asked, if needed, of the author to clarify issues arising from his or her reading.
   • Potential CR: A reviewer may make a formal request to make a change, called as change requests rather than defect reports.
   • Suggested Improvement Opportunities: The reviewer may suggest how to fix the problems, if there are any, in the code under review.

Step3 : Examination

The examination process consists of following activities:

1. The author makes a presentation of the procedural logic used in the code, the paths denoting major computations, and the dependency of unit under review on other units.
2. The presenter reads the code line by line. The reviewers may raise questions if the code is seen to have defects.
3. The record-keeper documents the change requests and the suggestions for fixing the problems.
4. The moderator ensures that the meeting remains focussed on the review process. The moderator makes sure that the meeting makes progress at a certain rate so that the objective of the meeting is achieved.
5. At the end of the meeting, a decision is taken regarding whether or not to call another meeting to further review the code.

Step 4 : Rework

At the end of the meeting, the record-keeper produces a summary of the meeting that includes the following information: A list of all the CRs, the dates by which those will be fixed, and the names of the persons responsible for validating the CRs. A list of improvement opportunities. The minutes of the meeting. A copy of the report is distributed to all the members of the review group. After the meeting, the author works on the CRs to fix the problems.

Step 5 : Validation

1. The CRs are independently validated by the moderator or another person designated for this purpose.
2. The validation process involves checking the modified code as documented in the CRs and ensuring that the suggested improvements have been implemented correctly.
3. The revised and the final version of the outcome of the review meeting is distributed to all the group members.

Step 6 : Exit

Summarizing the review process is said to be complete if all of the following actions have been taken:

1. Every line of code in the unit has been inspected.
2. If too many defects are found in the module, the module is once again reviewed after corrections are applied by the author.
3. The author and the reviewers reach a consensus that when the corrections have been applied the code will be potentially free of defects.
4. All the CRs are documented and validated by the moderator.
5. A summary report of the meeting including the CRs is distributed to all the members of the review group.

Static unit testing can be used in applications where the effectiveness of static testing is limited by the ability of a reviewer to find defects in the code by visual means.

Static unit testing can be used in scenarios to improve the quality of products at an early stage by implementing a viable testing strategy for code review process which estimates the resources required for future projects.