Meta: The Next Level in Your Written Test Reports

Once upon a time I wrote an article for the Testing Planet. I never got to publishing it on my blog. It doesn’t seem to be featured on the Ministry of Testing website any longer, however, I got a question via LinkedIn about the “lost” article. Apparently, a teacher of English used it in her class. So I’m happy to republish what I think is the actual version that got published in the Testing Planet magazine. 

In this article I’d like to explore the importance of recognizing cultural thought patterns and how they have an impact on expressing ourselves in writing. I will discuss how I use Robert B. Kaplan’s schema of thought patterns as a heuristic when reading and writing texts (be them bug reports, status reports, etc) to recognize problems in them and to remind myself to consider the audience’s needs.

As a tester I’m looking for and handling information about the product, about the overall status, risks, and perceived quality of the product. I deal with ideas, perceptions and assumptions of my own and others about the product. That’s a lot of information of different kinds and on different levels of abstraction. Therefore, a big part of my job is to convey information by using language in a way that makes the information tangible and easy to understand for my stakeholders.

Different languages enable us to express ideas and convey information differently because a language is usually tied to a distinct culture or cultures. For example, translators bump into this daily: what is available as a concept (expressed in a single word or a phrase) in one language may not be available in another, or it may have a different meaning when translated directly or word for word. Therefore, what makes the translators’ job difficult is not the lack of words or phrases but a lack of matching ideas available in the languages at hand.

The world looks different looking through the lenses of different languages that originate from the context of a culture. For instance, when an American novel was translated from English into Estonian in the 1960s, a problem occurred: how to translate the word “hamburger”? Sure, you can split the compound noun into “ham” and “burger”, translate these into Estonian and put them back together to get a raw and direct translation. You could just keep the original word “hamburger” and introduce it as a new term. However, the problem remains: Estonian culture lacks the concept of what a hamburger is like as it wasn’t available as a regular food item in the Soviet Union. At the time, translators came up with a new term which could be translated back into English as “cutlet bread”. This term is actually still in use from time to time but nowadays “hamburger” as the original term is more common: the concept and the corresponding word from one culture have traveled across time and space, and made home in another culture as well.

Alright, enough of hamburgers, let’s get to the real meat.

Testers working in cross-cultural distributed teams may end up explaining the impact of a technical issue to business people, and explaining an issue with solving a business problem to programmers. That’s where the jargon of different specialties also adds to the complexity of language use. If we end up using our second (or even third) language to communicate with different parties about all kinds of different information as mentioned above, we’re set up for a fair amount of misunderstandings and miscommunication. Communicating ideas efficiently between languages isn’t just about using correct terminology and grammar. It’s about the overall logic, structure and how information is ordered in your written reports or other communication such as e-mails. This is why we need to go on the meta-level and understand how the language we’re speaking influences our thinking.

I shall digress here. When I entered the university to study English language and literature, I quickly learned that I didn’t know how to write essays anymore. I used to be good at it in high school but suddenly, I wasn’t anymore. When I saw the schema about thought patterns by Robert B. Kaplan, I finally understood why. Here’s the schema:


The schema, or rather a series of sketches, illustrates cultural thought patterns in some languages. It is a very high-level and rough model (remember, all models are wrong, some are somewhat useful) and it doesn’t pretend to be the ultimate truth. Kaplan used this to explain why teaching the correct grammar and syntax isn’t enough to help produce understandable and acceptable texts by people who speak English as a second language.

That being said, the importance of the schema lies in how it highlights the differences in thought patterns using what Kaplan calls “the contrastive analysis of rhetoric”. Importantly, Kaplan points out that since sentences are usually used in a context and not by themselves, it makes sense that the writer of a text also “recognizes the logic on which the context is based”. In other words, we can’t make ourselves clear in English for native speakers of English if we’re following the thought patterns of our own native language. 

Going back to my experience as a freshman at the university, it wasn’t that my writing skills had disappeared, it was that my thought patterns, how I used to express my thoughts in my native language was different from English and the Anglo-American writing conventions. The pattern of Estonian is close to that of Russian or Romance writing. Looking at the schema you can see that parallel thoughts, making different moves, inserting digressions or even approaching the subject in a circular fashion are acceptable in different languages but not so in English which tends to be very straightforward.

When writing in English, you have to go about writing a text differently or else your writing is likely to be considered unclear and incoherent by native speakers. Following these three simple rules when writing in English may help:

  1. tell them what you’re going to tell them (make it explicit from the start what this piece of writing is about and what the reader will learn);
  2. then tell them it (explicitly present information, preferably using linking words like “firstly”, “therefore” etc); 
  3. tell them what you’ve just told them (summarize the content). 

In addition, it should be noted that digressions are not tolerated because they don’t add anything substantial to the central idea in the paragraph or paper. Nevertheless, looking at the schema you’ll notice that other languages are accepting of wanderings and digressions which means that when writing the “meta-level” of thought patterns of your native language will “shine through” your writing.

Ignoring the thought patterns of English when writing in English will come at a cost: you’re likely to “lose” your reader in your wanderings which means you’re running the risk of remaining obscure. Also, you’re forcing the reader to make a bigger effort to understand what you’re saying by shifting some of the responsibility of understanding to the reader. In my experience, the underlying logic of English makes the writer almost fully responsible for expressing ideas clearly and helping the reader understand what is being said. In other languages, it’s acceptable to be somewhat mysterious and have the reader do the work.

Now you may say that it’s all fine for writing a paper but what does this have to do with testing at all?

Firstly, I believe it’s useful to be aware of the difference in thought patterns when writing about testing (or any other topic for that matter). There are plenty of bloggers and authors who write about testing in English as a second language. To spread the word about your awesome ideas, it makes sense that you consider your audience and the distribution of responsibility of understanding the ideas expressed.

Secondly, since the thought patterns are ingrained in you and you’re unlikely to be able to switch your native pattern off and another one on, awareness of the pattern will help you evaluate your bug reports, for instance. Are you giving the most important information up front? Is your summary of the problem concise? Is the information in the bug report strictly relevant or do you sometimes digress when describing the steps for reproducing the bug? If you add extra information, is that relevant? If it is, do you signal the reader somehow that this is, in fact, extra information and not part of the central problem? 

Thirdly, if you’re someone who has to write lengthier test reports, you can benefit from observing what the order of information is and how descriptions of problems, risks, and observations about the product are linked to each other using linking words.

To summarize, being conscious of the thought patterns may help you realize why your writing may not be well-understood, and why you may be failing to deliver your point. It’s also a valuable reminder of the complex tool that we use to communicate our ideas, namely, the human language placed in the context of a culture. Keeping the meta-level in mind can help you take more responsibility for communicating clearly with your stakeholders when the working language is a second language to you because it will help you recognize the influence of your native patterns. It can also help remind you to zoom out from the level of terminology or syntax to remember to look at your own patterns from afar and be willing to look inside the patterns of your audience.




2 thoughts on “Meta: The Next Level in Your Written Test Reports

  1. Pingback: Testing Bits – July 7th – July 13th, 2019 | Testing Curator Blog

  2. Pingback: Five Blogs – 15 July 2019 – 5blogs

Chime in!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s