Communication in Software Testing: Waterfall

Introduction

This post is the second 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 laid the theoretical foundations, while this part will have an exemplary look at the waterfall software development process:

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)

Waterfall model

The waterfall model is one of several software development processes. I took it as an example as it is a representative of the heavyweight, sequential models around. And no, I will not get into the pros and cons discussion here as that is a topic totally of its own. The waterfall model is still seen around, though there is some variation according to the different phases.

We can identify five major acts of communication in the model:

1. Requirements collection
2. Requirements document
3. System architecture
4. completion of software
5. Testing documentation

While I am aware that there are other acts and that often communication is not as sequential as depicted, these ones stand out as the ones that are always present and therefore I will have a look at those.

I will now outline the situational context of these five acts of communication using the template proposed in part 1 (which you will have read of course…).

Requirements collection

The participants are somewhat defined, the addressee is not necessarily a person of its own, unfortunately. More often than not it is a customer taking on the role of a requirements engineer, if you are lucky though, a system architect or developer is involved as a passive participant. The purpose and topic are well defined as well, both participants want to establish a common understanding of what kind of software is to be built under which circumstances and conditions.

Talking about circumstances…the circumstances of the communication, the channel and the settings are where it gets somewhat discordant and you could actually argue that there are (at least!) two registers really. On the one hand you have written communication in form of emails and documents, which are planned and (hopefully) proofread speech. These don’t share a common time and place of communication. On the other hand there is oral communication (be it workshops, phone calls or a chat in the kitchen), which is spontaneous, but share a common time and place of communication. Additionally, more often than not the purpose swings a bit more towards opinion than fact in oral communication.

Requirements document

This one is actually rather defined. Participants are not necessarily persons of their own, but roles. It can be customers taking on the role of a requirements engineer and developers taking on the role of a system architect. This of course influences the relationship between the participants, hence the customer to contractor relationship in parentheses. The central part of this communication act is the document, which is conveyed and contains all the information gathered in the requirements collection communication act in a refined way.

System architecture

Depending on the project the document, which is again a central part, can vary: from diagrams to full fledged functional system description. This is the first act of communication where no customer is involved. Please take into account that the basic waterfall model assumes that each phase is fully reviewed and verified, so the last phase of customer involvement would have been the requirements document. In reality most of the waterfall projects I have had contact with had the system description verified by the customer just to make sure that it really matches the requirements document. Depending on the project, this is where testers are involved for the first time as (not so) passive participants. Place and time of communication are not shared.

Completion of software

To be honest, I am not fully satisfied with the name of this communication act, but did not really come up with anything better, so if you have any suggestions, let me know!

The situational context of this communication act is quite interesting actually since the medium differs tremendously in being the software itself. Of course there will be some kind of email notification, but in my opinion it is the software itself that is at the core of the communication. While other information are helpful and will probably improve the act of testing itself, the one thing that is really needed is the software, hence this communication act. Developers will usually inform other people, i.e. pm and customers, but in accordance to the waterfall model the testers are the addressees. Testers in this case is a role, not necessarily persons of their own.

Test documentation

If you were looking for a complete analysis of all the test documentation as proposed in IEE829 I have to disappoint you. While contracts may demand the creation of test strategies and other documents, when it boils down to the working level, the bug report is the one always present. As you can see from the table, I assume that testing happens when the developers are not available, therefore oral communication is no option in this case Yeah, you could use the telephone, but the usual way is to file some kind of bug report, be it a mail, a document or in a ticket systems of your choice (oh, well, probably the customer’s choice, but anyway). Depending on the project bugs will be reported to the developers or to the customers (in this case the whole waterfall could start all over with the bug taking over the role of the requirement). I also included opinion as a purpose as there might be situation where the requirements don’t specify how the system is supposed to work and the tester should report awkward behavior nevertheless.

Evaluation of the communication in the waterfall model

Let me warn you: Since I am a tester, this will have kind of a tester’s flavor to it. But first of all, it is rather striking that most of the communication in the waterfall model do not share a common time and place of communication. Especially the time discrepancy bugs me (I just had to use that pun somewhere…). If every phase is neatly separated from each other the timespan might just get too big between the phases. Let me explain that: The requirements document may be finished, but development (and thus the system architecture) may be postponed for some reason. In the meantime, requirements may change and you would actually have to rework the requirements and revise the requirements document. This results into additional workload if done or a system being built not fulfilling the revised requirements if not done. This problem will only balloon if later phase are postponed.

Remember the GateKeeping model from part 1? If applied to the waterfall model, it will look something like this:

From a tester’s point of view, there are four gatekeepers between the customer and you. Do you remember the game called “broken telephone” or “Chinese whispers”? This is actually the effect that will eventually happen. As a consequence you really need communication participants who really know their job and will make sure none of the vital information is lost (most likely there will be some loss anyway just to simple noise in communication). What you will have to avoid is this:

“What is said and what is meant and what is understood can be three very different things.” Dick DeVenzio

— Christian Kram (@chr_kram) 19. Januar 2015

From a communication point of view, though, this will be hard when you only communicate with the addressors and addressees in the phases directly above and below you. Furthermore, there is no real emphasis on reinforcement and feedback in this way of communicating.

Oh, well, seems I got a bit into the pros and cons discussions here as well. While there may still be situations where the waterfall might be adequate, the communication side of it is certainly on the non-recommendable side.