An introduction to black-box testing
In this blog post, I will go over the black-box method of software testing. Often referred to as specification-based testing. This software testing method can be applied as soon as the user requirements are formed, allowing for testing activities to begin as early in development as possible.
But what is black-box testing? What sort of tests can the method be used in? And why are we using a box to perform software testing?
Black box testing 101
Black-box testing is the process of software testing in which the software tester has no knowledge on the internal workings of the application they are performing their tests on (hence the term ‘black box’).
Testing using this method is focused primarily on what the software does, not how it does it. Meaning the software tester designs their test cases around the inputs and outputs of the application.
An example of black-box testing would be a tester verifying a smartphone app using their taps and swipes and comparing the outcomes against a list of expected operations.
While often associated with functional testing methods and whether the application is doing what it has been designed to do. Black box testing techniques can also be applied to non-functional testing methods, such as testing the security of an application, or the performance, in which the tester is only able to measure how the software performs. Not assess the internal structure of the application.
What are some black-box test techniques?
As mentioned above, black-box testing techniques focus solely on the inputs and outputs of the application. And as highlighted in another blog post (The Seven Principles Of Software
This leaves the tester with a problem to solve since testing every single input/output combination isn’t really possible (unless it is a very simple application). So instead, a decision has to be made on the most effective test cases that will ensure the highest coverage of possible inputs by the end-user.
There
But here is a couple of them with examples to show how they are used to test software.
Equivalence partitioning
Let’s take the example of a password field on a website that accepts a word with a length of 8-14 characters to be considered as valid a password.
In equivalence partitioning (EP), we break the inputs down into ranges (or classes) and an assumption is made that the behavior of all members of that range will behave the same.
We then take one member of each range and design a test case for it.
So the ranges of valid and invalid partitions would look like this:
0 – 7 : Invalid
8 – 14 : Valid
15 > : Invalid
The advantages of using this technique
Boundary value analysis
Much like equivalence partitioning. Valid and invalid ranges are first worked out and then test cases are instead designing to target where the boundaries where the invalid and valid values lie.
So if we take our password example from above.
7 : Invalid.
8 : Valid.
14 : Valid.
15 : Invalid.
The advantage of this technique is your test cases are covering those instances in the software where things are changing, and so more likely to catch defects or errors.
Boundary value analysis and Equivalence Partitioning are rarely used in isolation of each other and are often combined to ensure that inputs are being tested on the edge and within their acceptable values.
Conclusion
Black-box testing as we have seen is a testing method that can be performed by anyone on the testing team. They do not need to understand programming, or be technically minded as tests are performed from the perspective of the end-user and how they would interact with the software.
Black box testing is often compared with white box testing which is the subject for a future blog post.
