Three Techniques for Improved Communication and Testing

Anyone who has worked in the software industry for a while can tell you stories about projects that were on the verge of failure. Many initiatives fail even before they reach clients, which is especially disheartening when the failure is fully avoidable.

Miscommunication is a common source of preventable failures. Because successful software delivery needs the entire team, everyone must choose their words carefully so that they express what they truly mean, are sensitive to the sentiments of others, and consider all elements of a situation.

Here are three questions to ask yourself while speaking about your software testing initiatives to ensure you’re considering the power of words.

Are you taking into account other viewpoints?

As project teams grow in size, people’s interactions become less frequent. Silos form and teams interact less, causing members to fail to notice any perspective other than their own. Tunnel vision takes over, and individuals lose out on experiencing diverse points of view. In each debate in which I am asked to participate as an advisor, I make certain that the appropriate participants are present—and just the concerned parties—so that we may obtain the essential viewpoints.

As the saying goes, every tale has three sides: yours, mine, and the truth. This summarizes the most common issues in any discourse. The assumptions underlying a remark are rarely discussed, and we fail to see why our choice of words may paint a completely different picture to the listener. For example, comments like “I need this done before the end of the day” don’t explain why the assignment must be completed today. And with such a commanding tone, no one is likely to ask clarifying questions. It gradually degrades team morale, which harms the outcome.

Consider the difference if the request was phrased as, “Considering the time required to solve any serious issues that may be uncovered, may we try to complete all of our duties by the end of the day?” Yes, there are more words, but the meaning of those words has changed. The tone of the dialogue has changed to one of respect, and a channel of communication has been established for both sides.

Consider the difference if the request was phrased as, “Considering the time required to solve any serious issues that may be uncovered, may we try to complete all of our duties by the end of the day?” Yes, there are more words, but the meaning of those words has changed. The tone of the dialogue has changed to one of respect, and a channel of communication has been established for both sides.

Do you make constructive criticism?

Have you ever attended meetings where every suggestion was rejected even before the speaker had finished outlining it? Many individuals are unaware of the influence their words have, especially when they are negative. Testers are analytical thinkers, and they frequently begin by considering why an idea probably wouldn’t work. Although it is beneficial to have constructive criticism, speakers shouldn’t always take these remarks too personally. However, constructive criticism differs from the actions of naysayers.

There was a time when a client would repeatedly report a problem that was brought on by a specific character. We were continually fixing the system one issue at a time, and there were many components with distinct specific character restrictions. When we discovered that the problem was being caused by interactions between components, we decided to develop ways to identify these interactions. Ideas began to come to mind:

• Completely redesign the code.
• Clean up all incoming and outgoing data to the database.
• Limit the use of special characters across the system.
• During testing, focus only on the primary flows.

While all the ideas were being debated, one person continued dismissing each and every one:

• Without unique characters, security wouldn’t be available.
• Since this would need more time, we can’t automate the routine processes.
• Every flow is significant, and there are many customers.
• A lot of work has to be done on legacy code.

That individual left the meeting for a call after two hours of discussion. The group started talking right away. After considering the advantages and disadvantages of each strategy, we chose one to put into practice to resolve the problem. The critic had a kind heart, but he was unaware of how his remarks affected the team’s chemistry.

After learning about Edward de Bono’s idea of the six thinking hats, I started using it in talks to ensure that everyone had an equal opportunity to voice their opinions.

“Six Thinking Hats” is a way of investigating an issue from a variety of perspectives, but in a clear, conflict-free way. It can be used by individuals or groups to move outside habitual ways of thinking, try out different approaches, and then think constructively about how to move forward.

The naysayers’ influence is much diminished when everyone is “wearing the yellow hat,” which pushes everyone to concentrate on the advantages. The team gradually developed the habit of praising an idea’s positive aspects before condemning it. Our talks became more fruitful, partly because of the six thinking hats idea.

What are you focusing on?

Every project I’ve worked on has had at least one situation when software testers were questioned, “How did you miss the bug?” What comes to mind when you hear that question? Did you take that to mean “Why did you miss the bug?” or “How come you missed the bug?” Did you begin to formulate a response to the question depending on how you heard it?

Consider the “Mary had a little lamb” heuristic from Jerry Weinberg’s books:

Why does the lamb love Mary so? Mary so, Mary so?
Why does the lamb love Mary so? The eager children smiled,
Mary loves the lamb, you know, Lamb, you know, lamb, you know,
Mary loves the lamb, you know The teacher’s happy smile. – Wiki

Emphasize each word in the phrase and take note of the thoughts that emerge as a result of each stress. Consider the query, “Are you going home early today again?” If you emphasize “Are you going home early again today?” it might imply that the asker was hoping to leave early as well. If you emphasize “Are you going home early again today?” it might indicate that the asker believes you go home early too frequently. And if you emphasize “Are you going home early again today?” it might suggest the asker believes you should stay for something significant.

In the “Why did you miss the bug?” scenario, the person asking the question may be interested in learning why the problem was not discovered sooner, yet the inquiry might be construed as a personal attack. The individual addressing the inquiry may become defensive and make explanations for why the problem was not discovered during testing. The fundamental issue is buried in the manner in which the inquiry was posed.

As a result, I’ve toned down the “Why” inquiries and rephrased them to seem more like a dialogue than an interrogation. Instead of “How come you missed the bug?” “How do you believe we might have detected this flaw before release?” I inquire. I instantly come up with some fantastic suggestions that we can put into action. It also helps me pinpoint the source of the problem.

Next time you want to ask someone in your team a question, take a moment to consider the “Mary had a little lamb” heuristic and consider whether the question may be misunderstood. Later on in the project, this can save a significant amount of time and labor.

Closing

Each of us tends to spout off words as they emerge to us. The power of each word must be understood since it can improve or degrade any discussion. Your team will communicate more effectively and do more efficient software testing if you keep these three questions in mind to ask yourself throughout every contact.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile