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.

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.

I was always a good student. Never excellent, but good enough not to get any complaints from home. Not to be misunderstood, it was not only my parents pushing me to have good grades. I liked being a good student, I would just never make any extra effort to become the best one.

My high school years are far behind me and after some time working as a software tester, I came to realize that I was approaching work the same way I was approaching school. I had a collection of techniques that, back then, I was applying unconsciously to minimize the amount of time I would need to spend studying. Here is a short overview of my arsenal of tricks and how I used them in a work context.

Names, Dates, Locations, Numbers

The first thing that any lazy student not wanting to make an extra effort would do, was to learn the “SOS”. The term “SOS” was used to denote anything that was considered important by everybody. Dates and locations of battles, names of generals, number of soldiers in each army. They were trivial, and even though they were too obvious questions for a quiz, it would be too risky not to learn them.

As soon as I started working as a software tester, I considered it to be a good idea to first go over anything that was too obvious to fail. It was quite improbable that somebody would develop a “log in” button that could not be clicked on, but I preferred clicking on it by mouse or keyboard just to be on the safe side.

Once the specifics where out of the way, I focused my attention on the people controlling the exams, the all-powerful teachers.

Each Word Matters

Every teacher had favourite topics. Even if they wouldn’t say so, it could be hinted by the tone of their voice or the amount of time they spent on a subject. My lazy self would pay attention to identify the material that was close to their hearts and focus on it for the exams while only skimming over the rest of the book.

At work, I replaced the teacher with the product owner or the customer, the studying with testing and the exam with a release. The outcome was to test thoroughly what was perceived important for the stakeholders before we delivered.

My next trick was the jewel on my crown of gimmicks.

Establishing Yourself

Early on I realized that once teachers believed that you were a good student, they stopped questioning you. My approach was to study a bit harder in the beginning of the year to get good grades and establish my good name among the teachers. The rest of the year they would just let me do things on my own pace and comfort.

I found myself doing the same thing when I started working on a testing project. Working hard in the beginning to prove that I was good, made it easy later to convince management of new processes and workflows. After all if our team was delivering a product in good quality, why change a running system?

Graduating

Of course all good things come to an end. When the time came to take my university entry exam, I’ve realized that with my method I was good in getting good scores only within the confinements of my school environment. To get a passing grade in that exam, I had to study seriously and methodically the entire syllabus.

Nowadays, I try to keep up to date with all the latest developments in the testing world, including techniques and tools that could help me improve my work. There is an abundance of resources from books to online tutorials that can teach us almost anything technical that comes to mind. But I still wonder what other skills we need as testers to make us good at what we do? The incentive for the ones mentioned above was laziness but there must be others, prompted by more noble sentiments. And if there are, how and where do we learn and practice them?