Black-Box Testing

What is Black-Box Testing?

Black-box testing is a kind of software testing that verifies if the software works for end-users as intended, without being concerned about its inner workings.

You are more focused on the product's interaction with the end-user than the internals of the product.

Black-Box Testing Analogy

Imagine you are looking to buy a new car, and you have a few options in mind. How do you evaluate which is better for you?

You will, most likely, take the car for a test drive and ask yourself:

• Is it comfortable to drive?
• Does it have enough power?
• Is the air-conditioning pleasant?
• Is the music system to your liking?
• Is the control panel easy to use?

You are not concerned about the internal machinery of the car. Instead, you are interested in its functionality and usability. This focus on the end-user is the principle behind black-box testing.

A Real-world Example

Let's take an example of black-box testing on the login page. Test cases will be based on how the end-user interacts with the login page. Some of them are:

• Users should be able to login with a valid ID and Password.
• Users should not log in with an invalid ID and Password, and the software should show them the correct error message.
• Border conditions like blank ID or Password checked
• Other links on the page like Remember me, Forgot password should take the user to the right pages.
• Here we are not concerned with how the login code works on the backend.

When is black-box testing used?

In most test cases where black-box testing is used, it falls under the following categories:

Functional Testing

In functional testing, you test every feature of the software to see if it works as expected. An example of functional testing is the testing of a website. You need to make sure all the website components, such as web pages, links, and sign-up forms, are functional.

Non-functional Testing

In non-functional testing, you aim to test the performance and usability of the software. After the website's initial development, you need to check it for responsiveness, speed, and usability.

Regression Testing

Regression testing is done after code fixes, software upgrades, or any other system maintenance to check whether the new code has affected the existing code or not.

Advantages of Black-Box Testing

Impartiality

testers can work independently of the developers and write test cases from the end-user perspective.

No programming skills required for testers

Low-skilled testers can test the application without any knowledge of implementation and programming language used.

Exposes flaws in functional specifications

Since the focus is on the user's perspective, it often brings out the software specification's ambiguities and discrepancies.

Disadvantages of Black-Box Testing

Lack of parallelism

You can write test cases from the software specification rather than waiting for the development to complete. However, testing can happen only after the entire software is developed.

Dependency on an exact and comprehensive specification

without such clarity, it would be impossible to write good test cases.

Duplication of work

It could be possible that some test scenarios have already been addressed covered in other areas like unit tests or white-box tests.

Redundancy can lead to the proliferation of test cases

While some scenarios may appear to be different, they can be the same, and hence there could be an explosion of test cases.

Covering all code-paths is difficult and time-consuming

Some scenarios, especially edge cases, may not be explored, and writing building a comprehensive test suite takes a lot of time and effort.

Black-box testing Techniques

You can use multiple black-box testing techniques to maximize the coverage while reducing the number of test cases required. The choice will depend on the functionality and input data. Some of the popular methods are:

Boundary Value Analysis

In this technique, the behavior of the software at the input boundaries is tested. Also, it is common to include a value from the middle of the input range.

You are testing a ticketing application for a top-rated museum that requires that a user cannot purchase more than 20 tickets at a time.

Using the boundary value analysis technique, you will test the application for 0, 1, 10, 20, and 21 tickets. The 0, 1, 20, and 21 are from the input range boundaries, while 10 is from its middle spectrum.

Boundary value analysis is a particular case of the equivalence partitioning technique, which we shall look at next.

Equivalence Partitioning

This technique, also called equivalence class partitioning, is used to divide the input data into groups (partitions) of valid and invalid values. The grouping needs to be such that either all values in a set are valid or invalid.

An example would be a phone number that can either be 10 digits (mobile) or 11 digits (landline) long.

You will divide the phone number input into the following equivalence partitions:

• Less than 10 digits
• Equal to 10 digits
• Equal to 11 digits
• More than 11 digits

Like the boundary value technique, you use this approach to reduce the number of test cases.

State Transitioning

This technique is used when the software behavior depends on past values of inputs.

Consider the example of your phone PIN. You have three attempts to get it right. After that, the phone permanently locks you out. Every time you get it wrong, an error message pops up, and you have to re-enter your PIN. Anytime during your three attempts, if you get it right, you are granted access.

While designing test cases of this example, it will be easier to think about states and state transitions, as shown above. It would help if you wrote test cases corresponding to all the arrows in the above diagram.

Decision Table Testing

This method captures different input combinations and their expected results in a tabular form and design test cases based on this table.

Let's take an example of a job portal where users can upload their resume such that:

The decision table will look like this:

If we constraint that the number of pages cannot exceed 5, there will be additional rows in the table.

Once this table is pready, you write one test case corresponding to every row.

Conclusion

Black-box testing is testing the software from the end-users perspective. If done correctly, it is an excellent way to ensure the system works in line with end-users expectations without worrying about the system's inner workings.