What is Black Box Testing?

It is also known as behavioral, opaque-box, closed-box, specification-based, or eye-to-eye testing.

Black Box testing is a type of Dynamic Testing, an effective software testing automation, and it is an efficient way to evaluate the functionality of the Application Under Test (AUT)without analyzing its internal code structure.

It’s one of the most powerful methods of Testing because the tester doesn’t need to have deep knowledge about the product itself. It’s also the most well-used method of testing and occurs throughout the development cycle and Testing Life Cycle i.e in the Unit, Integration, System, Acceptance, and Regression Testing stages.

What Are the Techniques You Need To Learn?

When it comes to Black Box Testing, it usually involves 3 techniques to master.

A) Equivalence Class Partitioning:

Equivalence Class Partitioning (or Equivalence Partitioning, or EP for short) is an all-around specification-based black-box technique. It is extremely easy to understand, very common use, and approached in such simple logic that a majority of testers apply or figure it out just by reading specifications alone.

In this method, the input domain data is divided into different equivalence data partitions (or classes). Then, we test only one condition in each of those partitions. This method is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements. “Maximum requirements” here are emphasized, because certainly, it won’t be able to cover all the requirements. This coverage risk can be reduced when this technique is used alongside with Boundary Value Analysis technique, which we will cover later.

For example, to test an age restriction system for opening an account at a bank. In the specification, the user is required to be over 18 to be able to open their own account. To test this system, first, we must identify the range of ages (or partitions) that can and cannot create accounts as below:

Valid partition: age>= 18. Input value: 19
Invalid partition: 0<=age<18. Input value: 5
Please note that we have identified 2 partitions, not just the one
mentioned in the specification. As a tester, it is important to test every possibility, especially the ones that are not specified yet. In our experience, that’s where most of the bugs are found, as missing information in specification can become a developer’s mistake, then later translate into a defect in the system.

However, all the possibilities should still come from the realm of reality: as in this case, the age must not be smaller than 0. If a system allows input negative value into age, the test should not be connected with the “the user is required to be over 18” requirement, but it should be for a logical validation error such as “Age cannot be negative”.

After we identify the partitions, we only have to choose 1 value from each partition and test those values. In this case, we chose the age value of 19 for the valid partition and 5 for the invalid partition. One might wonder if we have missed some values: There are 19 numbers between 0 and 18 in the invalid partition and even more numbers from the valid partition, and we only test 1 in each of them.

It is an understandable concern, but this is how Equivalent Class Partitioning works: To cover every partition with the lowest number of test cases possible. If you want to not only cover every partition but also check their range, you will want to use the next technique.

B) BVA or Boundary Value Analysis:

Boundary Value Analysis is a Black box testing technique that focuses not on the partitions, but on the boundaries between them. In any case, this is where many bugs would occur. Bugs found by this technique are called boundary defects.

To use this technique, first, we also need to identify all the partitions (just like with Equivalence Class Partitioning). After that, we pick the maximum value and the minimum value possible for each partition (Valid and
Invalid) to test.

Consider the age restriction system described, with 2 partitions (1 valid and 1 invalid), using this technique, we choose our input value as below:

Valid partition: age>= 18. Input value: 18
Invalid partition: 0<=age<18. Input value:17 These input values signify the boundary between the partitions, also the range of each partition. Please note that there are partitions that would have fewer values picked from another (Namely the Valid partition: age>= 18. Input value: 18). This is called an Open Boundary.

C) Using the 2 techniques together:

Equivalence partitioning and Boundary value analysis (BVA) are
closely related and can be used together at all levels of testing. Listing out
partitions and boundaries when designing test cases, and we can test many partitions and boundaries with the fewest data possible.

For example, for an Employee ID system in an ERP (Enterprise Resource Planning) package has 3-digit numbers from 100 to 700, we can identify the partitions and boundaries as below:

1. 1. 1. Digits: With characters from 0 to 9 are the valid partitions (with boundaries of each digit being 0 and 9) and non-digits for invalid partitions.
      2. Number of digits: 3, so 2 and 4 digits will be the invalid boundaries)
      3. Range of the ID: 100 to 700 are valid boundary values, and 99 and 701 are invalid boundary values.
      4. IDs that are taken would be in the invalid partition and those that are not in the valid partition.
      5. If the IDs rise sequentially and automatically, the highest IDs could also be used as boundary values.

With the partitions and boundaries listed out, we can identify some data that can help us test multiple partitions and boundaries at the same time. For example, ID 390 can test valid partitions of (1) and (2) at the same time. Plus, ID 390 can test all the valid boundary values of (1) because it has 0 and 9 in it. Thinking like this will reduce the number of test cases significantly, and thus reduce the number of tests needed to be executed.

However, one important note is while multiple valid partitions or boundaries can be tested at the same time, sometime multiple Invalid partitions and Invalid boundaries should not be tested in the same test case. The reason is some systems might stop processing when they encounter the first problem, and only appear the error for that specific problem only. In the case of the example above: we should not test ID 1000 for (3) and (4) at the same time because the system might stop processing from (3) and only appear error of (3) without checking (4). If the system is not stopping at its first problem, or multiple error messages can appear at the same time, then you can proceed to test multiple of them without a problem.