Hello there! 👋
I'm Lucas, a Brazilian QA engineer, and this is Another QA Content nobody asked for (but i made it anyway 😂). My goal with this blog is to talk about things related to the QA world in my own way, giving my opinion and point of view. If you like it, follow me for more posts like this one!
The CTFL syllabus (2018) covers White-box and Black-box testing, but it doesn't mention a single word about Grey-box testing. Nor the book The art of software testing (3rd edition). What is it? Is it really not worth the mention? Let's find out.
🧩A brief about Black-box and White-box testing techniques
To understand what Grey-box testing is, we first must know what Black-box and White-box testing are.
⬛ Black-box testing (a.k.a. Closed-box testing) is a set of techniques in which the tester test a software's functionality without the need to know how it has been built. In other words, the tester checks whether determined inputs will produce desired outputs. Some examples of Black-box techniques are: Equivalence Partitioning, Boundary Value and Cause-Effect Graph.
⬜ White-box testing (a.k.a. Open-box testing) at the other hand, is a technique in which internal structure of the software is known by the tester. This way he can verify the code flow (conditionals, loops, etc.), security holes and other things. Some examples of White-box techniques are: Statement Coverage and Decision Coverage.
👩🏫 The definition of Grey-box testing can be confuse
Ok, now its easier to define what Grey-box testing is! If you access any page listed at the references section you'll find this definition: Grey-box testing is a technique in which the tester has PARTIAL knowledge of the source code. It's like it fits somewhere in the middle of White-box and Black-box testing, or even a sum of the two previous. Some example of Grey-box testing techniques are: Matrix Testing, Orthonogal Array Testing and Pattern Testing.
Have you seen the problem yet? I'll tell you: How much knowledge is considered partial?
Let's consider some options for answering the question above:
- You have access to just a part of the code;
- You have access to the code, but you can't understand it fully.
How would you define Grey-box testing then?
😯 How much dev knowledge should i have as QA
Let's say you, as a QA engineer, are testing a web application and you have access to the source code. Hence, you're able to apply White-box testing techniques, right? Not exactly.
As a QA, you're not expected to deeply know the programming languages and frameworks used to build the application (or at least you shouldn't). This is a job for your fellow comrades developers. Therefore, White-box testing techniques seems to be a lot more useful for designing unit/component tests.
Of course, that doesn't mean a QA can't have some front-end or back-end development knowledge and apply White-box techniques to help the team to improve testing coverage. But knowing how conditionals and loops work may not be sufficient in some cases. That's why the most common scenario is: Devs design and automate unit/integration tests and QAs design and automate end-to-end/API tests (there are more tests a QA can perform but more of that in later posts).
And Black-box testing techniques consists mostly on detecting the best test data (inputs) for minimizing the amount of tests cases needed. It seems like a perfect fit for QAs, right? And it is! No wonder it's a high demanded skill when applying for a QA role.
💭 What i concluded about Grey-box testing
After doing some research, i've found out that Grey-box testing techniques are much like Black-box testing techniques and are best suited for QAs in general. But the tests are performed by a QA that has some knowledge of how applications are made.
Consider the following example from Thomas Hamilton at Guru99's Grey-Box testing page (You can find the whole article at the references section):
While testing websites feature like links or orphan links, if tester encounters any problem with these links, then he can make the changes straightaway in HTML code and can check in real time.
In another words. If a tester is accustumed to perform Black-box testing, he would just open a bug for developers to fix saying that the link is broken. In this case, a QA applying a Grey-box technique could open the browser devtools and check the HTML structure to see if the href attribute is set correctly on the anchor tag, providing a more detailed bug report.
The same can happen for example if some requisiton fails with a 4xx or 5xx status. Opening devtools network tab and observing things like the requisiton header or response can lead to a detail-rich bug report, helping developers to debug the problem easily.
There's even a Grey-box technique in which the variables of the software are examined and assessed according to the risks it presents (Matrix Testing).
And just for the mention, it's possible to implement Grey-box testing as a form of penetration testing (Pentest) too.
My conclusion is that combining Black-box and Grey-box testing techniques is the way to go for modern software testers/QA engineers. It has some cool benefits like making your teammates appreciate working with you 😉.
How about you? Do you have a different point of view? Share with me in the comments.
If you've read this far, i hope the content has added something for you. If it didn't, remember: This is just another ordinary QA content 😬.
🍀 See ya!
🔍 References
CTFL Syllabus 2018
Thomas Hamilton at Guru99
Imperva
Software Testing Help
Top comments (0)