It is said for testers “Choose the right approach to deliver quality products”. A tester usually faces the dilemma in choosing a “White box” or a “Black box” approach for testing their application. Yes! Here we are talking about the two predominant test methodologies: White box and Black Box testing.
In this article, we have considered the following points to give you a good concept of the White box and Black box testing techniques.
- What is White Box Testing (with example)?
- Why and When to Perform White box Testing? Along with its advantages.
- What is Black Box testing (with example)?
- Why and When to Perform Black Box Testing? Along with its advantages.
- Difference between Black Box and White Box Testing
What is White Box Testing?
The White box testing is a type of testing in which only internal structures or workings of an application is tested. It is usually performed by the team members who know the code, usually developer. Since the developers have an in-depth understanding of the project code, they are capable of making the changes in the source code easily and in a small time. In White box testing, a tester needs to have a good understanding of the code so that he/she can exercise different code paths using tests.
White box testing is also called:
- Clear Box testing
- Structural testing
- Open Box testing
- Code-Based testing
- Transparent Box testing
- Glass Box testing
The purpose of White Box testing is:
- To improve security
- Improve performance and reliability
- Test the flow of inputs and outputs through the application
- Improve design and ease of use
Let's see, how the approach of testing a Banking application is related to the concept of White Box testing in the below-mentioned example:
Usually, in a banking application, white box testing involves verifying the return codes from different authentication or validations service. For example, when we make payments online:
- the web application contacts an online Payment gateway
- Payment gateways talk with the application in terms of messages and response codes
These messages and codes are not directly visible to an end-user but are part of the web application's internal communication. A white box tester would write tests to verify that correct status codes and messages are received and sent by the application to the payment gateway. A White box tester will also verify that his/her application is responding correctly to those status codes and messages. This level of testing requires an understanding of the internal code of the application.
In Banking application, each and every feature is very critical, be it
- Log in to the system
- Fund transfer
- Change Address etc.
Each feature of the system is tested deeply before developer/tester proceeds to test another feature. Each and every line of the source code is checked along with its dependencies like in case of the Fund Transfer module:
- Currency selection
- Local/International transfer limits
- Adding beneficiary etc
are some of the features that are tested for every scenario. This type of testing involves checking the internal structure, flow, and source code of the application.
Why White Box Testing Performed?
White box tests are mainly used to detect logical errors in the program code. These tests focus on individual code units for e.g. classes. modules or subsystems.
By testing at the most granular level i.e source code of the system, you can build a robust system that works exactly as expected, and make sure it will not come as a surprise. The white box testing tests all possible scenarios that a system/the code under test is programmed to perform. When the testing is performed at such a granular level, most of the possible defects are exposed out. And the developers and testers will have the opportunity to evaluate if some or all of them need to be fixed.
The major techniques that help you run the white box tests successfully are:
- Statement coverage: This technique makes sure that each line of code is tested.
- Branch coverage: This technique ensures that all branches (for example, true or false) are tested.
- Path coverage: This technique tests all the possible paths/routes.
When to Perform White box Testing?
White box testing emphasizes finding bugs before it goes to one step above in the development process. It can be applied at all levels of system development, especially in Unit, System and Integration testing.
When performing Unit testing, developers can make changes to small units/components in case of any enhancement or bug fix. This reduces the cost and time in the project.
As with the black box testing, there are different advantages for the white box testing also. Here are some of the most commonly cited:
Application Analysis: Application analysis allows Developers to evaluate each and every section of code and how well they are linked to other sections of the code. While application analysis,
- Developers can figure out the non-relevant code which needs to be cut out or could be improved,
- Re-evaluate design of application from a scalability perspective.
Stability: The white box testing can offer greater stability and reuse of test cases if the requirement never changes. In White Box Testing the developer checks and updates the internal code for any bug fix or requirement change. When the same process has to be repeated, then the already designed test cases are used which saves time and effort.
The thoroughness: Thoroughness is the quality of being complete. In situations where it is essential to know that each code or path has been thoroughly tested, that every possible internal interaction has been examined, white box testing is the only viable method. In the example of a banking application, the feature of fund transfer is tested and all its derived paths like currency, national/international limit are also checked. When testing at the source code level, a tester can execute each permutation and combination that the program that can theoretically accept.
What is Black Box Testing?
Black box testing is a type of testing in which the tester only focuses on the inputs and the expected outputs, without knowing how the application works internally and how these inputs are processed. Tester treats the Application Under Test (AUT) as a black box. Calling the application as Black Box is a figure of speech to show that Tester does not know anything about it.
In the Black Box testing technique, the software tester does not worry about the internal mechanisms of an AUT (Application under test). Testers focus only on the outputs generated in response to the selected inputs and the execution conditions.
This is identical to the approach followed by end-users. They interact using GUI, not via code directly. They interact with an application by giving it an input and wait to get something back as an output. If the process works well, they get an acceptable result; if not, they experience a problem.
Let's take an example of an ATM machine to understand the concept of Black Box testing in a better way. As a general user, we perform the following functions at the ATM machine.
- Card Authorization
- Balance inquiry
- Cash Withdrawal
- Display Balance
- Generate receipt
You give input to the machine by just pressing/touching the buttons and the machine produces the desired output as dispatching the cash or displaying the balance etc. You don’t know anything about the internal functioning of the ATM machine.
Same way, in Black Box testing, testers aren't bothered about the internal functioning of the application which they are testing.
Why Black Box testing?
Black box testing is performed from the end-user perspective and it is also known as Behavioural Testing. This ensures that any gaps in the applications for real users are identified. Black Box testing tests by using both valid and invalid input from the customer and gives the desired output or the error message which ensures that the application works properly in both positive and negative conditions.
In the case of ATM machine example:
- If the user gives invalid input i.e if he/she enters wrong ATM PIN then the system gives an error message
- If the correct PIN is entered, the system navigates to the next step.
Thus both the aspects valid and invalid input can be checked in Black Box testing.
When to perform Black Box Testing?
Black box testing can be performed in various conditions and for various reasons, here are the some reason
- When we want to simulate how real users would use the application, we should do Black box testing.
- Black box testing also enables exploring the application, which can help us identify missing features, issues or incorrect behavior in the application. If we want to identify these things we should do Black box testing.
- Depending on the skill set of the team also we can decide to do Black box testing. For e.g., if we have a team of testers who are not skillful in programming, we should do black-box testing.
Black box testing is an essential type of testing, we should always make sure that our teams do Black box testing. It helps us remove any biases for the application and treat the application as a real user would do.
The black box testing has many advantages. Here are some of the most commonly cited:
- Easy to perform: Since the testers do not have to worry about the internal workings of an application, it is easier to create test cases by simply working through the application.
- Faster development of test cases: Because black box testers care about the GUI and different types of input that will be sent to the application. Identifying different GUI paths and the inputs generally require less effort compared to writing code as part of unit tests.
- Simplicity: When it is a big, highly complex application, the black box testing offers a means to simplify the testing process by focusing on valid and invalid usage of the application from the user's viewpoint. Ensuring that the correct outputs are received for all the most common user scenarios.
Difference between Black Box and White Box Testing
|Feature||Black Box Testing||White Box Testing|
|Definition||It is a form of software test in which the application is treated as a black box. The tester of the application does not know the internal workings of the application.||It is a way of testing software in which the tester/developer knows the internal structure of the code or software program.|
|Performed by||It is mainly done by software testers.||It is mainly done by software developers.|
|Objective||The main objective of this test is to verify what functionality the system has to perform.||The main objective of white box testing is to verify how the system is performing.|
|Programming knowledge||No implementation/code knowledge is needed.||Implementation/code knowledge is required.|
|Type of testing||It is a functional test of the software.||It is a structural test of the software.|
|Documentation||These tests can be initiated based on the requirement specified by the customer. By using the requirement specification document.||This type of test starts only after the team develops the design description of the software product. By using the detailed design document.|
|Execution time||This technique is time-consuming and exhaustive.||This technique is comparatively less time consuming as most of the tests are automated|
|Types||Functional Testing, Non-functional testing & Regression Testing||Path Testing, Loop Testing, Condition testing, Unit Testing & Integration Testing.|