You are here

You are here

Tips for testing with customers without making a fool of yourself

Amy Reichert QA Engineer, RxMxUSA

Once in a while, a QA manager comes up with the grand plan of testing with customers before a go-live event. The benefits seem obvious: the QA tester gains exposure to an actual customer and their specific application user workflows. The customer benefits by imparting their knowledge on how the application works in their setting with a member of the development staff. The problem is that the majority of testers don't receive training before being sent out to the customer.

For example, customer service or sales personnel receive at least basic training on how to approach customers, what to say, what not to say, and basic business principles for interacting with customers directly as company representatives. However, QAs typically don't receive this information.

Now, one would assume that most experienced testers have enough professional knowledge and skills to manage on their own. But think about that for a moment more, and consider some of the QA testers you know or have worked with. There are likely several examples of well-meaning, highly intelligent people with little to no personal interaction skills. Is it really wise to send unprepared personnel to a customer site without spending time reviewing etiquette and expectations?

The answer is no, and it really isn't respectful to the employee or the customer, but it happens all the time. In order to receive the benefits of this practice, employees need to be prepared with at least the basics of how to gain information without offending or otherwise unintentionally causing harm to a business relationship with a customer. QA testers should equip themselves by thinking through possible situations and keeping the following tips in mind to make the experience worthwhile for everyone involved.

Respect is a two-way street

When arriving at the customer's business, remember that mutual respect is essential. You may not get it, but you need to give it. It's important to acknowledge that development staff and customers operate with different objectives for the software, whether in workflows or points of view. Discover more about this by observing their actions or reading through their tests. See if you notice a common theme where the application has repeatedly failed for them or they're working around a configuration setting they don't realize they can change. Ask direct questions in a professional manner. Explain what you're trying to accomplish by gaining information about their workflow up front, so participants have a chance to give you the data you're looking for.

Be open-minded and expect to learn. Seeing how the customer uses the application may open your eyes to other uses that aren't officially documented. Customers may use it in a completely different way or in an unanticipated style. Respect their knowledge as well as your own. There's no one right way to use an application—people are creative. Respect the possibility that you'll learn more about the application from testing with customers than you realized.

Ownership belongs to the customer

Another thing to keep in mind is that the process belongs to the customer and their workflows—not what you think they should be doing. Now, that doesn't mean you can't suggest alternate configuration settings, because they may not realize they're there. How many people do you know who actually read the release notes? I'm guessing it's pretty close to zero. So unless someone tells them otherwise, they may continue to use the application as they always have and come up with workarounds to avoid new features that are automatically passed to them. Work with them to improve their appreciation of the application, but remember that ownership belongs to the customer.

In other words, consult, don't direct. Point them in a direction you feel they may find useful. Show them how it works and what it does in the context of their workflow. Compare and contrast differences so they can make a solid decision. Whatever you do, don't direct them to look it up in the help menu or documentation. Find it yourself and present it to them if you feel it'll improve the partnership between the business application and their specific workflows.

Information exchange

When you're at a customer site, keep in mind that you're making a connection that is useful for yourself as well as the customer. One important item to remember is to discuss options and allow the customer to choose. Ask them questions, and share the information that you can with them, keeping in mind that some items may be proprietary and confidential. Know and understand what you can and can't discuss. If you're not sure, ask first. The larger the company you work for, the harder it is to find a person who knows. Check with your manager or a development director, and then move to a support contact or an account executive. If you still aren't sure, then don't discuss it. Wait to get more information and then share it with the customer at a later date, once you're confident it's appropriate.

One important thing that QA testers and other development staff must remember is to not be drawn into a negative conversation about the application or your employer. It doesn't build trust when you participate in or start negative conversations about the product you test or code. Remain neutral, despite having negative opinions, and don't rant, regardless of how tired you are. Respect and trust go both ways. If you don't publicly respect the company you work for while at a customer site, they won't respect or trust you. After all, if you can talk badly about the company you work for, what will you say about them? Keep to the facts and keep your credibility intact. Learn, experience, and use it to your testing advantage.

Keep learning

Read more articles about: App Dev & TestingTesting