Creating a masterpiece; a second set of eyes in the testing and developing arena

Do you want to know where software-development teams—especially testing groups—should focus next year? I have written two articles over the last couple weeks (“What is Grey Box Testing? How can it help you?” and “What types of software testing matter to you?”) that express my thoughts on the topic.

  

In both articles, I repeat the phrases “Grey box testing” and “root cause analysis” to the point of making myself nauseous. I hope to in this blog to start peeling back the layers like an onion (or parfait depending on your favorite character in “Shrek”). Today I will explain why I believe that developers and testing should complement each other--exploiting each other’s strengths while cancelling out their weaknesses. 

In practically every workplace I walk into, there is a palpable friction between the Quality Assure Group and Development with the business analyst playing both sides. Imagine the potential for your organization if these two groups worked in harmony.

 

A relationship built to allow for critism and critique

 

failing_grade_300x377.pngRemember when you would spend hours and even days writing term papers. At that time, you had worked so hard and long it felt like if you had the energy to keep writing a couple of more pages you would have a bestselling novel . Then you watch helplessly as the teacher or your “so-called professor” took a red pen and slaughtered your work of art. This is the moment where you define your relationship with your peer and professors.

 

Hopefully this analogy provoked a memory or a reaction, because the stress between quality assures and development is similar to this example. Modify the story slightly and put it the proper light. Instead of having an esteemed instructor critique you, now it is another student with a completely different degree path grading your masterpiece.

 

What if every page you wrote for the professor, instead was examined by your peer at the next desk who would review that page for syntax and grammatical errors right then. At the same time, would explain their interpretation of the assignment. After this review, you WOULD have to share some the credit with your peer. They haven’t reviewed the finished paper, but because of their work, final writing takes less time and at the end you would learn a lot about how other people interpret art.

 

What Grey box Testing can do for you

 

Grey Box Testing and having a testing team that is properly trained in root cause analysis is a powerful combination. The testing team can now assist in the development process by interpreting the business requirements and directly apply them to the code. In the past, they would have to apply business requirements to the application—which is often much too late to be cost effective.  It is like having a peer assist you before the professor sees your paper.  

 

thCAQ83YJ0.jpgGrey Box provides the ability to test an application from either the presentation layer (which is comparable to Black-Box Testing) or behind the presentation layer (which is similar to white-box testing) with the capability and the training to view the data and functionality of an application. This option does require some insight to the application’s internal structure, even to the code level at times. Today’s automated testing tools can help interpret application behavior and aids in the process of root cause analysis—an additional benefit.

 

Your testing then helps identify high risk areas of code and documents them with issues management. This removes the threat of unrealized defects. These defects may be hidden for several iterations or initiatives until a catalyst is introduced or business rule has been nullified or forgotten. This is a very dangerous situation.

 

I would love to hear if you have experienced a cohesive cooperation with your test and development teams. Were they frienemys at the beginning, but eventually learned the advantages of working together? In my next blog I will look at how to actually establish a healthy environment for these two teams.  They both know and understand the benefits of working together, but historical biases get in the way.

 

HPblogfooter2.jpg

 

Thanks

Doc

Labels: ALM| development| testing
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
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...


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