Difference between white box, black box and grey box testing | DeviQA
DeviQA Logo

Difference between white box, black box and grey box testing

Published on:
Difference between white box, black box and grey box testing

So. You are here and want to know the difference between those types of testing. Even if you just came here by mistake or wanted just to know what these boxes are, stay ahead and we would definitely share our knowledge with you.

These boxes are not just containers. These boxes are symbols.

Let us take Black box. I mean imagine real black box. Try to see what is in it. You focus your eyes but fail. Black color is very very dark and nobody will see what is inside. Now let's take your favorite application (web/mobile/windows it does not matter). Try to see what is inside. I bet that you have failed. That's because you see final product which was provided to customers. You, of course, will be able to test something here and you will probably find a lot of bugs and this type of testing is very important since you see same things as any customer does. Also, as any customer you will not see any details or reasons why this bug occurred and sometimes you will not see even a bug itself because dev has not defined any error message for it. So if we talk about Black box testing it is some kind of very useful one but it is blind testing. Automated testing have superior benefits from Black Box testing since it does not require any access to database and codes and covers almost every use case that could be faced by final client.

Black Box:


Is the fastest way to find:

incorrectly implemented or missing functions;

interface errors;

errors in data structures or organization of access to external databases;

behavior errors or insufficient system performance;

testing is done from the position of the end user and can help to detect inaccuracies and contradictions in the specification;


writing tests may be a problem if specification is not well written or missing;

some of tests may be overdone since same checks have been already done by dev during code reviewing;

scenarios are very narrowed by specification and only a very limited number of ways to execute the program will be tested.


You have web application which is allowed only for registered users. Each user after logging will be redirected to specific environment. Using Black Box method you will be able to test validation of several fields and that some environment opens as expected. But you will not be able to check scenarios like changing assigned environment to user, user expiration etc.

White color is a symbol of purity. In scope of testing let's call it Glass Box. On the one hand glass is transparent material and we are able to see what is behind. Same things is with testing. You will see every change of every variable element. On the other hand glass is very fragile material and it will cause a lot of configuration problems in testing when one of variables that you set is incorrect. So white box is very powerful and means access to data base, codes, applications etc. Pay attention that this type of testing requires a lot of knowledge and is also an extremely time consumed. You will be able to cover 99% scenarios using it but remember that usually it is not necessary for project as most of such cases are not use-cases and customer will never face them. Most of the time devs use it when perform their unit tests during code review flow in order to find obvious bugs in code.

White Box:


Full access to the configurations;

Full access to the code;

Full access to server side if you will use proper software.


Time consuming testing;

A lot of cases are not use-cases;

Requires really a lot of knowledge;

Requires full code understanding.


Same web application with log in page. You will be able to test every field and will be able to test validation according to code and not according just to specifications and logic. It is possible that upper case does matter or clicking on some unusual place cause an error. So you will have a lot of scenarios and most of them will not be use-cases and final user will never do such actions. If your project could afford testing which covers ~90% scenarios then you can use this method in all times of course if you have knowledge for it.

So in order to know the difference between White and Black Boxes we should define what is the same in all those types. And really the same thing is the Grey Box. Now we have come to the most important type of testing nowadays that is most used by QA. Grey Box. It's like glass which was covered by dirt which provides not perfect view through it but it is better than black glass and will not shock you by all stuff in it as crystal glass. This partial access is perfect in terms of testing for any QA.

Grey Box:


Devs are able to not just review their code but able to see results on already developed applications;

Testers are able to prepare test cases which will cover on the one hand all possible use-cases and on the other hand will cover possible errors in code;

Is very effective on big projects when there are a lot of modules with different configurations for each and nobody knows exactly real connections between them;

All positive sides from White Box are used during preparing configurations and from Black Box during testing.


Requires good communication between Devs, Testers and Products;

Requires a bit more knowledge and time in comparison to Black Box testing;

Mostly used for testing web applications;

Not user-friendly for software which is used for writing automation tests due to a lot of number of possible configurations;

Requires good written specifications documents (same as Black Box).


Same web application with log in page and different environments assigned to each user. Using Grey Box you have list of specifications and you are able to prepare configurations by yourself in order to test all stuff that might be occurred with final user. So this technique of testing is much deeper. It's require a lot of talking between devs/testers/products which is also time consumed but your project will be rewarded with improvements that come from such conversation. And those improvements will be implemented not because final user complains and version was published but because during talks about new feature tester/dev or product comes up with new idea before even code has been written.


So in other words combination of White and Black box is also a combination of power of all members in your project and having such different points of view could make huge impact on Quality Assurance for all project.