5 Grey Box Testing Tools Every Tester Should Use

You might be wondering why to use grey box testing tools? Tooling is an important part of a tester’s arsenal to deliver quality Testing. Just like a plumber needs his wrench, a Tester needs their tools to get the most out of their workday.

There are tools designed for various Testing activities and tasks. From a solid Test Case Repository to reduce redundancy and increase reuse, to a Bug Tracking tool to better manage defects and Requirements Traceability, and onwards to Automation tools to reduce the manual labour in your Testing life – there exist a variety of options for Testers to make their work lives more productive and comfortable.

Continuing in that vein, in this blog we’ll discuss what is Grey Box testing, and why and how it benefits your Testing efforts. We’ll also review the 5 tools everyone doing Grey Box Testing should be using, and how these can help you get more out of your Testing efforts.

What is Grey Box Testing?

For the uninitiated, Grey Box testing refers to the (apparent) amalgamation of White Box and Black Box testing.

White Box testing gives the tester a clear view of how the system ‘hangs together’ – that is, how the various components and subsystems integrate and share information. The tester is therefore able to look for and test specific functionality and scenarios to give the system a good shake.

“Grey Box Testing brings the principles of both White Box and Black Box testing together.”

Black Box testing is necessarily a situation where the tester understands the needs the system is required to meet, and the Input and Output requirements. And goes about testing these, while being oblivious to the internal workings of the system.

Black Box testing can be seen as a means to test the basic functionality that a system or software product is expected to fulfil, and should be good enough to move a product to the next phase of development if you are in iterative development mode.

White Box testing will help you test for the exceptional scenarios, catch those difficult to catch bugs and help get the product ready for release.

Grey Box Testing brings the principles of both White Box and Black Box testing together. It refers to situations where the tester is only exposed to intricate details about specific system components and functionality that they are required to test and validate, while the rest of the system can remain a Black box. It can at times refer to situations where your primary focus is in catching bugs with one or a few system components, and not necessarily the rest.

In simple terms,

Grey Box Testing = White Box Testing + Black Box Testing

Grey Box Testers generally have access to design documents, architecture diagrams and other supporting information to give them an idea of the internal workings of a system or system component.

Difference from White Box and Black Box Testing

Grey Box Testing is:

different from White Box testing in that it doesn’t provide a tester access to the source code.
different from Black Box testing in that it doesn’t deprive a tester access to information about the system architecture and design.

Grey Box Testing is quite common when testing web based applications, for the reason that the potential impact of a bug is considerably higher if undetected.

When does Grey Box testing become necessary?

Usually, when you have identified that a specific part of the system needs attention to fix critical issues.

For instance, many years ago, one of my clients encountered a bug with their internet banking platform when making a routine upgrade. It turned out that only payments of a certain type were failing after upgrading one of the data centres. Testers were able to complete all other payments except this one, and we couldn’t find the root cause – and hence couldn’t fix the issue.

As it turned out, we decided to investigate the issue by halting the upgrade (customer traffic was routed to the backup data centre by the way, which wasn’t upgraded yet and therefore unaffected by the bug). Over the next two days, we spent hundreds of hours of testers’ and engineers’ time to investigate and still couldn’t find the issue.

Grey Box testing came in handy here, as we split responsibility for the various system components amongst the team and performed targeted testing to bring out any anomalies within each.

By focusing on the permutations and combinations of just one system component, each tester was able to quickly identify and run through all scenarios for that component.

Why is Grey Box Testing important?

Testing happens from the point of view of the user – i.e., the consumer of your product. This is one of the benefits of Black box testing and carries over to Grey box testing.
Testing also happens from the point of view of the developer – with some characteristics of White Box testing still intact, the Tester is able to see the system from the vantage point used by the one that designed it, and uncover more – sometimes uncommon but potentially very embarrassing – bugs.
Combined with other Testing efforts in a project, Grey Box testing comes in quite handy when you’re trying to clean up code. Like my example demonstrated above, you don’t know when an unseemly bug could rear up its head.
Two brains are better than one. Especially when those of a developer and a tester come together to catch bugs. That is the benefit Grey Box testing provides – by allowing the tester use the system design documents to design Test cases.
Fundamental benefit – this is Black box and White box testing combined into one. Need I say more?

Tool #1: Selenium

Selenium is an open source tool, and helps with browser automation. This tool is primarily used for cross-browser black box testing, i.e., to check if your web based application works fine across browsers and versions. By using the IDE capture interface, you can help the system learn common user actions on a web based application and test it repeatedly across browsers.

Selenium provides probably the widest support for browsers, so is a first choice for most testers. Primarily a Black Box testing must have, this tool is important in your repertoire for Grey Box testing as well – given you deliver a degree of Black Box testing in the process.

Tool #2: Appium

Now, you’ve got a potent tool for cross browser testing in Selenium. How about mobile browsers and apps? Mobile is a specialisation in itself, and requires a dedicated tool given Selenium doesn’t necessarily provide adequate support for mobile. Having said that, Appium is essentially a companion to Selenium. If you use the latter for your web based applications, the former should be viewed as an add-on to test the application on mobile browsers.

Appium also supports mobile apps and is cross platform – both iOS and Android (what else is there?). The tool leverages Selenium API, and therefore should provide a degree of familiarity as well as a shorter learning curve if you already use Selenium.

Tool #3: Rational Functional Tester

Yes – it’s from IBM. Yes – it is NOT open source. But RFT provides a catch all, one-stop solution for your White and Black Box (therefore Grey Box) testing needs. It supports a range of technologies, from web based to iSeries and zSeries, so may be all you need – at a basic level.

Tool #4: Chrome DevTools

Picture this: Almost 50% (or more) of all web browser traffic is through Google Chrome. So of course you need to use the simple tools Google provides to optimise your product for Chrome!

Chrome DevTools provide web authoring and debugging tools that help you resolve layout issues and better optimise your code to work with Chrome.

This is one tool that should be on your list if you’re working on browser based applications. No excuses.

Tool #5: Bug Tracking, Requirements Traceability and Test Case repository

Yup – you read that right.

There are many more optimisation and automation tools to support Grey Box testing out there that help you get the most out of your Grey Box testing efforts. Have your pick.

You can arm yourself with the best Grey Box testing tools, but that wouldn’t give you the best results if your fundamentals are not strong, right?

We’ve covered the importance of tooling, automation, Requirements Traceability and Test Case management extensively on various blogs in the past. And I would like to reiterate that here.

Work hard on your Test tooling strategy, and have an ecosystem of intelligent, interconnected tools. There are a host of options out there (we’ve even got one in-house – ReQtest), and they all offer a wide variety of capabilities. Pick the one (or few) that most suits your Testing needs, and you’re all set. Look for tools that integrate well with other tools. You don’t want your test cases to live in a walled garden.

Now It’s Your Turn

I’ve said this many times before – Tooling alone won’t make for better Testing. But when combined with world class Testing skills and knowledge gained over many years in the industry, and industry accredited processes and practices to deliver Testing, Tooling can be a potent weapon for the experienced tester.

All said and done, tools only provide you the wherewithal to execute a sound test strategy. Tooling contributes significantly to success of your Testing efforts, yes, but only a minor share compared to high maturity in Testing processes and practices.

Choose your tools wisely, and they could make all the difference for your team’s productivity. Get your Testing fundamentals right, and the right tools will add to your success.

If you found this blog helpful, spread the word and help others as well.