>> White Box <<
White Box testing has one big advantage over the Black Box testing logic - you have knowledge of how the system works. With that knowledge, you can delve into the system at hand, and split it up into subsystems for smarter tests and clearer analysis. For example: when you bump into a problem you don’t have to stop the test cycle. As you know how the system is built, you can work around the problems and continue the test to reveal more deep rooted problems. This means that you can catch multiple bugs in just one test cycle - rather than having to run multiple test cycles.
This tactic saves a great deal of time and energy. Ultimately, the advantages of White Box testing are the disadvantages of Black Box testing.
The downside to White Box testing is that testers could be biased because of their ability to look inside the application. Perhaps even subconsciously, they may use this additional knowledge to influence actions that might not have been taken otherwise to verify a complete user environment and experience.
>> Black Box <<
There are two key advantages in Black Box testing:
1. It’s pretty simple in terms of how it’s applied to performance and load testing. The tester doesn’t need any knowledge of the internal operations of the application - he/she is only expected to focus on the user actions or inputs and expected outcomes. This makes the test easier to create and maintain. Once the load scenario is defined properly, the test can be carried out.
2. This type of testing enables the tester to closely reflect user actions. The user has no real knowledge of what’s inside the box. Therefore, the tester is acting more like a user and less like a developer. As a result, he/she may uncover bugs that might not have been otherwise found.
One of the greatest challenges that remains is properly defining the test scenario. Due to the fact that the tester does not observe or comprehend what’s happening within the application, they will often simply replicate the typical user flow. Without a solid knowledge of the apps internal operations, the Black Box tester creates scenarios by producing various input combinations. With this method, it’s difficult to pinpoint which one of the scenarios will have an effect on a specific aspect of the system.
Let's say you run a performance test with certain numbers for performance results in mind. You run a test and it fails. When developers look at the test, they fix the first problem they encounter, assuming it’s the only problem. But then they discover that there’s another bump in the road further along in the test, and the cycle is started once again: they stop the test to fix the bug, again unaware of potential bugs down the road. Eventually you end up running multiple test cycles as you have to stop a cycle every time a failure occurs.
Black Box testing could also be viewed as a more ‘shallow’ and potentially risky method. It’s virtually impossible to test everything. However, when you have knowledge of what’s inside the box (as in White Box testing), you can make smarter choices on what to test. Without this knowledge, you’re blindly testing and therefore taking a greater risk of not testing the key elements that need to be tested.
Which is Better?Edit
The most efficient solutions come about when developers find their own bugs right from the start. That way they are able to ensure a high quality, speedy solution. When QA finds bugs after applications have left the developers’ hands, additional people and resources are involved, inevitably elongating the process. The worst case scenario is when a customer reports a problem. In such cases, the developers, QA, and deployment engineers have already worked on the product that has ultimately led to an unsatisfied customer. Not only have you failed to live up to the client’s expectations, but you have to repeat the entire process from the beginning, costing the company more time and money.
Looking inside the box, especially for load and performance testing, is a better strategy. While Black Box is the easier approach, it’s bad from a business point of view as it takes you into a larger number of cycles, meaning you need to spend more time and money. With the White Box, you put more effort into the initial stage (looking inside the box, considering the architecture etc.) but you can build a better procedure which reveals much more information in each cycle.
However, real-life is not all black and white. So the ‘Grey Box’ approach is a pragmatic compromise. The Grey Box mixed approach uses the Black Box testing at times and the White Box testing at others. Once the concepts of White and Black Box testing are understood, Grey Box testing is an obvious alternative and, in my opinion, a light Grey Box would be an even better option. When you have two opposing concepts, generally selecting an option in the middle is your best bet.