All About the Apps
Showing results for 
Search instead for 
Do you mean 

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

Michael-Deady ‎10-30-2012 03:00 PM - edited ‎09-18-2015 03:54 PM

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


Remember 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.  


Grey 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.





0 Kudos
About the Author


Michael Deady is a Pr. Consultant & Solution Architect for Teksystems, center on quality, aimed at client's satisfaction, and long-term success. Perceived by clients, peers, and supervisors as a leader with the proven ability to lead development and quality assurance teams through software-development life cycle phases, to ensure quality of new products. He specializes in software development, testing, and security. He also loves science fiction movies and anything to do with Texas.

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all