In every business there is a contention between those perceived as “Producers” (who make things), “Facilitators” (who help make things happen), and “Constrainers” (who help prevent things from happening). Problems occur when these perceptions are misapplied or mischaracterized to people or groups. More significant problems arise when worse perceptions are applied to people and groups we work with.
The results – in particular, between development and software testing – are destructive to our projects, careers and businesses. This article will help you understand and re-align the perceptions that get in the way of a truly productive relationship between software testers and developers.
Let’s first look at a few typical functional perceptions examples:
Producers:
- Software Development (produce software)
- Manufacturing (produce things)
- Sales (produce revenue)
Facilitators:
- Software Testing (facilitate development)
- Supply Chain/Purchasing (facilitate manufacturing)
- Marketing (facilitate sales)
Constrainers:
- Legal/Regulatory/Compliance (prevent harmful actions)
- IT Security (prevent harmful hacking)
- Finance/Accounting (prevent harmful spending)
In virtually all organizations the Producers receive the majority of attention because their work most visibly affects revenue and growth; without Producers a company cannot exist. Frequently people argue that Producers receive a disproportionate amount of attention and budget. As someone who is at various times a Producer, Facilitator and Constrainer, I would have to agree with that argument.
But the reality is clear, even for the perceptions listed above:
- Buggy software will destroy the reputation of the company and revenue will disappear.
- If supply chain/purchasing doesn’t provide the materials, manufacturing cannot take
place. - If marketing materials and advertising are not deployed, sales will fail and no revenue
will be generated. - If legal/regulatory/compliance requirements are not adhered to, the company will be
sued or fined out of business. - If IT security doesn’t protect systems, then attacks can cause both the problems of
sales loss and legal issues to occur. - If Finance/Accounting doesn’t manage cash flow and investment, there will be no money
to operate and there will be more legal and compliance issues.
We can see that all three categories are requisite for the survival and success of any company. The complications are when they are misapplied.
The gap between developers and software testing is a perfect illustration of perceptions that affect at the personal, departmental and company levels. Fortunately, if we address the perceptions we can reduce the gap between the groups that challenges our success.
Perceptions: Software Testers View of Developers
Developers are, like carpenters or manufacturing workers, Producers of product. Requirements are ordered, code is built. But as in any profession, the Producers can acquire a reputation as a Master Craftsperson — or more colloquially, a “rock star.” That title is a double-edged sword, as while it implies great capability of performance it also implies a high-maintenance, prima donna persona.
Certainly not every developer acts or is perceived as a rock star, and that is part of our problem. In some cases the greater organization essentially bestows that title on the developer because of their position, performance, persona or all three. In other instances the developer essentially assumes the rock star title and acts the part. In any case the developer may or may not appreciate the title for its back-handed nature. In response they may create or reinforce those rock star behaviors whether or not the label originated with the developer or from others.
As testers, our tendency is to perceive every developer, from a personality standpoint, as a rock star or worse, a rock star wanna-be. While certainly at times this perception may be accurate, but in every case it is destructive. Whether the developer in fact behaves like one or has simply been labeled as such without justifying it, that label will create animosity from everyone who has to work with that developer. It negatively impacts our interactions with them, it predisposes software testing to frustrations and expectations of conflict, and in general reduces the developer to someone we have to simply “deal with.” It’s damaging to our process and mutual success.
In studying the software testing literature we often find software test professionals observing that organizations put far more interest, budget and emphasis on developers; it’s institutionalized. Unfortunately this is unavoidable as the developers create the product that is sold. At the end of the day, that leads to revenue and drives the company. That overt emphasis on Producers inevitably furthers resentment by others.
Lastly, the job of software test professionals is to find developers’ mistakes, document them, and report them.
Given all the perceptions we’ve discussed here, how could there not be inevitable schisms formed?
Perceptions: Developers’ View of Software Testing
But what of the view in the other direction? Software testers often find a lot of bugs, which is the job’s responsibility. And even if finding those bugs helps improve the quality of the product, software testers are rarely labeled rock stars by developers.
Instead, one of the many labels ascribed to software testers is “Teacher.” Not from the educational standpoint which would be complementary. Rather it refers to the “red pencil,” that is finding fault with the developer and ascribing a grade.
Being labeled a Teacher in this context is a double-edged sword, as was being a rock star. Here the value of bug identification is often lost and is instead seen wholly as criticism. The real value of software testing as assurance that the product is the best it can be is easy to miss. It’s no different than how a teacher identifies errors for students not to criticize, but so they may be the very best they can be.
When the critique- and critical-only characteristics of a Teacher are the narrow perception of the software test professional by the developer, the schism between us grows wider.
How to Succeed: Shifting Perceptions
The key to closing the gap between developers and testers is perception shift. The Developers view of software testing as Teachers labels them as Constrainers — preventing them from accomplishing their goals of production. Likewise software test’s views of developers as rock stars labels them as constrainers as well; their error-prone coding preventing products from moving to sales which is ultimately the point of all our work.
Clearly we must actively shift our perception of developers to Producers — which is their reason for being. And we must shift developers’ perception of software testing to Facilitators, which is our reason.
There will always be personality issues in both directions, but we must all be aspirational towards our real purpose rather than our occasional behaviors or labeling by others. Essentially we must focus on the concept that high product quality leads to high sales. And that is a top-line focus no one can argue with. If your communications stay focused on quality for sales sake rather than just for bug hunting and criticism, you will be in unassailable position.
Along with that product quality=high sales focus, software testing must actively cultivate the perception of helping the developer build products that are most saleable. Communicating to developers that your goal is to help them achieve that ultimate product goal – rather than slowing them down or beating them up – will quickly help you shift their perception of you from Constrainer to Facilitator.
You can’t force yourself (or anyone else) to change their perceptions overnight. First it takes understanding of each other’s perspectives, not just perceptions. Then it takes real effort to convey the right perspectives through action, word and behavior. If you consider the material here and actively work to implement a program of perception shift in yourself, you’ll find the gap between software testing and development shrinks faster than you’d imagine. And the results will visibly benefit everyone.
Questions? Please email me at bcollin@collingroup.com. Comment on this article too!
About the Author
Barry Collin Having coined the term “CyberTerrorism” and developing the studies behind terrorists exploitation of computer systems, few people are as concerned with software testing as Barry C. Collin. Today he is the CEO of Collin Group, Inc. and President of its flagship consulting unit Moddition (www.moddition.com). His work has created billions of dollars in new opportunities for small businesses through Fortune 500 enterprises. He’s also Director of Markets and Buyers Analysis at the Group’s research unit, The Markets Institute (www.marketsinstitute.org). There he has developed new market growth and innovation techniques implemented at myriad companies, analyzed complex markets, and invented the Business-With-Business approach used by major B2B firms globally. Barry recently discovered the Microbubble Phenomenon of Social Media Buying Behavior. His work is chronicled or cited in more than 65 current books and myriad papers in multiple languages. Barry also trains organizations like NASA and IBM to better connect their scientific, technical and less-technical people in new ways to reach maximum levels of efficiency, execution and success. As a professional speaker (National Speakers Association/Global Speakers Federation), industrial designer (IDSA), and business thought leader and author with over 25 years of experience across multiple industries. Barry has trained tens of thousands of professionals globally and presented at Harvard, UNC Chapel Hill, University of California at Los Angeles, Penn State University and others.