Black box testing functions on not knowing a software’s internal structure. This lack of information is necessary because, generally, the end user is not familiar with or concerned with how the system operates. The black box approach allows the tester to assess from the user’s point of view.
Black Box Testing Basics
The main focus of black box testing is inputs and outputs. A tester must first understand the requirements when testing a function. Having this knowledge allows them to develop different test cases based on expected outputs. Typically, the process starts with a happy path by entering a valid input that would provide the expected valid output. Other test cases are then created by entering invalid input and determining if the function provides the expected output under that scenario. Keep in mind the tester isn’t aware of how the data gets transformed.
Because of its nature and specified requirements, non-technical users can, or are able to, perform black box testing. It’s important to note that black box testing will not capture all testing scenarios or paths, but it does work well for functional testing.
Why is Black Box Testing Performed?
Let’s use an example. Sarah goes to the local market every week to buy produce. She looks forward to catching up with the cashier, Donna, who always asks her about her kids. However, this week when she goes to buy produce, instead of seeing Donna, there is a self-checkout kiosk. She has never used this type of machine before, and technology makes her feel a little apprehensive.
One of the main reasons we perform black box testing is so users will have a positive experience. As technology experts, we often see new machines as toys and can’t wait to try them out, but the majority of users are hesitant, like Sarah. As a result, when performing black box testing, we often position ourselves as users who don’t have any understanding of barcode scanners, payment gateways, APIs, or back-end microservices. For this type of user, the first experience could be a great one or a horrible one.
Black Box Testing Techniques
There are multiple techniques for black box testing. All of them can help make a user’s experience more pleasant. Deciding which one(s) to use will depend on the needs of the project or system under test.
Equivalence Partitioning
Equivalence partitioning divides data into sections where results are either valid or invalid. Each section can be tested, and the result would be the same for any value in that section. For example, a company wants feedback on a product targeted toward young adults, so they create a feedback form on their website. Included is a field for the participant’s age because they want users’ opinions between ages 18 and 29. Equivalence partitioning would look like this:
To test the field, we would enter at least one value from each partition. We could try to enter 15, 22, and 55, for example, expecting them to be invalid, valid, and invalid, respectively.
Boundary Value Analysis
Boundary value analysis is a type of equivalence partitioning in black box testing where the partitions contain numeric or sequential data. The boundaries are values that get tested. To test that the field responds correctly, we test each of the valid boundary values plus or minus 1.
The first boundary value in the valid column is 18. So we would try to enter 18 into the field but also attempt to enter (18 – 1 =) 17 and (18 + 1 =) 19.
Likewise, the other boundary value in the valid column is 29. We would enter 29, 28, and 30.
Decision Table Testing
If business rules are complex, a decision table is an excellent way to organize the conditions and actions of a system. For example, let’s say the company wants to give a 15% off promo for certain product users.
Business Rules:
Users must be aged 20-25 to qualify
Students get an extra 10 percent off
Must follow them on social media
We list our conditions and results in the table based on possible input options.
State Transition Testing
State transition testing is another black box testing method and is a way to assess different states of the system following an event. It is reflected using state transition diagrams and tables. These elements can help create the test cases needed to complete coverage for the business requirements.
Imagine our customers have made a purchase. We want them to be able to track their order status. We can create a state transition diagram to show the viable events and states on the order page. The range of an item’s status can be Order Received, Preparing, Shipping, Delivered, or Backordered.
Looking at the diagram, we can see the states and events that trigger the transition. For example, if the state is Order Received, an order is accepted (event) and can then transition to Preparing. Likewise, if the item is unavailable (event), the state will transition to Backordered.
We can make a state transition table to show possible scenarios by listing all feasible states as a column on the far left and again on the top row. Starting with the column on the left and working our way across, we can display the possible options, letting us know what we need to test.
Use Case Testing
Well-designed use cases imitate a specific interaction between a user (actor) and a system (subject). Use cases are performed based on the requirements of a specific function or as end-to-end system tests. Taking our first example of the self-checkout at the market, we could create different test cases for different users. For example, one user could be Sarah, who is unfamiliar with technology. For people like her, we could write tests to ensure the system is friendly, easy to use, and with help available. In addition, use case testing can identify what a system lacks. As a result, the product will have high quality and be more enjoyable for end users by resolving the issues.
Testing Tools
Many black box tests are good candidates for automation, and there are plenty of automation tools available on the market. Here are a few of the most popular.
- Selenium WebDriver – Selenium is popular because it can run using multiple languages and browsers. In addition, it is open-source, and although there are other contenders on the market, Selenium remains the most popular automation tool.
- Cypress – Cypress is another automation tool and claims to be easier to use than Selenium. It is also an open-source tool for end-to-end web application testing and can run on many browsers, but unlike Selenium, JavaScript is the only available test language.
- Appium – Appium is a popular automation tool for testing mobile applications. It is open-source and allows you to write tests using the same API for multiple platforms, like iOS, Android, and Windows.
Tips for better Black Box Testing
- Make use of personas if available. Marketing teams often provide these fictional customer profiles to help represent groups of users. Personas can be really helpful to testers because they can provide information about how a user will likely use the system and which functions and features they require. We can use this information to create use cases.
- Product management typically has tools that create workflows and diagrams. Collaborate with product managers using these tools to clarify business requirements.
- Consider the user’s point of view. Could your parents use the system? And what about your grandparents, or even your children? Consider who the end user of a system will be and evaluate their needs.
Conclusion
Black box testing does not require any special knowledge of a system’s internal structure. Instead, it is an opportunity for testers to evaluate how a system performs from a user’s point of view. There are several black box test techniques and tools to assist with testing.