What is Grey Box Testing? How can it help you?

thCA6MO5GZ.jpgI have always dreamed of being a contestant on “Jeopardy”. I can imagine myself being $10,000 ahead of the next competitor and having Alex Trebek ask, “For $1000, can Software Testing group survive and improve on the SDLC process in 2013?” My answer? Alex, “What is grey box testing” 

 

 Everyone in the Software testing industry has learned, heard, or used white box or black box methods of testing. But how many been trained, heard or used the step-brother method of testing—grey box testing or what is sometime called translucent testing?

 

Who is this “Step brother”?

 

In short Grey box testing is the ability or the training to test both sides of an application presentation layer and look directly at the code, data, and problems within an application. This allows the tester to play a big part in trouble shooting the errors—using root cause analysis if trained correctly in process?  Most testers can properly evaluate the problem and then document the finding in a single point of reference. This gives the developer time to fix the errors—what they do best.  

 

In several of my blogs I’ve mentioned Grey Box testing as a possible solution to address a lot of the struggles we currently face. It applies   not only to struggles in testing, but to IT as a whole. By the end of this series, I hope to convince you of new or different ways to make testing an integral part of your company’s future IT departments.  But before spelling out the solution everyone needs a really good horror story to get you in the mood for change. Because it is almost Halloween, and who doesn’t love a good scare this time of year!

 

When cuts need to be made, where do the scissors cut first?

 

The truth is when a company needs to cut back; they generally look first at the money trail. This search often leads them to IT—why is that? Is very simply the numbers, IT has become the biggest liability and the largest cash consumer in most companies. And these are mainly companies where the primary business is not information technology. 

 

garage1.jpgWhen you add-in the cost of the liability of IT from the stand point of security, risk, and exposure; companies cannot afford the cost of doing business. If you can’t afford change, then why invest in groups that are sluggish to change. Information technology is infamous for being resistant to adapting and embracing new Ideas and processes.  These companies hurriedly take red ink to IT groups. The remaining IT departments then decide to go into a support mode.

 

If the IT groups are going into a break/fix mode then companies don’t need a large of group testers.  And like that, testing is gone. 

 

The cost of doing business is shifting the way business is done

 

I didn’t say the above statement was logical. The cost of keeping developers (which can test and develop) and analysts (which can do some of the testing (poorly) and fix the application) is less than keeping testers. Testers usually cost less than a developer and sometimes more than an analyst on your staff.   But those other roles can pitch in and do the testing work—kind of.

 

money.jpgAlong with the ever smaller money trough; methodology and process shifts like Agile have made verbal communication an essential part of the development process. Without documenting the decision making process in the Software Development Lifecycle (SDLC), overall memory retention of application knowledge has been reduced. In other words, you can no longer remember why a change was made to an application after two years. This time frame can be greatly reduced, depending on the amount of turnover in your Agile teams. In addition, at the core of the Agile manifesto is that the work is shared equally across the team; however more agile teams are discovering that some people are more equal  than others creating  choke points within the  agile projects:

  • Not enough developers on a team
  • One to many business owners
  • And no words could quantify the number of Scum Masters needed in an IT agile environment    

These choking points are why testing groups need to take on greater responsibility within the software-development lifecycle. Testing groups should act as the application historian, and be responsible for all phases of testing, including all but rudimentary unit testing.

 

Grey Box Testing—what it can do for you?

 

thCAZP5NZB.jpgGrey box testing could combine the creative minds of developers and thoroughness and tenacity of testers into a single minded process of functionality and quality.  No I’m not describing IT’s version of Jason and Freddy having offspring on Halloween. Instead I am describing the beautiful harmony of Halloween candy—Pretzel M&Ms to be precise.

 

The reality is that this process shift takes the pressure off the developer and allows the testing teams to truly validate every aspect of application development. A lot of time testing development becomes adversarial. This happens because the developer believes he or she is done with that project and is ready to move to a new assignment, some tester will send them one or more defect (which to a developer is equivalent to telling Leonardo he can’t paint). If the developer is lucky, the tester will also send a complete list of steps of how to recreate the problem, data, and maybe one or two pictures.

This feels like a slap to a developer ego. He or she is required to root out the problem within the code or requirement, and then resolve it as well. Now is the developer going to be happy about completing a full root cause analysis which he or she has more than likely has little or no training at that type of trouble shooting? What really happens is what a lot of developers call the “patch fix mentality”. I’m telling you right now you don’t want to see how this can and will fester and grow within a development team (it should be called the “Patch fix Cancer”).

 

gray box.jpgThis is where the benefits of Grey Box testing come into play:        

  • This type of intelligent testing, will allow the tester to understand the functionality of the application. As well as, the application architecture, data flow and most of all exception handling— which most testers should understand to be successful at testing.
  • The practicality of using test automation in functionality and integration testing using techniques like API’s testing will become more of reality. This reduces the overhead of long drawn out functional and non-functional types of testing cycles.   
  • The ability to speed up the development cycle by having the developer complete rudimentary unit testing before handing it over to their partner. This frees up the developer to fix defects. 
  • The old expression “two set of eyes are better than one” come to mind every time I preach Grey Box testing.

This just some of the two dozen reasons which I will cover this series, but none of these benefits matter when IT is considered expendable…..

 

What does the future hold?

 

In the next blog we will talk about some the suggestions and possible solutions that could be implemented over the next year. But first what I would like hear from you about some of your predictions, and outlooks for IT, SDLC, and the testing processes. Or do you believe that the Mayan calendar is correct and our time has run out.  In that case there is no reason to call this article a series. Instead it will just be one guy’s ranting.

HPblogfooter2.jpg 

Keep Reading

Doc

 

Other Blogs you may find interesting

Comments
maria1 | ‎10-21-2014 11:10 PM

Thanks for sharing this infomation.

 

Will you please guide me that how can we improve the grey box testing process? 

Michael-Deady | ‎10-22-2014 07:50 AM

maria1,

Thank you for your response, I will be publishing a follow-up in the next couple of months with more detail; the concept of gray box testing has several points of integration with development:

  • Testing team needs to be more integrated into the development team during the design phase to develop detailed scenarios, allow them to automate while the code is still in development.
  • Develop APIs type testing to test all the new functionality this becomes critical when you're talking about mobile testing.
  • Talk to your development teams and see how the testing team can become more involved in the source code management and build tools this gives you the capability to draw from these sources of information to better develop new functional testing.
  • If you're working on existing applications look at exploratory testing in a way to assist the development team in identifying issues even before development is complete on the new functionality.
  • Look at the tools that they're using for unit testing such as Junit or Nunit and see if you can integrate that into your testing strategy.

These and several other steps will give you a high visibility with the development and business owners. In most cases if you create very detailed test cases using tools like HP sprinter you, and your team will become an essential part of the continuous integration strategy which a lot times parallel test driven development.

 

 

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He spec...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.