White box testing involves testing the external functionality of the code by manually reviewing the code, it's structure and design flow. 
1. Static testing of the code involves in person review of the code to detect the errors. This process has following advantages
(1.1) Desk Checking is a method to verify the portion of the code for correctness. It is normally done by the author of the code. It is usually informal and person dependent. Here the defects are detected and corrected with minimum time delay. It may not find all the bugs as the author usually may be biased about his/ her written code.
(1.2) Code Walk through: Group of people review the program code and post questions to the author of the code. The author addresses the questions by explaining the code logic involved. In this way, it brings multiple perspectives and the group conversations may discover new defects or better ways of implementing the code logic. If the reviewers do not question on some parts of the code, some of the existing defects may not get unfolded in that area.
(1.3) Code Inspection (or Fagan inspection): It is highly sturctured and formal method and demands complete preperation before an inspection/review. There are four roles in this mode of inspection.
1. The author of the code.
2. The moderator who is expected to formally run the inspection according to the process.
3. The inspectors who actually provides review comments for the code
4. The scribe who takes detailed notes during the inspection meeting and circulates them to the inspecton team after the meeting.
This method thus enlists multiple diverse views and it mandates going through the entire code in a structured manner. It thus focusses to detect all the issues or bugs.
The inspector team is selected by the author or the moderator. The inspector team members are supplied with hard or soft copies of the code and other supporting files (e.g. requirements, design, applicable standards etc.). The moderator takes the inspector team sequentially through the program code. A scribe formally documents the defects found in the inspection meeting.
Potential areas to be covered in statics analysis:
1. Unreachable code (Usage of switch cases/if-else/GOTO statements etc. usually causes this situation)
2. Declared variables are not used
3. Wrong assignment of values to the variables (e.g. decimal value is assigned to an integer variable)
4. Allocated memory is not freed up when not necessary
2. Structural Testing: In structural testing, we test the actual product code binaries against predesigned test cases. it can be classified into
(2.1) Code unit Testing: As part of the unit testing, developers performs quick tests and gain confidence that their code is capable of addressing the set requirements. To achieve this, developers uses IDE (Integrated development environment) tools where they test each step through viewing/modifying the content of the variables. They can set up break points to forcefully stop the program execution. This way, the developer can ensure the program is passign through the right loops in right number of iterations.
(2.2) Code Coverage Testing: we design and execute test cases to determine the percentage of code that is covered by testing. Code coverage testing is made up of following types of coverage:
Statement Coverage = Total statements exercised by designed tests * 100 / Total number of executable statements in the progrram
Path Coverage = Total Paths exercised by designed tests * 100/ Total number of paths in the proram
Condition Coverage = Total decisons exercised by designed tests * 100 / Total number of decisons in the program
Functional coverage = Total functions exercised by designed tests * 100 / Total number of functions in program
Code coverage upto 50% is usually achievable. Code coverage of more than 80% requires clear understanding of the code, logic and effective test case writing skills. In additon to the functional coverage, code coverage testing also helps identify (a) Performance analysis and optimization (b) Resource usage analysis (c) Critical sections of the code and (d) Memory leaks.
(2.3) Code complexity Testing: We use the metric called "cyclomatic complexity" which helps us below indecies
1. Whether the testability of the code is high or medium or low or not testable
2. Whether the cost requried to maintain the code is low, medium or high
3. Complexity of the code
For small programs, we calculate cylomatic complexity by creating code flow graphs manually. Post that we derive at Cyclomatic complexity using one of the below two formulae
Cyclomatic Compexity (M)= Number of Edges (E) - number of nodes (N) + Number of predicate nodes (P)
Cyclomatic complexity = Number of regions (R) + 1
you may view https://www.youtube.com/watch?v=0e3hz-oIdbA to understand cyclomatic complexity in detail.
For large programs, we have automated tools to calculate cylomatic complexity.
Finally...Cautions to be applied while performing WHITE BOX Testing
1. White box testing requires a sound knowledge of the program code. It requires developers and testers to work together hand in hand. It is an opportunity for the testers to understand the application in detail by pairing with developers
2. Good knowledge on end user usage scenarios is a must. Incase testers lack end user perspective of the application being tested, some users scenarios may get left out and defects may creep in.
As long as we apply caution to the above key points through other tests, there is high probability that white box testing proves to be more effective testing.
1. Static testing of the code involves in person review of the code to detect the errors. This process has following advantages
(1.1) Desk Checking is a method to verify the portion of the code for correctness. It is normally done by the author of the code. It is usually informal and person dependent. Here the defects are detected and corrected with minimum time delay. It may not find all the bugs as the author usually may be biased about his/ her written code.
(1.2) Code Walk through: Group of people review the program code and post questions to the author of the code. The author addresses the questions by explaining the code logic involved. In this way, it brings multiple perspectives and the group conversations may discover new defects or better ways of implementing the code logic. If the reviewers do not question on some parts of the code, some of the existing defects may not get unfolded in that area.
(1.3) Code Inspection (or Fagan inspection): It is highly sturctured and formal method and demands complete preperation before an inspection/review. There are four roles in this mode of inspection.
1. The author of the code.
2. The moderator who is expected to formally run the inspection according to the process.
3. The inspectors who actually provides review comments for the code
4. The scribe who takes detailed notes during the inspection meeting and circulates them to the inspecton team after the meeting.
This method thus enlists multiple diverse views and it mandates going through the entire code in a structured manner. It thus focusses to detect all the issues or bugs.
The inspector team is selected by the author or the moderator. The inspector team members are supplied with hard or soft copies of the code and other supporting files (e.g. requirements, design, applicable standards etc.). The moderator takes the inspector team sequentially through the program code. A scribe formally documents the defects found in the inspection meeting.
Potential areas to be covered in statics analysis:
1. Unreachable code (Usage of switch cases/if-else/GOTO statements etc. usually causes this situation)
2. Declared variables are not used
3. Wrong assignment of values to the variables (e.g. decimal value is assigned to an integer variable)
4. Allocated memory is not freed up when not necessary
2. Structural Testing: In structural testing, we test the actual product code binaries against predesigned test cases. it can be classified into
(2.1) Code unit Testing: As part of the unit testing, developers performs quick tests and gain confidence that their code is capable of addressing the set requirements. To achieve this, developers uses IDE (Integrated development environment) tools where they test each step through viewing/modifying the content of the variables. They can set up break points to forcefully stop the program execution. This way, the developer can ensure the program is passign through the right loops in right number of iterations.
(2.2) Code Coverage Testing: we design and execute test cases to determine the percentage of code that is covered by testing. Code coverage testing is made up of following types of coverage:
Statement Coverage = Total statements exercised by designed tests * 100 / Total number of executable statements in the progrram
Path Coverage = Total Paths exercised by designed tests * 100/ Total number of paths in the proram
Condition Coverage = Total decisons exercised by designed tests * 100 / Total number of decisons in the program
Functional coverage = Total functions exercised by designed tests * 100 / Total number of functions in program
Code coverage upto 50% is usually achievable. Code coverage of more than 80% requires clear understanding of the code, logic and effective test case writing skills. In additon to the functional coverage, code coverage testing also helps identify (a) Performance analysis and optimization (b) Resource usage analysis (c) Critical sections of the code and (d) Memory leaks.
(2.3) Code complexity Testing: We use the metric called "cyclomatic complexity" which helps us below indecies
1. Whether the testability of the code is high or medium or low or not testable
2. Whether the cost requried to maintain the code is low, medium or high
3. Complexity of the code
For small programs, we calculate cylomatic complexity by creating code flow graphs manually. Post that we derive at Cyclomatic complexity using one of the below two formulae
Cyclomatic Compexity (M)= Number of Edges (E) - number of nodes (N) + Number of predicate nodes (P)
Cyclomatic complexity = Number of regions (R) + 1
you may view https://www.youtube.com/watch?v=0e3hz-oIdbA to understand cyclomatic complexity in detail.
| Cyclomatic Complexity | What it means |
|---|---|
| 1-10 | Well written code, Testability is high, Cost/Effort to maintain is low |
| 10-20 | Moderately complex, Testability is medium, Cost/Effort to maintain is medium |
| 20-40 | Very Complex, Testability is low, Cost/Effort to maintain is high |
| Greater than 40 | Not Testable, Cost/Effort to maintain is huge |
Finally...Cautions to be applied while performing WHITE BOX Testing
1. White box testing requires a sound knowledge of the program code. It requires developers and testers to work together hand in hand. It is an opportunity for the testers to understand the application in detail by pairing with developers
2. Good knowledge on end user usage scenarios is a must. Incase testers lack end user perspective of the application being tested, some users scenarios may get left out and defects may creep in.
As long as we apply caution to the above key points through other tests, there is high probability that white box testing proves to be more effective testing.