Testing in Babel or Experiences from Testing in a Foreign Language

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.


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.

The Surprising Diversity of Password Retrieval

In the last weeks of my pregnancy the “nesting” instinct kicked in. Since I was no longer working, I had the time to do important chores, such as trying out all the pens in our household to get rid of the ones that were empty. Once I was done with the physical world, I went for the virtual one. I uninstalled unused programs, deleted duplicated folders and my final gargantuan task, was to clean up my online presence.

I knew there was an obscene number of accounts I owned that I would never use again. This was due to the facts that I have lived in different countries, that my interests over the years have changed and that when I was younger I wouldn’t give it a second thought registering to any website. For many of these accounts I had no clue what my password was, so I had to go through the “Forgot your password?” process multiple times.

I have tested this action various times at work, so I thought I knew well what to expect. To my surprise, I encountered an abundance of different implementations varying from air tight secure ones to having the password sent in plain text to my email account. After going through the process at least a couple dozens of times I’ve noted down some factors that seemed to affect the diverse implementations.

Site’s inertia

There still exist sites that have not changed much over the last years. They have a fixed set of features loved by their customers, old and new, who are probably constantly logged in. Those sites had the tendency to have a process with whatever good practices were available at the time of implementation but never revisited since.

Size of the enterprise

Sites belonging to bigger organizations had the process generally in pretty good shape, since mishandling could lead to bad publicity or even lawsuits.

Site’s target audience

Sites that were addressed to technically savvy people seemed to handle the process better than the ones aiming at non IT-related industries.

Site’s location

The origin of the website also affected the implementation of the process. There were some German sites had me jumping through hoops to retrieve my password, including having it sent to me by post (the retro one, with the envelope).

In this competitive market, we always strive to release new features to make our software more appealing and useful to our users. But do we ever take the time to review if what we already have is in a state of the art condition? Should we have an active process of reviewing existing functionality? Or maybe act on demand, triggered by the feedback of our customers?

My impression is that revisiting existing and familiar functionality is a good exercise which can advance knowledge transfer and lead to better, up-to-date, code. The challenge is to find the time to do it in our day-to-day work, rather than wait for the slack of a parental leave.