Free eBook - The Road to QA Excellence - Download now

QA as Customer Representatives within the R&D

By on October 13, 2008 in Best Practices

In many R&D organizations the QA takes the role of the Customer Advocate, testing the system and even arguing in favor of fixing defects based on their internal perception of how customers use the product.
In some companies Test Engineers even take the role of Users during Internal Design Reviews.

Why does this happen?
Your guess is as good as mine but I think this is an issue of perception.

If testers already have an end-to-end perspective of the system, and they take the role of users when testing the product, this makes them good customer advocates, right?
WRONG!
If most testers have never even talked to a user, how can they advocate for them???

I think that QA is a good candidate for internal Customer Advocate, as long as we make sure they have the tools and experience to fulfill this role.
There are at least 3 ways to provide our Engineers with the knowledge and experience required to represent Users.

1. Place them closer to users within the Organization.
Do this by letting them take part of Customer Support activities and by supporting sales teams during pre-sale cycles, it can be as simple as instructing the Engineers to talk and learn from these customer-oriented organizations about the main needs, pains and comments coming from field.

2. Take Engineers out into customer facing activities.
For example, by sending them on-site to work with customers on complex installations or advanced implementations of the system. Another good opportunity is during Beta Programs, Customer Trials, or any other activity where the R&D interacts with users face to face (preferably on-site).

3. User conferences
Not all companies have them, but if you do this is the easiest way to gain access to a big number of users.
During conferences it is important to have an effective way to interact with the users, you can do this by arranging meetings up-front (with the help of the sales or support teams) or even by setting up a Demo Area where the QA can demonstrate the new or up-coming functionality.

At the end of the day the QA needs to take the role of Customer Advocate, there’s no way around it. If so, it is important to let your engineers do this right, by giving them the tools and knowledge required for this task.

About Joel Montvelisky

View all posts by Joel Montvelisky →
  • Ido Schacham

    Generally I agree that these are good suggestions how to get developers closer to their customers.

    However, there is one major problem with what you said. Most developers are very attached to their code and think too much like developers. Few have an all encompassing awareness that can take the customer perspective in mind.

    QA are not attached to the code. They may get attached to how the product currently works and get mind blocked, but that’s a different story. So considering things they have, relatively, an external perspective as opposed to developers. They aren’t aware of technical difficulties, most of them don’t know how to program, even those that do usually aren’t acquainted with the code, and they do possess much better all around knowledge and a bigger picture of the product than most developers who are busy implementing tiny bits of it.

    So yes, QA aren’t the actual users, but they are much closer to the user perspective than the developers. It’s probably best to run usability tests with actual customers to get the real users’ take on things, but sometimes even the users don’t know what they want :) Isn’t that what product managers are for?

  • Joel Montvelisky

    Hi Ido,

    It’s obvious that no approach will fit every Organization, but I seem to disagree with a couple of your points.

    You wrote that QA Engineers don’t have programming skills and may not be aware of the technical difficulties of their apps. I think that was true 5 or 10 years ago; today most QA Engineers are trained in Development, and are able to understand the intricacies of the system under test.
    They are not the developers of their applications, but more and more I am seeing all over the Industry Engineers (manual tester and not only automation) who can enter the code, understand it and use it as part of their white or grey box testing approach.

    Regarding the task of the Product Managers, you are right and they should be the first players in direct contact with users, but not the only ones. The more QA and Developers are in direct contact with users, the better the application will answer their REAL Needs.

    Having a QA department that does not understand its end-users is like having a color-blind painter. He will get it right part of the time and with a limited spectrum of color but it will never be the same thing.

    Again, there is no approach that fits all Organizations, but I believe (and my experience tells me) that all organizations should strive to have their QA (and Dev) Engineers in some sort of contact with their users.

    My 2 cents (no obligation to take them :) )

  • Pingback: Become an Expert Customer-Advocate in 5 Steps | Testing Intelligence - a QABlog