I've been to quite a few conferences this summer, and at each I've had at least one conversation similar to the following:
I am continually amazed by responses like this, but I guess I shouldn't be. Most testers I meet simply have not been exposed to the virtually impossible business challenges regularly facing development projects that often lead to decisions that appear completely counter to a commitment to quality when taken out of context. The fact is that there are a huge number of factors influencing a software development project that, at any particular point in the project, may rightly take precedence over an individual tester's assessment of quality. Given their lack of exposure, it's no wonder testers seem to habitually take a "my team doesn't listen to me" point of view.
I blame managers for this situation more than I blame testers, but I hold testers at least partly responsible for not making more of an effort to understand the logic behind these seemingly bizarre decisions. That line of thinking drives how I address questions such as, "What valid reason could someone have for accepting bad quality?" For example:
This is about the point in the conversation when the tester either decides that I don't know what I'm talking about and walks away or decides that he should probably ask some different questions when he gets back from the conference.
I recognize that it is completely reasonable for people to draw conclusions based on the information they have. I further recognize that when those people are testers who are good at what they do because they don't blindly trust things that don't make sense, it's easy to draw the "my team doesn't care about quality" conclusion.
I even recognize that the last thing a business executive wants in the board room while trying to decide whether to lose money as a result of buggy software or to lose money as a result of the software not being ready on time is a tester saying, "It's
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
not about the money; it's about making quality software!" But most important, I recognize that testers need to stop ignoring the fact that there are valid perspectives other than their own from which sound software development decisions can be made.
There was a time when it was commonly believed that the earth was the center of the universe. It was a reasonable belief that made perfect sense from our perspective. It's not like at the time we could look through a giant telescope, or launch a deep space probe to get a different point of view. I actually think that this "Center of the Universe Syndrome" is natural. Given no reason to do otherwise, why wouldn't a person look at something from his own perspective?
Unfortunately, this Syndrome is not particularly helpful to a tester who is genuinely concerned with software quality. To really have a positive impact on quality, I think testers would do well to consider the following before deciding that the team or company doesn't care about quality, or doesn't take testing seriously:
When all is said and done, in many organizations the test team is no more at the center of the universe than the Earth's moon. Think about it. In your team, does the test team (the moon) orbit the development team (the Earth), which is guided by the gravity of the business (the sun), which in turn is weaving a path through the universe of business, finance, and competitive pressures? If so, maybe it makes sense to think about the things you can influence -- such as testing methods, improved communication and test prioritization -- as opposed to things you probably can't -- like budget, business priorities, and contractual obligations.
That is similar to how the Earth's moon influences tides, causes solar eclipses, and inspires awe and a spirit of exploration in the inhabitants of Earth, but it doesn't seem to feel as though it isn't taken seriously because it can't change the direction that the Earth orbits the sun.
----------------------------------------
About the author: Scott Barber is the chief technologist of PerfTestPlus, vice president of operations and executive director of the Association for Software Testing and co-founder of the Workshop on Performance and Reliability.
