3 Methods for Better Communication and More Effective Testing

Ask anyone who has been in the software industry for a while, and they can tell you stories about projects they’ve worked on that were on a death march. Many projects fail even before they can reach customers, and it’s more disappointing when the failure is entirely preventable.

One common cause of preventable failures is miscommunication. Successful delivery of software requires the entire team, so it’s imperative that everyone choose their words carefully so they convey what they really mean, are sensitive to others’ feelings, and consider all aspects of a problem.

Here are three questions to remember when communicating about your software testing projects to ensure you’re considering the power of words.

1. What are you emphasizing?

In every project I’ve worked on, there has been at least one instance when the software testers were asked, “Why did you miss the bug?”

How do you feel when you hear that question? Did you interpret it as “Why did you miss the bug?” or “Why did you miss the bug?” Did you start thinking of an answer to the question based on how you heard it?

It’s helpful to think of the “Mary had a little lamb” heuristic from Jerry Weinberg’s books: Emphasise each word of the sentence and notice what thoughts arise as a result of every emphasis. For instance, consider the question “Are you going home early again today?” If you emphasize “Are you going home early again today?” it could mean the asker also was hoping to go home early. If you emphasize “Are you going home early again today?” it could mean the asker thinks you’re going home early too often. And if you emphasize “Are you going home early again today?” it could mean the asker thinks there’s something important you should stick around for.

In the “Why did you miss the bug?” example, the person asking the question might want to know the reason behind not discovering the bug earlier, but the question could be interpreted as a personal attack. The person answering the question may get into a defensive mode and come up with excuses for why the bug could not be found during testing. The real issue is hidden in how the question was asked.

Consequently, I’ve reduced the “Why” questions and rephrased them to sound like a discussion rather than an interrogation. Instead of “Why did you miss the bug?” I ask, “How do you think we could have found this bug before release?” I immediately get some good solutions we can implement. It also gives me an idea of where the actual problem is.

The next time you want to ask someone on your team a question, pause for a second, think of the “Mary had a little lamb” heuristic, and see if the question can be misinterpreted. This can save a lot of time and effort later in the project.

2. Are you considering different perspectives?

When project teams get bigger, the interactions between people gradually reduce. Silos start to creep in and teams communicate less, which results in people failing to recognize any perspective other than their own. Tunnel vision comes to the fore and people miss out on getting a taste of different perspectives.

In any of the discussions where I am called to act as the facilitator, I ensure that the right participants are in the discussion—and only the involved parties, so we get the necessary perspectives.

As the saying goes, there are three sides to every story: your side, my side, and the truth. This sums up the typical problems in any conversation. The assumptions behind a statement usually don’t come up, and we fail to understand why our choice of words might be giving a totally different picture to the listener.

For example, statements like “I want this done by the end of the day” doesn’t convey why the task needs to be done today. And with such an authoritative tone, you can hardly expect anyone to ask clarifying questions. It slowly affects the morale of the team, to the detriment of the deliverable.

In the same situation, think of the difference if the request was posed as ,  “Considering the time needed for fixing any critical issues that could be discovered, can we aim to finish all our tasks by end of the day?” Yes, there are definitely more words, but the meaning they convey has changed. The tone of the conversation is more respectful, and a channel for discussion has opened for both the parties.

3. Is your criticism constructive?

Have you been in meetings where every proposal was shot down even before the speaker finished explaining the idea? Many people fail to realize the power of their words — especially the negative words. Testers are critical thinkers, and their first thought usually is how an idea won’t work.

Speakers shouldn’t always take these words to heart; it is good to have constructive criticism. But constructive criticism is different from how naysayers behave.

There was an instance where we kept having a customer report an issue that was due to a special character. There were different modules and special characters were allowed in all of the modules, and we were constantly patching the system one bug at a time. We realized that it was the interaction across modules that was causing the issue, so we wanted to brainstorm about how to find such issues.

The ideas started flowing:

• Restrict special characters in the whole system
• Test the main flows and ignore the other flows
• Rewrite the whole code
• Create a mock customer with just the special characters and automate the flows
• Sanitize the data getting in and out of the database

While all the ideas were being discussed, there was one voice that kept shooting down every suggestion:

• Without special characters, we would miss out on security
• Every flow is important, and we have a lot of customers
• Legacy code needs lot of rework
• We don’t have the bandwidth to automate the regular flows, and this would take extra time
• It’s not an ideal solution

After fifteen minutes of discussion, that person left the meeting for a call. The group immediately opened up. We discussed the pros and cons of every approach and finally decided on an implementation to solve the issue. The naysayer is a good person at heart, but he never realized the impact his words had on the morale of the team.

After I got to know about Edward de Bono’s concept of the six thinking hats, I started applying it in discussions to give everyone a fair chance of sharing their views. “Wearing the yellow hat” forces everyone to focus on the positives, so the naysayer’s effect is reduced considerably. Slowly, the habit of appreciating the good in every idea before criticizing it spread within the team. We started having productive discussions, thanks largely to the six thinking hats concept.

We all tend to blurt out words as we come up with them. It is important to realize that each word is powerful and has the potential to either boost or damage any conversation. Remember to ask yourself these three questions in every interaction, and it will help your team engage in better communication—and have more effective software testing.