Traditionally, software testing is divided into two major methods:
* Black-box testing is used for running tests from the user’s point of view, being focused on the application’s functionalities, features and also design. An important advantage of this testing method is that it’s inexpensive, it’s performed exclusively from the application’s user interface and no implementation knowledge is required whatsoever. However, black-box testing has quite a few disadvantages, such as: not all possible paths can be realistically tested within an adequate time-frame, or that the cause of the issues found may be hard to determine by the output of the user interface alone.
* On the other hand, white-box testing is employed for testing mainly the internal workings of an application (the source code) rather than its functionalities. For this type of testing programming knowledge is a must and is required in order to design test cases. This is the main reason why most of the time this type of testing is performed by developers and not by testers. As a consequence, this type of testing is considered to be more expensive than black-box testing. Even more, testing the whole code of an application is nearly impossible, as there are numerous paths that could be tested in a module and in the interaction between modules. Also, white-box doesn’t have the objectivity of black-box testing, as tests are performed by programmers (the ones in charge with the development).
Most projects use these two testing methods complementary, white-box is preferred for unit testing and optimizing code, while black-box testing for integration testing, system testing and acceptance testing (although it can be applied successfully to any testing level).
Apart from these two testing methods, another methodology has become more and more popular: gray-box testing. Gray-box testing attempts, and generally succeeds, to combine the benefits of both black-box and white-box testing methods, thus cancels out some of the flaws of each testing method when used individually.
Gray-box testing takes the straight-forward approach of black-box testing, but also employs some limited knowledge of the inner workings of the application. Therefore, a tester can verify both the output of the user interface and also the process that leads to that user interface output. Gray-box testing can be applied to most testing phases, however it is mostly used in integration testing.
A tester with little programming knowledge can create test cases based on the code, and then apply them to the user interface elements of the application. This way, the whole process is tested not only the output, eliminating some of the major problems of black-box testing: the difficulty of determining the cause of the issue, “blind” testing that can become time consuming and sometimes completely misses important issues.
Let me give you an example: you have an application that manages the employees of a company and you need to test the process of adding an employee. The form contains fields for various information (phone numbers, emails, address, etc.), so there are values of different types. If the black-box tester will have to create test cases for all possible combinations of types of values, for each field, the gray-box tester has access to the database and knows exactly what type of value each field has. So he can design test cases with specific vulnerabilities in mind, but he’ll also cover possible user interface issues, as this is where he will apply his test cases.
The advantages of using gray-box testing are obvious, it combines the strengths of both black and white testing, it’s non-intrusive, as testers don’t have access to the entire code, testers can author better test cases due to the extra knowledge of the application and more. However, gray-box testing inherits some of the disadvantages of black and white box testing methods, such as: the fact that it can only achieve partial code coverage and it requires better trained testers.
Overall, gray-box testing has become a popular testing method, and some testers don’t even realize that they use it, as even the most untrained tester can pick up on tips and tricks about the inner workings of applications, given enough experience. So the process of upgrading from black-box testing to gray-box testing is a natural one, its speed depending only on the determination of the tester, and on the characteristics of the development process.
More precisely: if the process is based on the effectiveness of the black-box testing, as a “non-biased” and “agnostic” method, then gray-box testing will work against that. But if the development process tries to accumulate the benefits of both black-box and gray-box (for example, some of the members of the testing team can use exclusively black-box testing, while others are also allowed to rely on white-box), then gray-box testing is also a good option.
