Is there a more classic love/hate relationship than the one between developers and testers? (Okay, maybe between developers and program managers, but I digress.) As a developer, you either see testers as nagging or persistent, nitpicky or thorough, obnoxious or passionate, unsophisticated or customer-focused, doomsayers or cautious.
The same could be said for how testers view developers: brilliant or geniuses, dedicated or hard-working, creative or inventive—uh yeah, right. If the truth be told, testers often think as poorly of developers as we do of them.
Many teams are far from reaching parity and mutual respect between these disciplines. Some steroid-sucking developers out there might respond, “That’s fine—lead, follow, or get out of the way. If the test team can’t keep pace, can’t stand toe to toe, can’t flex their own muscle, then they should step aside and avoid the oncoming dev machine.”
Big words from small minds. It’s time to tear this twisted testosterone tale apart, piece by piece, and reveal how real developers should be working with the greatest allies they have: testers.
How do I love thee? Let me count the ways
So why do development teams often treat their test teams as second-rate and unworthy of respect and cooperation? I’ll break down the reasons, one at a time:
- All testers really wish they were developers; therefore, developers must be better. Any ridiculous generalization like this can’t be true. Not all testers wish they were developers. Some do, certainly, but others want to be golf pros, racecar drivers, product unit managers, program managers, parents, priests—you name it. Some even want to be great testers.
The real disgrace about this myth is that it shows how insecure some developers really are. A developer who is truly proud of his work and accomplishments wouldn’t need to feel that development is a superior discipline.
- Testers are not as smart as developers. Taken as a corollary to the previous fallacy, this is often voiced as, “If testers were as smart as developers, they’d be developers.” Again, bull excrement at the most basic level.
However, even fair-minded people will point out that testers often aren’t required to have the same level of education as developers. Black-box testers, in particular, are frequently hired with little or no technical experience. To me, this is purely a case of the chicken versus the egg—there simply isn’t enough external training for testers.
Eric Aside Black-box testing treats the product as a black box. You don’t have any access or knowledge of the internal workings, so you probe it like a customer would—you use it and abuse it till it breaks. Microsoft has been steadily moving toward white-box testing, in which you use exposed instrumentation to automatically and systematically test every aspect of the product.
Many people inside the company are working hard to correct this inequity through initiatives like the Readiness at Microsoft Program (RAMP) and the Test Lead program. Even a few universities and local community colleges have begun offering courses in testing. But until colleges and universities create standardized bachelor’s and master’s degree programs in this important discipline, testers won’t find quality opportunities to learn more about their field through higher education.
Does this lack of educational opportunity mean that most testers are not smart? Of course not. There are strong and weak testers just as there are strong and weak developers. That’s all.
- Testers wouldn’t have much to do without developers. The idea that without developers, testers would have nothing to test leads some people to think that developers are better. (Of course, the fact that developers often generate plenty of work in the form of bugs leads many people to think that developers are worse.) Nonetheless, is every upstream discipline considered inherently stronger than the downstream counterparts who depend on them? It is harder to direct a movie than to run the projector, but then again, it’s easier to dig up a diamond than to cut and polish it.
It really comes down to the complexity of the work, and testing products and functionality well is easily as difficult as writing the stuff in the first place. Many of the hard theoretical coding problems have been solved, but many of the hard theoretical testing problems are still waiting for answers.
- There aren’t as many strong test teams as there are strong development teams at Microsoft. Based on this presumption, developers might extrapolate that their discipline must be better than testers in general. This is a bad assumption and poor pretext for not doing all that you can do to grow your test team and strengthen your whole group in the process. Testing is not as mature a discipline as development. Using this as an excuse to act condescendingly toward testers only serves to lower a developer’s maturity level rather than raise a tester’s.
Necessary evil or priceless partner?
We can’t ship a product without testing it. Think of the three worst bugs that testers found in your code last cycle and you’ll know what I’m saying. What many developers haven’t realized yet is how well you can ship a product with the test team’s support.
Unfortunately, for many groups, testing remains a necessary evil rather than an integral priceless partner. I know that there are developers out there chiding me saying, “Integral priceless partner, as if! Test is what they’ve always been: monkeys that bang on the code till it breaks and then whine about it till we fix it.”
If that’s the way you treat them, then that’s what your testers will be. However, there’s an alternative approach.
A man’s got to know his limitations
It starts with understanding three principal areas where development falls short: writing perfect code, understanding Raid holistically, and working within the customer’s environment.
No developer writes bug-free code; even if there are no logic bugs, there may be behavior bugs. No developer lives and breathes Raid; he just uses it as a tool. No developer commonly works in the customer’s environment; he works on big machines with tons of memory, processing power, and disk space. Developers also have high privileges, fast networks, the latest operating system and patches, and no legacy code—and they work in their native language. Basically, developers are hopelessly out of touch with what is necessary to move the product from their desk to the customer’s.
So guess who’s holding the safety net and providing the balancing pole for developers as they cross the tightrope between code complete and release? That’s right, it’s your testers.
Testers find both the logic and behavior bugs; they live and breathe Raid; they know where you stand and how much work needs to be done; their computers run all the time in the customer’s environment and in all the different languages, platforms, and configurations. Testers can tell you how many bugs you need to fix each week without guessing. They know where the problem areas are and can give you gut and metric readings of how far you need to go.
You complete me
Developers can make you say, “Wow!” But testers will save your behind and make you proud of your development efforts.
If you treat your test team like trash, trash is likely what you’ll ship and trashy is likely how you’ll feel. If you prefer a smooth release and want to ship a great product, make your test team your ally.
The key is for you and your development team to understand and appreciate all that the test team offers you. They cover the areas that you can’t or don’t want to do. They keep you on schedule and on track. They keep you honest and represent the customer’s perspective.
Tell testers how valuable they are to you. Tell them how they can help both your teams ship a great product. Do everything that you can to support them, and they will come through for you.
Eric Aside I really can’t say enough about my respect and appreciation for the test discipline. In the nine years since I wrote this column, some nice strides have been taken at creating parity between dev and test in all areas, but there’s still far more we can do, as I discuss in Test don’t get no respect. As for managers and PMs, I admire and respect them too, but since I live under the darkening shadow of their every whim, forgive me for not stroking their egos.
By the way, if you’re already making the test team a valued partner, it’s time to do the same with service operations. The same arguments apply, so why not trade in your pain and frustration for synergy and success?
Be First to Comment