Quality Engineering

Inflicting Help

Pain is our bodies way of telling us to stop doing something. Stop putting your hand on a hot stove, stop hammering your thumb, stop walking into lampposts…

Like it or not, our profession, software testing, unwittingly creates pain in others. Shattering illusions does that. Have you seen that look of mild alarm as you approach a software developer? You know the one, that pleads, “please don’t let it be me…”. The pain isn’t only one sided of course. Software testers can feel pain as well when software development runs over and their insufficient time to test.

A human response to pain, is to remove or reduce it. Sometimes we do this through changing or own behaviour. Often we try and change the environment around us. For example, if we burn our thumb on a hot stove, we move the thumb away (our behaviour), but we also turn off the stove.

In software testing, we do the same. We modify our own behaviours, but we realise that in order for things to work effectively we need to modify other’s behaviours too. Tricky work, when you don’t necessarily have huge amounts of influence on the time.

In software testing, we try and remove the pain of ‘not enough testing time’ through the concept of shift left. We try and persuade the team to start testing earlier. To fix our pain, we attempt to inflict help on the team. Sometimes we call this help ‘quality improvement’.

Look at shift testing left. We like the concept because it means it solves our pain, our headaches. With software testing starting earlier, we have more time to finish our work and we potentially reduce the number of bugs created. No brainer right?

The trouble is, while our pain may reduce, we’ve inadvertently created pain for others. Developers workload has increased. Logically, Shift Left makes sense, and it’s a useful heuristic to adopt. But we don’t work on logic, we’re driven by our emotions. So while logically this means they won’t have to fix bugs later down the track, it doesn’t really feel that way at the time when they consider the additional testing they need to do.

Have you ever been with a team that feels they’re doing a good enough job and they don’t see a reason to change? Do you sometimes feel like you're a nurse telling a patient to drink the cod liver oil because ‘its good for you’? Logically the team knows you’re right, but at an emotional level their not feeling the pain you feel and so have little incentive to change.

I’ve seen two different ways of handling this situation.

First is to have a conversation around responsibility of quality. A consensus of quality being everyone’s responsibility can then lead to discussion of how as a team, the pain should be fixed. I call this strategy path of most resistence.

Sometimes, rather than looking at what you feel is the solution understand their pain. Instead of fixing your pain, look to fix their pain. What’s bothering them? What can you do to help out their priorities, as opposed to your immediate concerns? Shifting the focus on the team, allows you to view their concerns. Why is this important? Because once people see you're interested in their pain, they’re more willing to work on yours.

The second strategy is much smarter and was taught to me by Anne Colder. It’s called Verwondering. Verwondering is a dutch term that translates badly into ‘being curious’. Instead of trying to fix the pain, get curious about how it's come about in the first place. Ask questions on why the release is late? Do they not have enough time? Why are things so, and has anyone tried to fix the situation? What happened when they did so? What fears are driving these behaviours? Verwondering encourages you as a quality advocate to put aside your ego and your desire for change and genuinely listen to where people are coming from.

The Verwondering strategy is particularly useful in the role of quality coach/advocate. Here, you may be in a position where you need to influence without direct authority. Let go the desire to ‘inflict help’. Get curious about your team. Ask for their input. None of this guarantees success but it may help to build a collaborative and supportive environment. And who know, down the track what that may lead to?

I think that’s enough inflicting help for one night

Like this post? Why not have a read of the following: