White Box Testing

White box Testing (Or) Glass box Testing (Or) Clear box Testing (Or) Structural

For doing this testing process the person have to access to the source code of the product to be tested. So it is essential that the person doing this white box testing have some knowledge of the program being tested. Though not necessary it would be more worth if the programmer itself does this white box testing process since this testing process requires the handling of source code.(see daiagram of white box process).


"It is a method of testing in which one will perform testing on the structural part of an application. Usually developers are white box testers perform it."

"Testing in which the software tester has knowledge of the back-end, structure and language of the software, or at least its purpose."

What is WBT?

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. In other word WBT tends to involve the coverage of the specification in the code.

Code coverage is defined in six types as listed below.

1) Segment coverage – Each segment of code b/w control structure is executed at least once.
2) Branch Coverage or Node Testing – Each branch in the code is taken in each possible direction at least once.
3) Compound Condition Coverage – When there are multiple conditions, you must test not only each direction but also each possible combinations of conditions, which is usually done by using a ‘Truth Table’
4) Basis Path Testing – Each independent path through the code is taken in a pre-determined order. This point will further be discussed in other section.
5) 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 i.e., those based on each piece of code chosen to be tracked. Even though the paths are considered independent, dependencies across multiple paths are not really tested for by this approach. DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.
6) Path Testing – Path testing is where all possible paths through the code are defined and covered. This testing is extremely laborious and time consuming.
7) Loop Testing – In addition top above measures, there are testing strategies based on loop testing. These strategies relate to testing single loops, concatenated loops, and nested loops. Loops are fairly simple to test unless dependencies exist among the loop or b/w a loop and the code it contains.

Who will do white box testing ?

White box testing only done by developer not the tester because white box testing is static as well as dynamic testing.

What do we do in WBT?

In WBT, we use the control structure of the procedural design to derive test cases. Using WBT methods a tester can derive the test cases that
- Guarantee that all independent paths within a module have been exercised at least once.
- Exercise all logical decisions on their true and false values.
- Execute all loops at their boundaries and within their operational bounds
- Exercise internal data structures to ensure their validity.

Why WBT?

We do WBT because Black box testing is unlikely to uncover numerous sorts of defects in the program. These defects can be of the following nature:
- Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. Error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
- The logical flow of the program is sometimes counterintuitive, meaning that our unconscious assumptions about flow of control and data may lead to design errors that are uncovered only when path testing starts.
- Typographical errors are random, some of which will be uncovered by syntax checking mechanisms but others will go undetected until testing begins.

The purpose of white box testing

Initiate a strategic initiative to build quality throughout the life cycle of a software product or service.
Provide a complementary function to black box testing.
Perform complete coverage at the component level.
Improve quality by optimizing performance.

Practices :

This section outlines some of the general practices comprising white-box testing process. In general, white-box testing practices have the
following considerations:
1.The allocation of resources to perform class and method analysis and to document and review the same.
2.Developing a test harness made up of stubs, drivers and test object libraries.
3.Development and use of standard procedures, naming conventions and libraries.
4.Establishment and maintenance of regression test suites and procedures.
5.Allocation of resources to design, document and manage a test history library.
6.The means to develop or acquire tool support for automation of capture/replay/compare, test suite execution, results verification and documentation capabilities.

Skills Required

Talking theoretically, all we need to do in WBT is to define all logical paths, develop test cases to exercise them and evaluate results i.e. generate test cases to exercise the program logic exhaustively. For this we need to know the program well i.e. We should know the specification and the code to be tested; related documents should be available too us .We must be able to tell the expected status of the program versus the actual status found at any point during the testing process.

Limitations

Unfortunately in WBT, exhaustive testing of a code presents certain logistical problems. Even for small programs, the number of possible logical paths can be very large. For instance, a 100 line C Language program that contains two nested loops executing 1 to 20 times depending upon some initial input after some basic data declaration. Inside the interior loop four if-then-else constructs are required. Then there are approximately 1014 logical paths that are to be exercised to test the program exhaustively. Which means that a magic test processor developing a single test case, execute it and evaluate results in one millisecond would require 3170 years working continuously for this exhaustive testing which is certainly impractical. Exhaustive WBT is impossible for large software systems. But that doesn’t mean
WBT should be considered as impractical. Limited WBT in which a limited no. of important logical paths are selected and exercised and important data structures are probed for validity, is both practical and WBT. It is suggested that white and black box testing techniques can be coupled to provide an approach that that validates the software interface selectively ensuring the correction of internal working of the software.

Tools used for White Box testing:

Few Test automation tool vendors offer white box testing tools which:
1) Provide run-time error and memory leak detection;
2) Record the exact amount of time the application spends in any given block of code for the purpose of finding inefficient code bottlenecks; and
3) Pinpoint areas of the application that have and have not been executed.

Advantages of White Box Testing

- Forces test developer to reason carefully about implementation
- Approximate the partitioning done by execution equivalence
- Reveals errors in "hidden" code
- Beneficent side-effects

Disadvantages of White Box Testing

- Expensive
- Cases omitted in the code could be missed out.