A long time ago I was working in customer support, spending my days speaking to unhappy customers who had purchased some sort of electronic device. People generally didn’t pick up the phone to tell us how pleased they were with their purchases. Sometimes they would call to ask for a technician, others to ask how to properly use their machines. And of course, there were the ever fun moments of somebody simply yelling and venting about their faulty product.

Writing tickets about these incidents addressed to the company, I was wondering about things like “Don’t they see that step x of the manual doesn’t work?”, “How hard is it to make a note telling us how long it will take to be fixed?”, “No, YOU tell the customer that it is normal for the machine to make a buzzing sound, loud enough to be heard next door”.

Years later, working on the other side in a development team, I thought about my frustrations from my customer support years. The last thing I wanted was to make the same mistakes I had been complaining about. So, here are some of the measures we put in place to get the most from the customer support’s expertise and knowledge and to enable them to provide better solutions for our customers.

One backlog to rule them all

All issues coming from customer support requiring technical assistance were logged in the development backlog. The only thing that distinguished them from a “normal” internal bug ticket was that they were marked with a “support” label. Filtering on that label made it easy for the product owner to assign priorities to them or even turn them into new features. Another benefit of having support tickets in the development backlog was that it improved the transparency of the efforts put in developing new functionality versus fixing existing issues.

Make backlog accessible to support

We gave customer support access to view the development backlog, so they could follow the resolution of their ticket. Instead of having a generic comment on their plate like “working on it” or “TBD” they could see the priority given to it as well as the work it took to fix it. The more details you have on the history trail of the fix, the easier it is to convince the customer that their problem is being addressed. Urgency is perceived differently by customers than production teams.

Support ticket – Handle with care

We agreed that support tickets needed to have a higher degree of information than the average bug ticket. If the ticket could be closed because the software “worked as designed”, we needed to point out where this was documented, so that the next time support could point customers to that. If it was not documented, we needed to provide solid arguments why the implementation made sense. When an issue would take long to fix or be addressed we needed to add some justification of our actions. Preferably, something that we wouldn’t be embarrassed to say out loud ourselves.

Rotate developers handling support requests

Each week a different developer would take care of the support tickets. They could handle the situation themselves, or assign it to another team member that they thought would be more efficient in resolving the situation. This was beneficial because everyone from the development team got to see what issues from real users looked like. Developers would also think about what kind of information they would like support to add, so that fixes would be faster, improving the support lifecycle.

Analyse customer support requests

Besides the obvious bugs that people reported, we took time to analyse the issues that customer support handled on the fly and never reached development. If people would call for the same problem over and over again and support would help them solve it over and over again, why not take care of it and make everybody’s life easier? Besides that, closed support tickets sometimes contained excellent features ideas. Customers might not actively get in contact to request a feature but might drop an idea or two while waiting for their problem to be fixed.

Keep support in the loop

One of the worst situations that you can get in as support, is to have a customer ask you questions about a feature you are not even aware it exists. Sometimes you can swing it with a “please describe to me what you see” and then hope you can improvise something based on previous functionality. To avoid this situation, before releasing a new feature we would first enable it for our support (we had toggle switches in place) so that they could try it out and be ready for customer questions. We also asked them to note down anything positive that the customers noticed to have a better understanding of what people like. As a bonus, their feedback provided a good usability and acceptance test.

Respect customer support

If you measure your product’s quality by customer satisfaction, you probably want to have the people that talk to your users feeling respected and valuable. This is especially the case when customer support is outsourced and doesn’t have an invested interest in your product’s success. Take the time to listen to the people that deal with the end users of your product and learn from their experience. Give them a channel to communicate the difficulties they face and what they need to improve their work. Create an environment of trust so that they can provide an honest feedback to you and how you handle your support requests.

Nowadays, we would have more automation in place to improve our customer support. Maybe training an AI system to triage tickets or to even provide automatic responses to common requests. To extract behaviour patterns from existing tickets and help define new features based on them. But will customer support be completely automated? Forrester’s top customer service trends for 2018 sees a decrease in the number of support agents employed, nevertheless predicts that there will still be a need for highly skilled professionals to handle difficult customer issues. So improving the collaboration between customer support and your development team to create super agents that care about your product might not be a bad idea after all. Heck, they will be the ones that your AI system learns from.

The situation where development and management don’t speak the “same language” is something that many of us have faced one time or another. But what happens if you are a tester and literally don’t speak the same language as the rest of the people around you?

I first started working as a software tester 3 months after moving to Germany. At that time, I knew neither German nor anything about software development. The official language of the product was English but everybody in the team was German. All documentation was written in English, all meetings were held in English, but of course, most office conversations were in German.

Here are some challenges I faced, being a non-native English speaker, working in a foreign country, without speaking the local language.

Testing literature in English – Me non-native speaker

Without any knowledge of testing or software development, I had to look up literature to learn the fundamentals. I am lucky enough to be quite comfortable with English, so finding reading material was not an issue. Nevertheless, I wonder if I still have not grasped some ideas properly, due to my non-native English knowledge. I attempted to fix that by looking up Greek texts, which is after all my native language. I found that the translation of the terminology just confused me even further, so I settled with just English texts, come what may.

Understanding the requirements of the product

In my opinion, to test something properly you need to initially understand what it is supposed to do. In the beginning everything was communicated to me in English as any attempt to talk to me in German resulted in an empty stare. But as years went by and my language skills improved, meetings with important feature information would be held in German. Although I could understand what people were saying because I was familiar with the context, I was still missing important details, the ones that help you identify risks to support your testing. Eventually, whenever I felt uncomfortable with the level of detail I had, I would have a one on one meeting with the product owner to clarify all of my questions. Not 100% bulletproof, but it was good enough.

Understanding the market of the product

Our product was mainly addressing the German market, meaning that

• we needed to develop something that would resonate with the German public, and
• customer support was done in German.

Both of these parameters were causing me huge headaches in my testing efforts – especially when I started – because I had not lived in Germany long enough. There were obvious problems, for example I could not read any material about what the tendencies of the local market were nor any customer tickets. But there was also the more subtle issue that I could not provide any input, besides obvious cases, on what would be considered attractive or offensive for our customers. Only years of living in Germany partially removed this impediment.

No water cooler talk

Software is produced by humans (at least for now) and I think a good part of testing is to understand and anticipate the behaviour of the people working on a project. Pleasant “shop” conversations over lunch can reveal a misunderstanding in a requirement’s implementation. I spent a couple of years registering all conversations in the office as white noise, missing bugs that were revealed in casual chit chats. Improved language skills was the partial remedy for this drawback.

Misunderstandings

I was very surprised when a colleague told me that we should show empathy to our customers. Surely, he didn’t mean that. Why would I hold a grudge against our users? After we stared at each other for a couple of seconds, we looked up the meaning of the word. To my surprise, the Greek word εμπάθεια, which is used as a synonym of malevolence or hate, in English has the positive meaning of compassion or sympathy. Since we were all non-native English speakers, there were more misconceptions of this kind in bug descriptions and emails, causing anything from awkward silences to full blown arguments, but always consuming valuable time.

Avoiding communication

One of the worst consequences of the language barrier was the hesitation to start a conversation with a colleague. On my part, I felt inadequate explaining anything in German, from a bug I found to a concern about something I tested. On the other hand, there were teammates who were equally uncomfortable speaking English. Eventually, I realised I trusted the people I communicated with on an equal footing more and this was creating a bias in my behaviour. Unfortunately, I never found a good solution for this aspect.

It is not all bad though. The science is in and communicating in a foreign language takes emotion out of decision making. This can be very useful when you need to evaluate risk in order to choose what to test. Additionally, due to the language barrier you can insist on clarifications of requirements, so that you get them straight, helping everybody to define them better.

There were many questions that haunted me over the years regarding this topic. Would I be a better tester if I were a native English speaker, having a better understanding of all of the literature? Would I be a better quality engineer for my product if I was proficient in German? So far, my answer to both these questions is that I would be neither better nor worse, but surely a different professional.