Communication in Software Testing

Introduction

This post is the first in a three part series about communication and natural language in the context of software testing and software development in general. This will be done taking the register approach the way Douglas Biber and Susan Conrad proposed it into account. I will not conduct a full-fledged register analysis, but will rather work out the situational context.

The first part will lay the theoretical foundations, while the following parts will have an exemplary look at two software development processes:

Part 1: Communication and register analysis in general

Part 2: Communication and register in software testing (waterfall)

Part 3: Communication and register in software testing (scrum)

There is quite some buzz about communication and you can find blog posts like the following ones (which are all great reads by the way, but have a slightly different focus):
http://sjpknight.com/ill-communication/
http://www.setheliot.com/blog/2015/01/19/how-to-communicate-tools-of-the-trade/
http://rhythmoftesting.blogspot.de/2014/12/on-symbols-metaphors-and-understanding.html
http://www.rajsubra.com/2014/12/30/effective-communication-for-testers/
Communication is an ongoing topic on twitter as well, I am sure you will have stumbled across one or two tweets about it yourself. If you are on twitter, that is.
All of these entries have one thing in common: they presume and imply a common understanding about what communication actually is and more or less deal with the effects of communication put into use. While I agree that there is something like an innate understanding of communication I would like to have a closer look at communication in software testing from a linguistic point of view.

Communication

If you look up communication in a dictionary of your choice it will come with something among the lines of this:
“the act or process of using words, sounds, signs, or behaviors to express or exchange information or to express your ideas, thoughts, feelings, etc., to someone else”
(Source: “Communication.” Merriam-Webster.com. Accessed January 25, 2015. http://www.merriam-webster.com/dictionary/communication)
I will not delve into the concepts of sounds, signs or behaviors here, but focus on the words part, which in my opinion includes aspects of the other concepts, though.

Models

Models are pretty popular. Not just in software testing, but in linguistics as well. I would like to introduce some basic ones here as background information. I’ll skip the Aristotelian beginnings and start with a sender-receiver based one proposed by Shannon and Weaver in 1949. I know that there are successors and additions, but I think it is sufficient for the ideas conveyed here. If you really want to know about the different models, visit http://communicationtheory.org/
swm
This model describes communication from a more technical point of view.
There are 6 core notions:
• Sender: This is the initiator of the communication and the source of information
• Encoder: A transmitter that transforms the information into signals
• Channel: the medium in which the signals are transmitted
• Decoder: Counterpart to encoder. Transforms signals back into information
• Receiver: The destination where the senders information are supposed to end up
• Noise: influences the transmission via the channel and affects communication
Example:
A stakeholder (sender) writes an email (decoder) to a requirements engineer (receiver), who is having trouble receiving the email on his mobile (decoder) due to weak bad (noise) network coverage (channel).
While this model pretty clearly shows the “how” of communication (for simplicity’s sake only one way and without any feedback loops), the “what” is not really touched, though encoding, decoding and noise are notions that apply to this side of communication as well.
This is where Roman Jakobson comes into play:
jakobson
Every act of communication needs the following factors to work:
• Addressor: Someone who initiates the communication
• Addressee: Someone at whom the communication is aimed
• Code: a common language system
• Message: the content
• Context: referents of the content
• Contact: The channel or medium of the communication
If we take our example again it would be matched like this:
A stakeholder (addresser) writes an email (contact) to a requirements engineer (addressee), who is having trouble receiving the email on his mobile due to weak bad network coverage.
As you can see the factors code, message and content are missing. We would need additional information. Code can be implicit to a certain degree. We can safely assume that they speaking the same language, otherwise the project would be in real trouble (and no, I won’t dip into the problems of intercultural communication here). To identify the message and the context we would need something like this:
A stakeholder (addresser) writes an email (contact) to a requirements engineer (addressee) about changing the GUI color theme (context) from red to blue (message). The requirements engineer is having trouble receiving the email on his mobile due to weak bad network coverage.
gate
A last model that I want to mention is the GateKeeping theory by Kurt Zadek Lewin, which proposes that one has to filter communication in order to block unwanted information. In terms of software development this pretty much reminds me of a product owner who takes in as much information as he can, processes it and conveys only relevant parts to the development team. But in order to do so, he or she needs as much explicit input as possible.

Register

People are exposed to acts of communication every day, with each act differing in terms of language usage and in the linguistic characteristics. This represents the factors described above from a point of view that focuses on language itself. These differences, or varieties, are the main focus of different linguistic analysis methods. One of them is register analysis. On a side note: It is actually the one I find most convincing and I actually put this framework into use for my M.A. thesis back in my first life as a linguist.
“In general terms, a register is a variety associated with a particular situation of use (including particular communicative purposes). The description of a register covers three major components: the situational context, the linguistic features, and the functional relationships between the first two components” (Douglas Biber, Susan Conrad: Register, Genre, and Style. CUP, 2009:6).
The register approach relates what is said with a broader context in a way that explains the why. This is where it really differs from other notions like genre or style. If you are really interested in the details, I can highly recommend their book. A lot of, if not all, ideas described here have their origin in that book. Register analyses are by definition comparative. Where, in what way and how do different registers differ?
For a register analysis you would have to describe the context at first, then describe the persistent linguistic features and then relate those on a functional basis.
The first step to describing the situational context is to find a source for information. If you are part of the cultural/situational background, you may rely on your experience, but should not rely on it solely (well, if possible). For an analysis of the cultural background the following aspects should be taken into account:
• Participants (addressor, addressees, any passive participants?)
• Relations among participants (who communicates with whom in which role? Do they share common knowledge?)
• Channel (written or spoken? Any specific medium?)
• Production circumstances (free speech, planned speech, instant message, planned and proofread email?)
• Setting (share time and place of communication?)
• Communicative purposes (why is communicated? Facts or opinion?)
• Topic (what is being communicated?)
The next step would be to identify the linguistic features. That would probably be the topic of another blog post or even a series of its own. But what we should keep in mind is that communication works best, if what the addressor encodes and what the addressee decodes is the same. Therefore the linguistic features should not vary within a given situational context as this would change the register. This is the reason why a common understanding of terms should be aimed for on a lexical level (Did I hear anyone shout out glossary?). This is also the reason why sentence patterns on a syntactical level are very helpful (Just take your “given, when, then” template from BDD).

So much for part 1 and a the more theoretical framework. Part 2 will have a look a different possible situational contexts within the waterfall model (and no, this does not mean that I really like it, but I regard it as important enough and it is still spread widely enough).