This is one of two heuristic approaches to testing and test design that considers different statuses of the software programming code. The other is Static vs Dynamic. These two types of approaches to test design can be combined together into one quadrant.

Black Box and Clear Box testing, also known as Open Box and Closed Box testing, are metaphors for two approaches to testing involving visibility or knowledge of software internals. It’s important software testers are aware of both approaches so they’re not limited in their thinking to only a single type of techniques. Either approach maybe more suitable depending on the current information objectives and mission of the software testing project.

Black or Closed Box

Black/closed box is testing without access or knowledge of the software’s internals. Think of the software product, system or service as a black, opaque or shut box where the internal mechanisms are hidden and the only thing that can be observed are inputs and outputs (Kaner, 2010). Testers build-up their own model of how the software product, system or service works based on these input and output observations, and use that understanding to find problems (Poston, 2020).

Black box test design is all about looking at the software system as a whole and the value it can bring to customers or end-users. Understanding the people, problem domains and contexts are critical to black box testing and the goal is to simulate real-world usage and problems without worrying how the software is built. It’s therefore most important to focus on how the incorrect software is being built in the first place (Page, Johnston and Rollison, 2009).

• Black box testing can be static or dynamic (with or without code execution)
• When it comes to checking, the focus is more on validation than verification
• The key question black box testing asks is “how doesn’t it deliver value to customers or end users?”

Clear or Open Box

Clear/open box (also glass or clear box)¹ is the opposite to black box, it’s testing with access or knowledge of the software’s internals. Think of the software product, system or service as a clear, transparent box where the internal mechanisms can be seen and everything that the machine does can be observed (Kaner, 2010). Testers may also be given models from the project team to study to help them test the software product, system or service, and use those models to find problems (Poston, 2020).

<td class="boxes"
style="text-align:
left;">
 <pre>
 </pre>
</td>

Clear box test design is all about looking at the software structure and implementation and is done with developers in mind. Understanding programming is critical to clear box testing so it’s often done by developers themselves, though testers with programming skills, access to architecture diagrams or pair-testing with developers can do clear box testing, and volunteer their services to assist developers when appropriate. Clear box can also assist black box with diagrams and code coverage used to identify edge cases, untested user functions or complex/problematic code that could be targeted for extra system testing (Page, Johnston and Rollison, 2009).

• Clear box testing can be static or dynamic (with or without code execution)
• When it comes to checking, the focus is more on verification than validation
• The key question clear box testing is asks is “how doesn’t it do what the developer(s) intended?”

Mixed Box

There are many different definitions of “grey box” testing that all try to describe something translucent between black and clear (“white”) box testing. However there’s no consensus for an intermediate meaning between testing done with and without access or knowledge of software’s internals. The best examples may be tools that expose internal variables, verbose logs with stack traces or using partial models of the software from the project team, making it a mixed approach of black and clear box testing.

Citations

• Kaner, C., 2010. BBST Foundations 1B: Overview and Basic Definitions in Software Testing. [online] TestingEducation (BBST). Available at: Link t.i. 2:31
• Page, A., Johnston, K. and Rollison, B., 2009. How We Test Software at Microsoft. 1st ed. Redmond, WA: Microsoft, p. 71
• Poston, H., 2020. What are black box, grey box, and white box penetration testing? [online] Infosec Resources. Available at: Link

Notes

1. Clear box is sometimes called white box to contrast it with black box, however the analogy doesn’t work when it comes to understanding the internals of the system are visible to the tester (you still can’t “see inside” a white box).