WHITE BOX TESTING White Box Testing

White Box Testing

White box testing (also known as "glass box testing," "clear box testing," and "open box testing") encompasses a number of testing techniques that require a comprehensive understanding of the software code. For example, a programmer can perform white box testing by comparing:

- the requirements from the spec

- a piece of Python code from ShareLane

Do you want to perform some white box testing now? Let's do it!

Your First Bug Found With White Box Testing Approach Example

Spec #2233: "5.1. If user adds from 20 to 49 books (inclusively) to the shopping cart, we offer a 2%

discount."

SL

1. Go to Test Portal>Application>Source code>shopping_cart.py 2. Click the "BUG #1" link under the "View bugs" section.

Here is what we see:

If q >= 12 and q <= 49:

discount = 2

Programmer Billy used "q" as a variable to hold the value of the quantity of books added to the shopping cart. In human language the expression means:

IF the quantity of books is greater than or equal to 12 AND it is also less than or equal to 49

THEN the discount should be equal to 2

Congratulations! We’ve just found a bug using the white box testing approach! Billy made a mistake by writing 12 instead of 20. What is the bug summary? "Spec2233: shopping_cart.py: 12 instead of 20 was given as lowest limit for a 2% discount."

During black box testing we used "20" as an input and it was a legitimate scenario, BUT we didn't find a bug! We would have found a bug if we had tried "19" – i.e., a value that was not mentioned in spec. The bug was actually found during white box testing. That brings us to two very important conclusions:

1. If we simply develop test scenarios using direct ideas from the spec, we will create legitimate test cases, but those test cases won't necessarily be effective bug finders. The job of the PM is to describe how the features should work, not how the features should be tested. In other words, the PM develops USE CASES, not test cases.

Use Cases Vs Test Cases Brain Positioning

A use case is a description of :

- How software will be (or is being) used

- How software should respond to certain scenarios Example

Here is an example of a use case: "During login, if a user submits the wrong password, an error message 'Oops, invalid username or password' should be displayed.’"

A functional spec often includes a collection of use cases.

Use cases and test cases are similar, because they share the same concept: a certain scenario should lead to a certain expected result.

Use case and test cases are different because:

- The purpose of a test case is to find a bug, while the purpose of a use case is to describe how the software should respond to a user actions.

- A test case is used to test the software, while a use case is used to describe the software.

You can read an excellent article about use cases on Wikipedia.

The real power in finding bugs is invoked when we use the professional body of knowledge known as the black box testing methodology. The value of "19" originates as a test idea because I used the special black box testing technique called Boundary Values. Read on, and soon you'll become experts in many cool testing techniques!

2. Black box testing and white box testing are a great combination that helps to find bugs by improving:

- Test comprehensiveness – i.e., checking the software from different angles - Test coverage

Understanding Test Coverage Brain Positioning

Let's elaborate on test coverage.

Imagine a chessboard with 64 squares with white king on one of the squares. Each possible position of the king on the board is written on a separate card in the form of an instruction – e.g., "Move white king to E2." There should be a set of 64 cards to cover all of the possible positions. If we start moving the king using the positions specified on our cards, then, after all cards are used, we will achieve:

- 100% of the possible positions of the white king on the chessboard - 100% execution of the given instructions

Now, imagine that the chessboard is so big that the number of squares is incalculable. Let's also imagine that, according to some logic, we selected 20 positions and wrote them down on 20 cards.

Can 20 cards cover 100% of the possible positions of the white king on the chessboard? No.

But can we achieve 100% execution of the given instructions? Yes.

Now, back to software testing.

The term "test coverage" means one of the following based on the context:

1. The coverage of possible scenarios 2. Test case execution coverage

1. For the coverage of possible scenarios, we have two situations:

a. Usually, the number of possible scenarios is incalculable. Thus, we usually don't really know the exact percentage of possible scenarios that we are going to cover by our testing.

b. In some cases, the number of possible scenarios IS calculable – especially when we narrow down our testing to a small, isolated piece of the software. In those cases, as we prepare test cases we might confidently name the percentage of possible scenarios to be covered during our testing.

In both situations, the coverage of possible scenarios is improved if we add a valid unique test case – e.g., a test case that:

- Checks possible scenario

- Does not duplicate another test case

When we talked about how the black box/white box combo helps to improve test coverage, we also talked about improving the coverage of possible scenarios.

2. It's much simpler with test case execution coverage.

We always know how many test cases we have and how many of them have been executed.

So, when you are asked about test coverage, ask what that person means: the coverage of possible scenarios, or test case execution coverage.

In real life, white box testing usually exists in the form of unit testing performed by the programmer against his or her own code.