All Info About Grey Box Testing (With Examples)

Web App Testing

Thursday April 18, 2019

The method of testing a software system – application or product, externally and internally by using a combination of “white box testing” and “black box testing” approach has its own pros and cons.

The action is carried out with limited or partial knowledge of the internal workings of the software application.

With a view to conquering the deficiencies and ambiguities found in such type of testing, Grey Box Testing (also spelled as Gray Box Testing) has been developed as a productive merger of white box and black box testing.

White Box testing – the internal structure (code) is known

Black Box testing – the internal structure (code) is unknown

Grey Box Testing – the internal structure (code) is partially known

Grey Box Testing Methodology

First – White Box Testing to study and gain a basic understanding of the internal features of the application.

Second – Design and define test cases based on thorough knowledge and understanding to cover each and every aspect of the application.

Third – Black box testing to execute developed test cases to externally test the qualities of the software application.

Best Suited Applications:

Grey-box testing is an ideal fit for Web-based applications.

Grey-box testing is the best technique for domain or functional testing

Grey Box Testing Strategy

It is not necessary in Grey box testing that source code is required by the tester to design test cases. To carry out this testing process, test cases can be designed based on the algorithm, knowledge of architectures, internal states or other advanced descriptions of the program behavior.

It utilizes all the clear-cut techniques of black box testing for function testing. The generation of a test case is based on requirements and presetting all the conditions by assertion method.

The standard steps to carry out Grey box Testing are as follows:

Step 1: Selection and identification of inputs from White-Box and Black-Box testing inputs.

Step 2: Identification of probable outputs from the above-selected inputs.

Step 3: Identification of all the key paths to pass through during the testing phase.

Step 4: Identification of sub-functions to carry out deep level testing.

Step 5: Identification of inputs for sub-functions.

Step 6: Identification of likely outputs for sub-functions.

Step 7: Execution of a test case for sub-functions.

Step 8: Verification of the appropriateness of outcome.

Step 9: Repetition of Step 4 and 8.

Step 10: Repetition of Step 7 and 8.

Security-related, GUI related, Database related, Browser related, and Operational system related testing are all part of the test cases designed for Grey Box testing.

Grey box testing Techniques:

Matrix Testing

Matrix testing, a technique coming under Grey Box testing, defines all the used variables of a particular program. In any program, variables are the essential elements through which values can move through the program.

It should be on par with the requirement without which the readability of the program and speed of the software will be reduced. Matrix technique is a way to eliminate uninitialized and unused variables by identifying used variables from the program.

Examination of inherent risks like technical risks and business risks that are associated with the variables with different frequency labeled by the software developer is carried out under this type of testing.

Design of test cases becomes smooth and easier when all of this information is summarized in two types of tables as in the following example:

All Info About Grey Box Testing (With Examples) All Info About Grey Box Testing (With Examples)

From the information in the above two tables, the testing analyst can immediately make out that the technical and business aspect of the code, namely saving and deleting records requires testing.

Regression Testing

This type of testing is carried out after executing a functional development or repair to the program.

To verify whether the modification in any of the previous version of the software has regressed or caused any unintended or adverse side effect in other aspects of the program in the new version, the following testing strategies can be pursued:

  • Retesting within a firewall where dependencies are analyzed for choosing baseline tests
  • Retesting risky use cases where the risk factor is considered
  • Retesting all existing test cases
  • Retesting by profile where time is allocated in proportion to the operational profile
  • Retesting changed segment where code changes are compared for choosing baseline tests

At some stage in confirmation testing, if any defect got rectified, and that part of the software started functioning as intended, there might be a possibility that the rectified defect may have initiated a different defect somewhere else in the software.

Here, regression testing takes care of these types of defects by utilizing the above-mentioned testing strategies. The tester, as a reference, may use 80% of the allowed time to run existing test cases and 20% of the allowed time to execute exploratory testing.

Orthogonal Array Testing or OAT

The intention behind this testing is to locate defective logic in the system by providing coverage with the maximum code as well as GUI functions and with minimum test cases in a statistical and organized way of software testing.

Complex applications and e-comm products can be tested with this technique. Orthogonal Array Testing is composed of an array of values in which a variable is represented in each column and a test case is represented in each row.

A simple example is as follows:

All Info About Grey Box Testing (With Examples)

By conveying values for each factor and then of course, extrapolating for combined pairing, the total number of test cases will surely come down to nine from 27.

Though simple, this effective technique helps in maximizing the required testing coverage.

Pattern Testing

This testing is carried out by using the record of analysis on the historical data of the previous system defects. These analyses may contain specific reasons for the defect or bug with information on the problem that has been addressed, applicable situation, generic test cases, etc.

Unlike black box testing, grey box testing plows within the code to determine the reason for the failure so that they can be fixed in the next software. It is noteworthy that pattern testing is applicable only to such type of software that has been developed by following the same pattern of previous software as the possibility of similar defects occurs in this software only.

Generally, Grey box methodology employs automated software testing tools to conduct the testing. Module drivers and stubs are created to relieve the tester from manually generating the code.


Grey Box Testing is said to be performed when –

  • The codes for two modules or units are studied for designing test cases which is the White Box Testing method and then
  • Actual tests are conducted using the exposed interfaces which are the Black Box Testing method.

For example, during testing of Drupal website containing links, if an error crops up while clicking that link, changes can be made in the HTML code for further checking. Here the user is carrying out white box testing by altering the code and black box testing by testing on the front end.


Nowadays in this modern world, nobody is indisputably safe from cybercrime irrespective of whether it is a big corporate or an individual, government organization or non-benefit association.

The potentiality of becoming a cybercrime target looms large. Grey box testing comes up as a priceless tool for securing security in software. Significant vulnerabilities can be uncovered by giving in less effort and cost.


Hire a Tester


Call Us