I Represent the User! And We All Do

As a tester, I try to represent the interests of users. Saying the user, in the singular, feels like a trap to me. There are usually lots of users, and they tend to have diverse and sometimes competing interests. I’d like to represent and highlight the interests of users that might have been forgotten or overlooked.

There’s another trap, though. As Cem Kaner has pointed out, it’s worth remembering that practically everyone else on the team represents the interests of end users in some sense. “End users want this product in a timely way at a reasonable price, so let’s get things happening on schedule and on budget,” say the project managers. “End users like lots of features,” say the marketers. “End users want this specific feature right away,” say the sales people. “End users want this feature optimized like I’m making it now,” say the programmers. I’d be careful about claiming that I represent the end user—and especially insinuating that I’m the only one who does—when lots of other people can credibly make that claim.

Meanwhile, I aspire to test and find problems that threaten the value of the product for anyone who matters. That includes anyone who might have an interest in the success of the product, like managers and developers, of course. It also includes anyone whose interests might have been forgotten or neglected. Technical support people, customer service representatives, and documentors spring to mind as examples. There are others. Can you think of them? People who live in other countries or speak other languages, whether they’re end users or business partners or colleagues in remote offices, are often overlooked or ignored.

All of the people in our organization play a role in assuring quality. I can assure the quality of my own work, but not of the product overall. For that reason, it seems inappropriate to dub myself and my testing colleagues as “quality assurance”. The “quality assurance” moniker causes no end of confusion and angst. Alas, not much has changed over the last 35 years or so: no one, including the most of the testing community, seems willing to call testers what they are: testers.

That’s a title I believe we should wear proudly and humbly. Proudly, because we cheerfully and diligently investigate the product, learning deeply about it where most others merely prod it a little. Humbly, because we don’t create the product, design it, code it, or fix it if it has problems. Let’s honour those who do that, and not make the over-reaching claim that we assure the quality of their work.

3 replies to “I Represent the User! And We All Do”

  1. I fully agree that it is not enough to represent the users (however, it is always good to keep them in mind). Sometimes the topic boils down to ethics.
    For instance, company A may be building a product for company B, and end users (people who actually interact with the software) are customers of company B. They don’t even know that company A exists.

    So, should testers in company A represent the end users? Or maybe they should represent company B (the actual customer)? If they need to choose between these options, where do they look for the answer? What if a particular choice in the software is according to customer’s requirements, but it’s absolutely against the end users (an example would be hiding “report a problem” option very deep in menu system)?

    Michael replies: Let’s consider the tester’s scope of responsibility. The tester doesn’t decide what the product should do or not do; the tester doesn’t decide whether something is a problem, or whether a problem is serious enough to fix. The tester doesn’t decide whose values matter over others. The tester shines light on the product and on the problems people might have with it. So when I’m representing some party or another, I’m testing for problems that would matter to that party.

    There are two fundamental questions in testing. Looking down at the product, I’m asking “Is there a problem here that would threaten value for some person?” That’s the first question. Upon finding a problem, I report it to the client of my testing, and ask the second question: “Are you okay with this?”.


Leave a Comment