Technical Support Can Be Testing

(Heather) #1

A recent article series from James Thomas, Chris George & @norry was published on the Dojo titled “Technical Support Can Be Testing”.

I’ve never been involved in technical support with a company but I was involved in gathering and replying to beta user feedback to help improve the application pre-release. There are similarities but they’re obviously a bit different.

I know some people have moved from a technical support role into testing. Others have a very close relationship with their technical support staff. I was wondering what experiences you all have of working with technical support or perhaps even helping them out? Do you have any caveats you have come across that you would warn others about?

(David Shute) #2

I moved into testing from support. For me, it’s essentially the same skillset, just with a different goal. Short version.

Testing, you’re examining the product to figure out how it operates and how it fails to meet expectations.

Support, you’ve got a broken expectations and you’re operating the product to figure out why it failed.

(Jesper) #3

:raised_hand: 5 years of supporting people getting on the WWW.

I some smaller IT delivery companies I know of the test team and support team have the same manager. some even cycle the support watches. You get to know all the nooks and crannies doing both.

(Lisa) #4

I worked in tech support for many years for a software company. And when I say tech, I mean really technical. I did a lot of coding, I had to go through hex dumps to find where the customer’s database crashed, test installation and so on. It’s what led me into testing. Our company had no testers (this was in the 80s/early 90s) and our new releases often had terrible bugs. We asked our devs to give us advance copies of the new release so we could find the bugs before the customers did. That made our managers say Oh, testing would be a good idea, let’s start a testing department, and that’s where I went.

At my current job, when I started, we didn’t have dedicated support staff, so I spent probably half my time on support (fortunately, email only, no phone support). It was a super way to learn how customers use our product and where their pain points are. I still help with support and find it really helps me do a better job of asking questions about proposed features and do better exploratory testing. When we release a new feature, I watch support tickets to see what kind of feedback we get that maybe our analytics won’t tell us.

Doing nothing but tech support on the phone leads to burnout pretty quickly, but helping with support on a regular basis is invaluable to me. And, it’s really rewarding to hear nice feedback from a customer who is happy with the help I gave them!

(Chris) #5

Before I did any software work, I did some technical support at an alarm monitoring company. I was the guy who called to say that your alarm was going off and to see if I could help.

Consequently, a large portion of my job was helping people troubleshoot false-positive alarm systems.

This ends up being nicely analogous to:

  • Build Breaks!
  • Test failure!

and ergo kind of a lot of test work, in my opinion. It has been a long time since I interviewed someone for a truly introductory level testing job, but talking with someone about how to troubleshoot a technical thing isn’t a bad “I wonder if they can feel their way around” interview question / story to tell an interviewer.

(James) #6

Similar here, although these days I don’t do support on any kind of regular basis.

I was managing the support team at Linguamatics when I became our first tester, and split my time 50-50 between test and support. My first hire into the test team was split the same way and I’ve recruited out of support several times since.

As well as the advantages you mention, I find that deep knowledge of the product gained while it is in development gave us a massive head start when support calls started coming in immediately after a release. Unlike a completely separate support team, we weren’t learning the product just before/at the same time as our customers.

This is one of my favourite pieces about support/testing crossover: