No requirements? Then, there is nothing to develop and nothing to test. There is only one defect: Software was written that is not required.

I was having a discussion with a Team Lead that revolved around unit and integration testing; specifically the impact of Black-Box versus White-Box testing. Intermixed into the conversation, I brought out the possibility of Gray-Box testing as an additional approach.

Because of that conversation, I realized that it had been a while since I had researched the various testing models and how they can impact a project. As we began the process of digging into the client's existing tests and work toward shaping their testing efforts, I realized that I needed to reflect on this set of processes and ensure that a common language is communicated to the teams appropriately.

These processes are needed to provide the beginnings of a thought process; one where the end result is a suite of tests at various levels covering both the breadth and depth of the "code under test."

White-Box Testing

Also known as ...

• Clear-Box Testing
• Open-Box Testing
• Glass-Box Testing
• Transparent-Box Testing
• Code-Based Testing
• Structural Testing

White-Box Testing is a software testing method in which the internal structure, design, or implementation of the code being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. developer experience and knowledge of the implementation is essential. White-Box testing is testing beyond the user interface and into the fine details of an application.

This method is so named because the application, to the tester, is like a transparent box; the insides of which one can clearly see.

Applicability

This method of testing can be used at the unit-test level, as well as at an integration level.

Advantages

• Testing is often more thorough, with the possibility of covering most branches of the code.

Disadvantages

• Since these tests are often complex, skilled resources are needed, with a thorough knowledge of development and implementation.
• Test script maintenance can be a burden if the code is often refactored.

Black-Box Testing

Black-Box Testing (or Behavioral Testing) is a software testing method in which the internal structure, design, and implementation of the code being tested is not known to the tester. These tests are usually functional, although the can be either functional or non-functional.

This method is named as it is because the software, in the eyes of the tester, is like a black-box that hides what is inside.

This method attempts to find errors in the following categories:

• Incorrect or missing functions
• Interface errors
• Errors in data structures or external access (services or tooling)
• Behavior or performance errors
• Initialization and termination errors

Applicability

This method of testing is generally used at the integration level and above.

Advantages

• Tests are done by taking into account a users behavior and will help in exposing discrepancies in the specifications.
• Tester does not need to be a developer or event know how the software has been implemented.
• Tests can be conducted by a person or group independent from the developers, allowing for an objective perspective and the avoidance of developer-bias.
• Test cases can be designed as soon as the specifications are complete.

Disadvantages

• Only a small number of possible inputs can be tested and many code paths will be left untested.
• Without clear specifications test cases can be difficult to design.
• Tests can be redundant if the developer has already run a test case.

Gray-Box Testing

Gray-Box Testing is a software testing method that is a combination of the Black-Box and White-Box Testing method described above. In Black-Box Testing, the internal structure of the item being tested is unknown to the tester and in White-Box Testing the internal structure is known.

Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code-targeted systems in white-box testing.

In Gray-Box Testing, the internal structure is partially known. This involves having access to internal structures and logic for the purposes of designing test cases, but testing at the user, or black-box level.

Gray-Box Testing is named so because the software program, in the eyes of the tester is like a gray, semi-transparent box that allows some of what is inside to be seen.

With minimal access to the source code, Gray-Box testing is considered to be non-intrusive and unbiased. During a gray-box test, the person may know how the system components interact but not have detailed knowledge about internal functions and operation. A clear distinction exists between the developer and the tester, thereby minimizing the risk of personnel conflicts.

Advantages

• Offers combined benefits of white-box and black-box testing, it allows for advantages from both the test types.
• Non Intrusive: It is based on functional specification, architectural view whereas not on source code.
• Unbiased Testing: In spite of all above advantages and functionalities, Gray-Box testing maintains boundary for testing between tester and developer.

Disadvantages

• Partial code coverage: In gray-box testing, source code gets missed because of limited access to internal or structure of the application which results in limited access for code path traversal.

Applicability

Although the Gray-Box Testing method may be used in other levels of testing, it is generally used in Integration Testing.

Wrap Up

Normally, I would provide some conclusions to an article. But, in this case the processes, advantages, and disadvantages are fairly well defined. All three of these processes (White-Box, Black-Box, and Gray-Box Testing) are used within the various levels of testing in most organizations, irregardless of whether they were used with intent or not.

These processes should provide the beginnings of a thought process; one where the end result is a suite of tests at various levels covering both the breadth and depth of the "code under test."