(Reproduced from Kaijun Michael Fu and Philip Noor

(Reproduced from Kaijun Michael Fu and Philip Noor. Software Testing.)

There are two basic approaches in test design: black-box and white-box.

Black-box test design treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal code and structure. Black-box test design is usually described as focusing on testing functional requirements, external specifications or interface specifications of the program or module. The ultimate goal for black-box testing is to test every possible combination and value of input. It is sometimes desirable but it is impossible to test all the input for a program with a bounded schedule and budget.

White-box test design on the other hand allows one to peek inside the "box", and it focuses specifically on using internal knowledge, like logic, of the software to guide the selection of test data. The test is to test to the code or its logic with little or no regard to the specifications. The ultimate goal is to test every execution path through the program logic.

Some further detail.

White box testing (also known as unit testing) is one of the most popular testing approaches. To white-box test means that the tester should read and use the source code of the applications being tested, through which, applying test cases and various inputs in order to test branches, conditions, loops and the logical sequence of statements being executed. To test the software using this approach is beneficial, it helps in finding bugs that are hard to find through normal usage of the application, this usually needs an expert eye, i.e. a good programmer. In some cases, testing the code in real environment could be costly, thus white-box testing provides a good bug detecting approach before giving the software to the customer. In the same time, white-box testing requires a considerable period of time to finish; it is somehow a slow approach. It also requires a good programmer to do it; a regular user will not do since the tester should also be familiar with the programming language used. In some cases, the developer is asked to test his own code using a white-box test approach. This is good since the best person to know the code is the one who actually wrote it, but this approach also has its disadvantages. The developer will always have the same perspective towards the approach of solving the problem, thus, the special cases that he missed when actually building the program will probably stay un-noticed. From my point of view, I think that a developer can never test his own code, at least it should not be the only test made before the release of the software. I also see that if a company is giving a developer his own code to test, this could mean that there is lack of convention between developers in writing code, and it is considered hard for a developer to understand the code written by another developer. To overcome this problem, now some tools exist that can generate a code written in a specific style depending on the convention used inside the company. White-box testing is also a hard task when done by a different developer. The other developer will also miss the experience of the main developer that he gained while developing the application. Another issue is that the fact of actually having two - or more – developers spending time to understand the same problem in order to build and test it means more wasted time and personnel, i.e. resources.

Black Box testing (also known as functional testing). Testing using this approach means testing the functionality of the application and checking if it is the same functionality required, i.e. check if this is what the program has to do. Testing using this approach does not require understanding the programming language – like the white-box approach- but it requires a full understanding of the problem and the functionality it should provide. The tester will be simulating a user's regular use of the system, or a customer test. He should be pushing the application to its limits to see how "tough" it is, this can be done through entering valid and invalid inputs and checking how the application will respond to this. E.g. if the application fails when given lots of input, this means it is not a "heavy duty" piece of software.