For a better understanding of software testing approaches, you need to know what methods of testing exist. The key difference between methods hides in the knowledge of the internal structure of the test object. This way we can distinguish "black-box", "white-box", and "grey-box" testing. Each of these methods offers different possibilities, which we will explain in this post.
"Black-box" testing
Black-box testing, also known as specification-based testing or behavior testing, is a technique based solely on the external interfaces of the system under test. In other words, we do not know anything about system implementation and interact with it in the way a regular user does. The purpose of this technique is to find bugs in the following categories:
Thus, we have no idea about the structure and internal structure of the system. You need to focus on what the program does (not how).
Advantages:
- testing is performed from the perspective of the end-user and can help detect inaccuracies and inconsistencies in the specification;
- the tester does not need to know programming languages and dive deep into the features of the program implementation;
- testing can be performed by specialists independent of the development department, which helps to avoid conflict of interests;
- you can start writing test cases as soon as the specification is ready.
Disadvantages:
- only a very limited number of program execution paths are tested;
- without a clear specification (and this is more likely a reality on many projects) it is rather difficult to create effective test cases;
- some tests may be redundant if they have already been conducted by the developer at the unit testing level.
"White-box" testing
White-box testing is the opposite of the black-box. This method assumes that the internal structure, design, or implementation of a system is known to the tester. We select the input values based on our knowledge of the code that will process them. In the same way, we know what the result of this processing should be. Knowledge of all the features of the program under test and its implementation is a must for this technique. White-box testing goes much deeper into the internal structure of the system, beyond its external interfaces.
Advantages:
- testing can be done at an early stage: there is no need to wait for the user interface completion;
- more thorough testing can be done, covering a large number of program execution paths.
Disadvantages:
- a lot of specialized knowledge is required to perform white-box testing;
- when using test automation at this level, maintaining test scripts can be quite overhead if the program changes frequently.
"Grey-box" testing
Grey-box testing is a software testing method that involves a combination of white-box and black-box approaches. We only partially know the internal structure of the program. It is assumed, for example, that an engineer has access to the internal structure and algorithms of the software for writing the most effective test cases, but the testing itself is carried out using the black-box technique (from the user's position).
Advantages:
- as grey box testing is a combination of the black-box and white-box testing, it provides the best of both worlds i.e. benefits of both the testing techniques;
- for grey-box testing, functional specifications and other design documents are used; it does not need the use of the source code which helps in keeping the source code safe from any disruptive changes;
- grey-box testing results in the instant fixing of the issues as a tester can change the partially available code to check for the results.
Disadvantages:
- while doing grey-box testing, testers do not have access to the source code, so it becomes difficult to get complete code path coverage and testers might fail to notice some critical errors;
- algorithm testing is not possible as accessing the complete logic of the algorithms is not possible;
- grey-box testing is usually not suitable for distributed systems.