When it comes to software testing, you will hear many fancy words like blackbox testing, whitebox testing, redbox testing, graybox
testing, monkey testing, gorilla testing and the list goes on. Out of these, the words that have become almost an industry standard are Black box testing and White Box testing.
Black-box and white-box testing are commonly used on numerous testing techniques. In this article, we will discuss the definition, use and the techniques of testing for the two.
Black-box Testing
A testing technique that focuses on the functionality of the program and it is compared against the specifications without knowledge of how the system is built. Also, this technique is usually data or business process driven; this technique determines if combinations of input data and expected results are produced correctly thru operations. As a tester, it means testing a black box without understanding the program code or be able to read the program code. The tester should understand how the processes on the program work through exploring the program’s UI and functionality. It is usually used on System Testing and Acceptance Testing.
What are the techniques used in Black-box?
The input data is critical when creating test cases through black-box. Below are the three techniques used for managing the amount of input data required.
1. Equivalence Partitioning
Specifications followed in testing are partitioned in the set of all possible input data into classes that receive equivalent treatment. Equivalence Partitioning results in identification of a finite set of functions and their respective associated input data and output results. The known characteristics of these functions can develop test data.
Example of Equivalence Partitioning: A program that will accept credit card as a mode of payment with a minimum purchase of $50 and cash out is allowed, but maximum cash out is $100.
The equivalence classes would be:
- Less than $50 of purchase for credit card payment is invalid.
- Greater than $50 purchase for credit card payment is valid.
- $1 to $100 for cash out is valid.
- Greater than $100 for cash out is invalid.
2. Boundary Analysis
This technique will help narrow down the possible test cases through focusing on the input and output of a given function. This technique will help to avoid exhaustive testing as it lessens the test cases for every equivalence class. This technique is only applicable to variables with fixed values.
Example: On a store, to be awarded a 10% discount, the minimum amount of a customer should purchase is $100 to $200.
- Low boundary +/- one ($99 and $101)
- On the boundary ($100 and $200)
- Upper boundary +/- one ($199 and $201)
3. Error Guessing
This technique is used to find defects on the program and develop test cases. It is used by a tester based on his/her experience in testing and familiarity on the module.
Example: The system time on a program uses a 24 hour format. The tester now then develops test cases to see how the program would respond to a different time format, thereby exposing any defects, if any.
White-Box Testing
It is a testing technique that presumes that the path of the logic in a program unit or component is known. It consists of testing paths, branches, and coverage of the code written, to deliver predictable results. This is technique is usually used on Unit Testing, where a developer tests a particular module or unit of code is working properly. As a tester, it means being able to learn the parts of the code that you will test to spot the weaknesses of the program.
What are the techniques used in White-Box Testing?
Statement Coverage
100% statement coverage means all statements in the program are executed at least once during testing.
Decision Coverage
100% decision coverage means all decision directions are executed at least once during testing.
Condition Coverage
100% condition coverage means that each decision with all possible outcomes is executed at least once during testing.
Decision/Condition Coverage
100%decision/condition coverage means all possible combinations of conditions with all possible outcomes are executed during testing.
Multiple Condition Coverage
This means to invoke each point of entry at least once in testing.
Developers can choose the combination of techniques that are suitable for the program. Not that too many combination of these techniques may lead to unmanageable number of test cases.