Black Box, White Box and Gray Box Testing

Black Box testing

 

Black Box testing refers to the technique of testing a system with no knowledge of the internals of the system. Black Box testers do not have access to the source code and are oblivious of the system architecture. A Black Box tester typically interacts with a system through a user interface by providing inputs and examining outputs without knowing where and how the inputs were operated upon. In Black Box testing, target software is exercised over a range of inputs and the outputs are observed for correctness.

Advantages

a. Efficient Testing — Well suited and efficient for large code segments or units. 

b. Unbiased Testing — clearly separates user's perspective from developer's perspective through separation of QA and Development responsibilities. 

c. Non intrusive — code access not required. 

d. Easy to execute — can be scaled to large number of moderately skilled testers with no knowledge of implementation, programming language, operating systems or networks. 

Disadvantages

a. Localized Testing — Limited code path coverage since only a limited number of test inputs are actually tested. 

b. Inefficient Test Authoring — without implementation information, exhaustive input coverage would take forever and would require tremendous resources. 

c. Blind Coverage — cannot control targeting code segments or paths which may be more error prone than others.  

White Box testing

White Box Testing refers to the technique of testing a system with knowledge of the internals of the system. White Box testers have access to the source code and are aware of the system architecture. A White Box tester typically analyzes source code, derives test cases from knowledge about the source code, and finally targets specific code paths to achieve a certain level of code coverage. A White Box tester with access to details about both operations can readily craft efficient test cases that exercise boundary conditions.

Advantages

a. Increased Effectiveness — Crosschecking design decisions and assumptions against source code may outline a robust design, but the implementation may not align with the design intent. 

b. Full Code Pathway Capable — all the possible code pathways can be tested including error handling, resource dependencies, and additional internal code logic/flow. 

c. Early Defect Identification — Analyzing source code and developing tests based on the implementation details enables testers to find programming errors quickly. 

d. Reveal Hidden Code Flaws — access to source code improves understanding and uncovering unintended hidden behavior of program modules.

Disadvantages

a. Difficult To Scale — requires intimate knowledge of target system, testing tools and coding languages, and modeling. It suffers for scalability of skilled and expert testers. 

b. Difficult to Maintain — requires specialized tools such as source code analyzers, debuggers, and fault injectors. 

c. Cultural Stress — the demarcation between developer and testers starts to blur which may become a cultural stress.

d. Highly Intrusive — requires code modification has been done using interactive debuggers, or by actually changing the source code. This may be adequate for small programs; however, it does not scale well to larger applications. Not useful for networked or distributed systems. 

Difference between Black Box and White Box Testing

1. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box. 

2. Synonyms for white-box include: structural, glass-box and clear-box.

3. Generally black box testing will begin early in the software development i.e. in requirement gathering phase itself. But for white box testing approach one has to wait for the designing has to complete.

4. We can use black testing strategy almost any size either it may be small or large. But white box testing will be effective only for small lines of codes or piece of codes.

5. In white box testing we can not test Performance of the application. But in Black box testing we can do it.

Gray Box testing

Gray Box Testing refers to the technique of testing a system with limited knowledge of the internals of the system. Gray Box testers have access to detailed design documents with information beyond requirement documents. Gray Box tests are generated based on information such as state-based models or architecture diagrams of the target system.

Advantages

a. Offers Combined Benefits — Leverage strengths of both Black Box and White Box testing wherever possible. 

b. Non Intrusive — Gray Box does not rely on access to source code or binaries. Instead, based on interface definition, functional specifications, and application architecture. 

c. Intelligent Test Authoring — Based on the limited information available, a Gray Box tester can author intelligent test scenarios, especially around data type handling, communication protocols and exception handling. 

d. Unbiased Testing — The demarcation between testers and developer is still maintained. The handoff is only around interface definitions and documentation without access to source code or binaries. 

Disadvantages

a. Partial Code Coverage — Since the source code or binaries are not available, the ability to traverse code paths is still limited by the tests deduced through available information. The coverage depends on the tester authoring skills. 

b. Defect Identification — Inherent to distributed application is the difficulty associated in defect identification. Gray Box testing is still at the mercy of how well systems throw exceptions and how well are these exceptions propagated with a distributed Web Services environment.