Quora is a remarkable resource. To me, it’s like a Wikipedia of personal experiences. People also come there for learning. Of course, software development and testing topics are among popular.

So the questions were asked:

• What is white box testing?
• What is black box testing?

While some answers strive to give formal definitions, I decided to step away from the labels and demonstrate with examples. After all, people are trying to understand how it works, not how it’s called.

Cross-posting my answers below.

What is white box testing?

Let’s take a look at this

(Source: samples at Arithmetic Operations on two numbers)

We see the code. We can read it. We can infer what it’s supposed to do. We can mentally execute it and identify possible issues.

The code is in a transparent “box”. Or a “glass” box. Which, eventually, to contrast it with Black Box testing, became a White Box testing term, albeit slightly misleading in this form.

Now to action!

Let’s take a closer look at the “div” function.

• We can see that the coder assumed floating point numbers.
  • Example of a potential problem: if the solution is required to handle data with a precision beyond supported in this data type, there might be errors.
• We can see that the inputs are [attempted] to be directly converted to ..integers! (Learn more about this function Convert.ToInt32 Method (String)
  • Potential problem. Forget about the floating point precision – all data past decimal point will be lost!
  • Potential problem. If a user puts “-” sign or hits a space by mistake, it will be considered a non-number.
• We can see the [attempt] of a direct division.
  • Uh-oh.. What if the second number is zero?

That was a little of White Box testing (or Unit Testing)

• Note that I say potential problem for a reason. I’m not making much of assumptions about this code.
  • Maybe it’s just a first pass of coding, and refactoring will follow, and the problems above will be mitigated.
  • Maybe it’s a code snippet designed specifically to train white box testing skills. Then each “bug” is actually a valuable feature, intended to teach about certain problem patterns.
• Since each function is a small isolated unit of code, we can interchangeably use the term Unit Testing here.
• Note that we didn’t really execute this code. This is why sometimes this type of testing is done as a part of Code Review. Or even called a code review in some development teams.

We can take it further

Note that certain thought experiments we did were like passing some values and executing the instructions. Why can’t we do that for real?

Just write some more code calling the function:

• Try a div with (1,0)
• Try a div with (null, 1)
• Try a div with (“one”, 1)

And so on.

You can even pre-code an expected behavior for each call, and reporting if the actual didn’t match the expected.

There are libraries and frameworks for coded unit testing. Take a pick: Unit Test Basics

---

How White Box testing may resemble elements of Black Box testing

Note that we didn’t really need to know the code of the div function when we coded our unit tests. We had to know what are the passed in arguments and returned parameters. And we had to know what is the purpose, the expected behavior of the function.

Armed with that knowledge we could design same tests (and more).

This situation is not uncommon. Developers may need to write unit tests for someone’s else code. Or for 3rd party libraries. Or for their own code they wrote long enough ago to forget what it was exactly.

But because it’s still testing of the code modules, not the entire product, it’s typically falls under white box – or glass box – or unit testing label.

 

 

What is black box testing?

Let’s take a look at this

(image credit: samples at Arithmetic Operations on two numbers)

This is a “box” that takes some input and gives you some output. You don’t know what’s going on inside.

In fact, you don’t even know all the inputs and outputs of your “black box”, your system under test. (image credit: Cem Kaner, The Ongoing Revolution in Software Testing)

Interact, Observe, Evaluate

Because we don’t have a direct knowledge or control over what’s inside we can only try to interact with it and observe the behavior.

As we gather our observations, we also need some evaluation rule(s) to make a judgment – is there a potential problem?

Note that a perception of a problem will be different for different people. Therefore testing, being a service, must not rely solely on the testers’ perception of the problem.

What is your reasoning based on?

As I said, we need to have some evaluation rules. Such rules typically involve an expectation and a decision criteria. Although sometimes it’s enough to point to problematic inconsistencies.

Sources of expectations might be

• [Doh!] Business requirements (never come absolutely detailed, often become quickly outdated, typically contain internal inconsistencies) – written and said, emailed and sketched on a whiteboard.
• Specification (sometimes this term is used interchangeably with business reqs; more commonly means more thorough version of them, enriched with details about the technologies and implementation) – written and said, emailed and sketched on a whiteboard.
• User manuals, guides, training materials, and so on. Obviously, they’re intended to tell the customers how to use and what to expect from the product – which is worth to explore with testing.
• Other claims – might be marketing materials, a promotion posted by your company, even promises publicly made by the CEO last month.

This is not a complete list, just some general and the most common sources.

Let’s get some action!

(Let’s assume that the program is intended for these arithmetic calculations – add, subtract, divide, multiply. Knowing the purpose of the product is critically important! What if this program is intended for training in black box testing? – Then each “bug” would be actually a valuable feature to discover.)

Below you can see a mindmap of test ideas I quickly put together (this is not a complete list, by the way). Since there’s no actual app to explore some of the ideas are in a form of general guesses. While testing, I use just learned information to generate new test ideas and to explore further.

(Click the image to see full size)

These test ideas would turn up as in the following sample:

• Try natural, integer, and floating point inputs to explore the format of supported values.
  • Note: you may have a requirement explicitly stating the supported format, but that doesn’t necessarily mean that the app won’t do something odd when given other formats. So test it out!
• Explore the boundaries of the numbers. 255? 65535? Or 2147483647? Don’t forget the lower boundary, whether it’s zero or −2147483647.
• Of course, if you’re dealing with Real number format make sure to try the respective boundary numbers.
• Speaking of zero. Whenever and wherever a function does any calculations, make sure to try it for each input. Zero is a special case, and division by zero is a classic error.
• It matters not only what data you input but how you do that. So try
  • Using keyboard and mouse
  • Typing and pasting
  • Editing existing values and removing the content of the fields
  • Input in different order
  • Input with interruptions and repetitions
• Also explore for any other behavior, and, when discovered, investigate it.

Where to stop?

Even with this simple example we’re ending up with a considerably high number of tests. It seems like testing won’t ever run out of ideas. And this is normal.

To manage your black box testing, you need to employ set of other techniques:

• Prioritize your coverage by the importance of the functions you test
• Prioritize your coverage by the importance of the problems you target
• Prioritize your coverage by the likelihood of the potential risks
• Time box your testing sessions and track the budget of your available time

---

I feel like the answer went pretty far but I also feel that there’s so much to tell.

I only want to recommend one of the best online courses on Black Box Software Testing. You can self-train for free (all materials are downloadable) or sign up for a class for a very affordable price.

• BBST main site – http://bbst.info/
• Training with AST – AST-BBST Courses