Work First Line Support For Awhile: 99 Ways Workshop #2

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 simple, 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 #2 - Work First Line Support For Awhile - Chris George

As a tester who has actually done this a fair bit during his career, and has actually been a Customer Support Engineer on the phone with customers, I have to say I agree 100% with this approach. there re skills that you learn when dealing with customers in a one on one situation that can really sharpen your overall testing skill set. There are many reasons for this:

- Support calls are closely monitored and tickets are watched and evaluated frequently. This means that the goal of a support organization is to get questions answered, problems solved and customers happy as fast as possible. Therefore, front line support people need to be able to think fast.

- Customers on the phone with a problem are not always the most patient people. The front line support person needs to be able to calmly and deliberately work with the customer and get to the root of their issues.

- Customer support may not have an immediate fix, but they are often able to, and encouraged, to come up with workarounds for situations if at all possible. The ability to consider workarounds and alternative ways to accomplish goals often leads to great insights regarding application design and alternative approaches to testing.

- Since front line customers often have access to screen share tools or remote desktop control applications, it's possible to get status and see what is actually happening on customer's machines.

That's just a quick and dirty run down of benefits and abilities that a customer support engineer needs to be aware of, and it barely scratches the surface of what they actually do. Each environment is different. Some may be primarily phone based, dome nay work mostly with email or chat. Some may set up special meetings so that they can share their workspace and watch in real time what you are experiencing.

Workshop: Becoming a Virtual Customer Support Engineer

I hear what you are saying... OK, that's all great, but we already have a support team. I can't just ask to go and sit in for support. That may be true, but that doesn't mean you can't still practice these ideas and learn from them. here's some thoughts as to how you could role-play "Front Line Support" for your product or for others.

1. Does your product have an active support forum? If so, go in and select 10 issues at random. Why at random? Because real life support engineers may not get the luxury of deciding which issue they deal with right then and there. If they get a call, they have to cover it. By picking at random, you don't get to chose if you will wait to deal with it. It's on your plate right now.

2. Give yourself a time box to work in. depending on the issue, you may want to spend five or ten minutes dealing with each issue. Why so short? Because that's a real pressure front line customer support engineers have to deal with. Time is money, and every minute spent working through an issue is a minute you are not helping another customer with their issue. Plus, working quickly with the issues helps to get you focused on examining the issues and risks and making assessments quickly.

3. If you can determine a solution for a problem, write it out in as concise an direct a manner as you can. If you cannot solve the problem, devise a workaround for the issue and write out the workaround in the same manner. If you can neither solve the problem or devise a workaround, write a bug report for the issue (again, make it as clear and concise as possible. What's the issue, how can you get to it, what are you seeing, and what you would expect to see).

4. If you can recruit another tester, member or your organization, or a friend to help you with this next step, set up a time (perhaps an hour block) where that friend will call you with "issues' regarding your chosen representative product. Get the second partner in this experiment to try to find a genuine issue, or construct a scenario that you can help troubleshoot, and suggest a solution, a workaround or confirm a bug. See how long it takes you to come to the resolution. Try to do this for ten issues, if possible.

Some key takeaways from doing this:

- Ask about machine specifications, applications installed, and other details that could interfere with programs running smoothly

- Consider the way that customers use a product, and try to see what areas are causing them the most pain.

- Look to see what common misconceptions are, and if there are trends and patterns you are noticing.

- For each issue that you troubleshot and resolve, review and see if new testing insights are revealed, and if you can use some of those insights in future testing efforts.

Granted, there's no better way to learn about front line support than actually having the opportunity to do front line support. If you have a customer support engineer or two, ask them if you would be able to sit in for an hour here and there. Yes, actually take calls and answer email or forum questions, if the support team feels you are up to it. If they don't have that comfort level, then do it virtually or as a support role to the actual front line customer support team. If your experience is anything like mine, you will likely discover many avenues you would never consider without experience in this paradigm.