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.
More Questions Than Answers 