In recent years, the third testing method has been also considered – gray box testing. It is defined as testing software while already having some knowledge of its underlying code or logic. It is based on the internal data structures and algorithms for designing the test cases more than black box testing but less than white box testing. This method is important when conducting integration testing between two modules of code written by two different developers, where only interfaces are exposed for test. Also, this method can include reverse engineering to determine boundary values. Gray box testing is non-intrusive and unbiased because it doesn’t require that the tester have access to the source code.
In the Gray box testing tester is usually has knowledge of limited access of code and based on this knowledge the test cases are designed and the software application under test treat as a black box & tester test the application from outside. Don’t confuse with White box & Gray box, as in the Gray box testing is tester doesn’t have the knowledge in detailed. Also the Gray box testing is not a black box testing method because the tester knows some part of the internal structure of code. So Gray box testing approach is the testing approach used when some knowledge of internal structure but not in detailed.
The name is comes because the application for tester is like a gray box like a transparent box and tester see inside it but not fully transparent & can see partially in it. As tester doesn’t require the access to code the gray box testing is known as unbiased & non-intrusive.
To test the Web Services application usually the Gray box testing is used.
The above diagram clearly describes about the role of all – Black (functional), Gray (functional and structural) and White (structural) box testing.
The white box testing means tester is aware of internal structure of code but the black box tester doesn’t aware the internal structure of code.
Gray box testing example
We will take example of web application testing. To explore gray testing will take a simple functionality of web application. You just want to enter email id as input in the web form & upon submitting the valid email id user & based on users interest (fields entered) user should get some articles over email. The validation of email is using Java Script on client side only. In this case if tester doesn’t knows the internal structure of the implementations then you might test the web application of form with some cases like Valid Email Id, Invalid Email ID & based on this will check whether functionality is working or not.
But tester is aware of some internal structure & if system is making the assumptions like
- System will not get Invalid email ID
- System will not send email to invalid email ID
- System will not receive failure email notifications.
In this type of testing you have to test the application by disabling the Java Script, it might be possible due to any reason Java Script is failed & System get Invalid email to process & all assumptions made by system will failed, as a result incorrect inputs are send to system, so
- System will get Invalid email ID to process
- System will send email to invalid email ID
- System will receive failure email notifications.