Introduction to black box testing

They say the best way to avoid disappointment is to not expect anything from anyone, but is it really possible? We all read reviews online, we all value opinions from both our friends and strangers, we all never want to buy a pig in a poke. Luckily, it often works the other way around – most producers take good care of their customers and do their very best to provide clients with what they expect or even more.

When producing software solutions, the development team is determined to create valuable operating systems, but test engineers are the ones that make sure the product is flawless. In order to be the best at what they do, they have come up with several methods, with black box testing being just one of them.

What is black boxing?

There are two ways we can perform software testing and you can find the description of both of them on our blog,  today I will be focusing on one of them only which is manual testing. Software developers and test engineers run test after test comparing the product with program expectations and the reason why black box testing – opposed to white box testing -- is unique is that the engineers have no knowledge of the internal structure and code. It is called that this because the tester sees the software literally as a black box inside which they cannot see.

Why black boxing may be beneficial

Being the most popular manual testing method, black box testing has a lot to offer. Its main advantage is that testers can feel like the actual users and thus be more objective because, as I have already stated, they do not know the internal workings of the application or website being tested. They are also not obliged to know any programming language, in fact, they are not expected to be technical in any way. Another positive aspect is that the moment the specifications are complete, the test cases can be designed right away.

Why black boxing may be harmful

Every rose has its thorns and so does black box testing. This method may be unique, however, it does take a lot of time and effort to design such tests and make sure the results are not overestimated at the same time. Without having clear and concise specifications, only a small number of possible inputs can actually be tested, but it is almost unrealistic to test every input stream there is. No matter how beneficial black box testing may be in some cases, you must remember it may leave you with many paths untested when not paying enough attention.

Equivalence Partitioning

As black box testing is rather complicated, there are several methods with equivalence partitioning being the most popular one. Using this technique, a test engineer divides all the possible inputs into smaller groups for which the response is supposed to be the same and then checks how the systems react to one value, assuming that it should behave the very same way for the rest of the values as well. Let me provide you with an example to make things clearer. Imagine an application for teachers to grade exams. If a student can get a maximum of 7 points and only one of three grades can be assigned (good when he scores between 3 and 5, unsatisfactory when less than 3 and excellent -- when more than 5), the possible outcomes of the exam results can be divided into the following partitioning:

Number of points

Expected grade

0,1,2

unsatisfactory

3,4,5

Good

6,7

excellent

 

            Boundary Value Analysis

            The next method uses equivalence partitioning as its basis but responds only to the highest and the lowest value for each partitioning. The system which earlier checked every grade a student could get, will now only determine if he or she passed the exam or not. If, for example, 10 points is a maximum and it is required to score at least 5 in order to pass, the results will be divided into two groups only: passing and failing, with 4 being the highest result of failing and 5 being the lowest result of passing.

            Decision Table Testing

            When your aim is to work out how the system actually works, decision table testing is your choice. In this method, all combinations of inputs and ways the system responds are presented in the form of the table. Using this method, you can be sure that logical conditions and business rules have been checked. This example, just as the method, may be a little bit more complicated, but imagine a bank offering their client $100 if and only if they are ready to deposit $1000 in their new account and get a new credit card. If they meet two previous conditions and spend $1500 on their credit card, they can get an extra $50. The system should now check whether and how much money the client will get, and all the conditions and results can be shown like this:

Conditions:

 

 

 

 

 

 

 

 

Pay $1000 into account

Y

Y

Y

Y

N

N

N

N

Open credit card

Y

Y

N

N

Y

Y

N

N

Spend $1500 with credit card

Y

N

Y

N

Y

N

Y

N

Actions:

 

 

 

 

 

 

 

 

Pay $100

Y

Y

N

N

N

N

N

N

Pay $50

Y

N

N

N

N

N

N

N

 

State Transition Testing

If the way the system should respond rests on actions that took place earlier, a state diagram will most probably make testing clearer. After drawing one, it is highly recommended to prepare a list of all of the system's possible states and to find the transitions, i.e. ways to get from one state to another. Think of an application that changes the order status before the shipment and this is what you can get:

           

            Even though the four methods above are not all black box testing methods there are, these are definitely the most popular ones. As you can see, they all differ and the requirements you should meet in order to test an application effectively are rather specific, but hopefully, I made it clearer for you as to how essential black box testing and testing in general actually is.

 

Author Biography

Renata Wojnicka is our manual test engineer who makes sure all of our software solutions are flawless. In her free time, she enjoys studying history, riding horses and sailing.

We use cookies to improve performance and enhance your experience. By continuing to use this website you are agreeing to use our cookies.