White box testing: Need, Skill required and Limitations

What is White Box Testing?

White box testing (WBT) is also called Structural or Glass box testing.

White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.

White Box Testing is coverage of the specification in the code.

Code coverage:

Segment coverage:
Ensure that each code statement is executed once.

Branch Coverage or Node Testing:
Coverage of each code branch in from all possible was.

Compound Condition Coverage:
For multiple condition test each condition with multiple paths and combination of different path to reach that condition.

Basis Path Testing:
Each independent path in the code is taken for testing.

Data Flow Testing (DFT):
In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code.DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. In short each data variable is tracked and its use is verified.
This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.

Path Testing:
Path testing is where all possible paths through the code are defined and covered. Its a time consuming task.

Loop Testing:
These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested by this approach.

Why we do White Box Testing?
To ensure:

• That all independent paths within a module have been exercised at least once.
• All logical decisions verified on their true and false values.
• All loops executed at their boundaries and within their operational bounds internal data structures validity.

Need of White Box Testing?
To discover the following types of bugs:

• Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
• The design errors due to difference between logical flow of the program and the actual implementation
• Typographical errors and syntax checking