The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #54: Understand what your customer wants, what he needs, communicate the needs, agree with needs and deliver both of them. -Teemu Vesala
Suggestion #55: But remember that people don't always need what they think they need. Be prepared to think around the problem to deliver a solution to the problem, not just what was explicitly asked for. - Joseph Brannan
These two are direct point/counterpoint, so it makes sense to look at them as part of the same exercise. If I wanted to be really lazy, I'd just say look at "Get to Know Your Customers" and "Trust No One", but what fun would that be :)?
In truth, the customer is not just a single entity. Organizations need to cater to many customers. The fact is, software testers are not just testing software for the end user. They are also part of an engineering team, a company division, internal organizations, and corporations that have senior management, executives, boards of directors, shareholders, etc. Each entity in that list is a customer, and each entity has mutual, but not necessarily compatible goals.
Workshop #54 and #55: Read between the lines and see if you can determine "the rest of the story". Focus less on the "what" and more on the "why". Consider who the "customers" or "stakeholders" are in each area, and what their actual goals are.
We'd like to believe that our primary focus is to release software that is high quality, ideally low in bugs, and with features that will make our customers happy. Were we to just focus on that aim, decisions around testing resources, methods, and testing commitment would be easy, and obvious. Everyone would invest in making the decisions that would emphasize that. However, it's rarely that simple. Businesses exist for one reason, ultimately, and that's to turn a profit. Without profit, continued development would not be possible. People could not be paid, and companies would ultimately go out of business.
The simple, unavoidable, and often painful truth is that software testing is a cost center in an organization. Unless you run a for-profit testing organization that sells actual testing services, or you sell software applications that actually aid in software testing (which, frankly, means you work for a company that sells a software product to a customer in the classic sense of the word), most software testing costs an organization money to perform. We don't book revenue by doing great testing. We can safeguard revenues, we can act as a hedge, but we do not actually earn revenue for an organization with our testing. This is why it's vital to recognize the "customers" in every aspect of the organization, what value they place on testing, and why they might consider it important (or not):
To the end user: the feature you are testing will help them do their work better. If they can do their work better/easier/faster, it's possible they can spend time focusing on other things that matter to them, be more efficient and effective in what they do, or potentially have fun because of what has been created.
To the developer: we help them realize their goals of releasing a feature that will differentiate, and hopefully, encourage people to buy the product.
To the customer support representative: every issue we find before it gets out the door is fewer phone calls and workarounds they have to deal with (and ring up another cost center for the organization).
To the marketing team: high quality code represents a feature and a story they they can trumpet. Buggy code makes for areas they need to downplay or side-step altogether. Defensive ad campaigns are rarely long term winners.
To the accountants: testing adds business value by helping ensure that public "black eyes" don't occur, resulting in an exodus of customers and revenues. Don't be surprised if you have to genuinely make this case to them.
To the executives: a culmination of all of the above.
Each of these are customers. Each of them has different goals with features and releases. Each of them values something in the testing that's performed, but don't think that they share the same vision or have the same goals. This makes for a variety of challenges for software testers looking to do good work, under a variety of both rational and irrational pressures.
Great testing is, at its heart, the ability to create a coherent narrative, a compelling story, and tell it in such a way that decisions (often critical) can be made. We provide information to show acceptable behavior. We provide information to demonstrate conformance, where and when that matters. We provide information that allows organizations to mitigate risk. We provide information to help decide if what we have is the next "killer app", or a "white elephant". Understanding the whole narrative, and how that narrative matters to different stakeholders, will allow us to focus on the "why" first and foremost. If we do that, we have a far better shot at demonstrating the real value we can provide. From there, much of the who, what, where, when and how will take care of itself.