Black-Box vs White-Box testing | Definition and Examples

Vlad

November 9, 2020
5 min read
Back-End Black-Box Testing Front-End White-Box TEsting

What is Black-Box testing?

Black-box testing is a testing method that involves testing the functionalities of the system without knowing its internal structures like code, architecture, etc. It is solely focused on the given inputs and the expected outputs.

Black-Box testing is acquired from previously agreed software requirements and documentation. The website, desktop application, android application, or the database itself can be candidates for black-box testing.

Types of black-box testing includes:

Functional Testing – Functional part of the SUT- System Under Test is covered based on the requirements not knowing the internal workings
Non-functional Testing – Covering the non-functional aspect of the SUT, including performance, visual testing, security testing, accessibility testing, etc
Regression Testing – Performed every time after newly released features to confirm that those changes would not affect the existing ones

Ways to perform Black-Box testing

Since black-box testing only cares about the inputs and outputs, there is a process that needs to be followed in order to perform black-box testing for the system under test:

Requirements are being reviewed and analyzed
Acceptance criteria for all functionalities extracted
Test cases created with predefined inputs and outputs for every case
Separate positive and negative scenarios
Tests executed and potential defects solved and retested

Black-Box testing techniques

One of the main black-box techniques used are:

Equivalence partitioning

A widely used technique to test a specific scenario. Very useful when we have many inputs for a test but we do not need to cover all of them. Only a few of them will do the trick. Let’s explain it better with an example:

There is an input field that should accept numbers from 1 to 100. Anything below 1 or above 100 is invalid. You need to create all of the test cases (positive and negative ones) to cover all of the scenarios. In order to avoid testing all numbers below 1, between 1 – 100 and above 100 we can do this:

All positive cases would be from 1 to 100 and we are putting them in a valid partition. Everything below 1 is an invalid value no matter if it is 0 or a negative digit and that is an invalid partition. Everything above 100 is also an invalid partition and every 4 digit number is also an invalid partition. The main thing here is that if we pick one number from a partition to do the testing, the other values from the same partition should have the same output.

So when you set it all up you’ll have 4 test cases to cover. Let’s say -1, 22, 159, 1020. We are covering all partitions with only 4 cases.

Boundary Value

Using the boundary value technique allows you to test the boundaries for every partition. Since it is closely related to the equivalence partitioning technique, let’s take the same example from above.

We’re covering only the boundaries which in this case are: 0,1,100,101,999,1000. Those are positive and negative boundary test cases and with that, we’re making sure that any edge cases are covered.

Error Guessing

Instead of following a graph or diagram, the error guessing technique solely relies on the tester’s experience in testing the software and finding bugs based on the inputs provided.

State Transition

With state transition testing, we’re focusing on which states the system is in at that moment based on the specific inputs and outputs. What will happen if we have 2 scenarios of a correct password for a login page and 2 scenarios for an invalid password.

Decision Table

When we have multiple complex inputs for a test scenario it is often a better solution to use decision tables. Decision tables test the behavior of the system by combining different inputs in a tabular form.

	Rule
Conditions	/
The mouse does not work	Y
Actions	/
Check the cable	X
Check the USB port	X

What is White-Box testing?

White-box testing is a testing method in which internal structures like code, design, and architecture are known and are tested to confirm that the flow is correct and it works as expected. Testers should have knowledge of the code structure since they need to test it. In other words, the internal workings of an application are being covered.

Types of white-box testing include:

Unit Testing – Testing one unit/component after every code change to ensure that the isolated part is working as expected

Ways to perform White-Box testing

Testing the internal structures of the system means:

Technical knowledge for those who will perform the testing is a must
Understanding the code is also a must
Understanding the internal workflow in order to write unit tests
Write unit tests to test components separately

White-Box testing techniques

Branch Testing

This technique involves testing every single branch from the decision point in the code to be executed at least once to ensure that it is working. usually hard to achieve 100% code coverage but covering the most important combinations should at least confirm that the code works. This technique is done by the developers.

Statement Testing

This technique involves testing every single statement in the code to be executed at least once to ensure that it is working as expected. The main goals are to cover all the possible paths, statements, and lines in the code. This technique is done by the developers.