This question came up in the recently Rapid Software Testing Explored online class. Donatas asks: “Let’s say you discover a problem in the application or the development process itself. However, it doesn’t get the attention it needs, but you believe that it should. How to you convince the others? What are the recommended ways to interact with developers, managers and product owners in these scenarios?”
This is one of the great problems in testing. As a tester you find trouble. But if your clients don’t agree with you about what trouble is you won’t be seen as a valuable member of the team. They will think of you as a sad ghost that haunts the attic.
Getting Attention for a Deserving Problem
First, let me sketch the basic dynamics on getting people to listen to you. It’s mostly not about reason and logic! Persuasion is not primarily a rational process, although rationality is an important tool. Factors that matter include:
- your credibility, likeability, and power in the eyes of the people you want to influence
- your specific relationship to them
- their belief in the general plausibility of your ideas
- their assessment of the evidence and reasons that you put before them
- how much they fear or desire what you are arguing for
- how good or bad they would feel about agreeing with you
- how your case compares to alternative possibilities
My point is that you can’t be successful just by gathering great evidence and letting that speak for itself. I have been in situations where I came to believe that nothing I could say would have the slightest positive impact on the outcome. I don’t stay in those places for very long. That way leads to chronic anger and burnout.
For a non-hopeless situation, here is my advice on persuading your clients that a bug or project issue should be fixed. Let’s assume you’ve already reported a problem in the normal way, yet you have been rebuffed. Perhaps they are ignoring the problem, entirely. Now what?
Reality Check
- Are you sure you are right? Double-check your facts. Perform a deeper investigation. It will hurt your credibility if you push hard and turn out to be wrong.
- Are you sure they are ignoring the problem? Sometimes trouble can be a sensitive matter. Sometimes the process of resolving it takes time and quiet maneuvering. Sometimes a fix can be very time consuming and difficult. Just because a problem isn’t getting fixed doesn’t mean no one cares.
I once came into a project and the first thing I noticed were terrible error messages. They were super vague, like “Error 37: a general failure has occurred.” As the new head of testing for the company, I told them “we have to fix this!” until they explained that to fix it would require a major re-architecting of the system. The developers were sheepish and embarrassed about the messages. They wanted to improve them. But there were more important things to do if we wanted to stay in business.
Things To Do From the Start of Your Employment
- Mission Negotiation: All of your communication with your clients is based on your perceived role. Don’t assume that your mission is clear and accepted by everyone. If you haven’t already had a conversation about your purpose on the team, do that. Get it settled.
- Trust Development/Reputation: All of your communication is also affected by how people perceive you as a person and a professional. Do they think you are competent and serious? This trust can only be developed over time. It may take months to build, over many interactions. Keep your agreements; respect confidences; do not tell lies; get control of your emotions.
- Protocol for Sounding Alarms: As you develop your working relationship with the team, and before you want to ring alarm bells, you should talk with the team (or at least your management) about the fact that you sometimes need to make noise about things that threaten the success of the product or project. You can negotiate how to do that. For small to medium problems I generally start a Slack thread or raising it in a project meeting. For serious and sensitive problems I might start by having private meetings with the key people to break the ice, prior to calling a general meeting with those people to agree on a course of action.
Once I was testing a safety-critical device and found a bug so shocking that I had to escalate it to the division manager. The bug was the sort of thing that would be impossible if the programmers had been following basic professional practices. This is a product that could kill someone, after all. Faced with that, it’s not enough to fix the bug– you have to talk about fixing the process that led to it.
Make the Case in Different Ways
- Make the case with reason. You should, of course, use classic rationality to make the case. But the effectiveness of this tactic is overrated. It turns out humans are amazingly good at ignoring or discounting arguments made using evidence. Check out some of the videos on YouTube by people who believe that the Earth is flat. Yikes! This is why your personal relationships and trust matters so much.
- Make the case with vivid examples. People are greatly swayed by a good story, so I try to come up with plausible scenarios of bad things that might happen if we don’t fix the bug. I google for news stories about such scenarios.
- Make the case with allies. Perhaps you are not the only one in the organization who feels as you do. It may help to line up other influential voices to add to your own. Testers are people who act as agents for the rest of the organization, so build your connections. I particularly like to get to know people in customer service.
And Keep These Principles in Mind
- Fire and (mostly) forget. Once you make your case and your case is heard, walk away from it. Let them think about it. They might be less willing to take action if you don’t give them space. I learned this by being the father of a very stubborn son (just like his dad).
- Periodically check in about longstanding problems. Keep a list of current top concerns and go over it once in a while with the team or management.
- Power is best used backwards. Here’s another life lesson from being a dad, a husband, and a manager: If you have enough power, you can just force people to go along with you. But when you use power often, the people below you will take action to avoid or blunt your will. So, if you want to keep your power, you should use as little of it as possible. A good way to do that is use power to make other people feel more powerful. This can be scary, I know. It’s seems completely backwards, but it works well in many cases. When you affirm someone else’s privilege to control the situation and be secure in their agency, magic can happen. Extreme loyalty can develop. (This is my wife’s favorite method of influencing me and it works well even though I know she’s doing it.)
Years ago I caught a project manager in a pretty embarrassing lie, and he knew that I had caught him. I decided to forgive him instead of having a showdown in the next project meeting. I let it go. To my surprise, my working relationship with him immediately improved. Paradoxically, trust began to blossom. And my concerns began to be heard.
Like I said, persuasion is mostly not about logic and evidence.
An excellent post, James, and full of life lessons that apply well beyond testing.
One example: Making the case with vivid examples. In a previous role, I was also a fire warden as well as having my formal testing responsibilities. Our trainer for the fire wardens was a former firefighter. he showed us the official, uncut video of the Bradford City stadium fire. This was a disaster at a football stadium in 1985 where a fire started in discarded litter from a cigarette end. The stand was old and of timber construction. It burnt out completely in less than four minutes and there was considerable loss of life.
Watching raw, time-coded footage from a fixed security camera had an immediacy that no news footage could convey. I can honestly say it was life-changing in terms of my attitude to public safety and, by extension, thinking about the elements of my work which could impact life and limb. It was at the back of my mind throughout one contract I had which involved testing embedded software on medical devices and which had to jump through a number of “traditional” testing hoops to deliver confidence in the devices’ outputs – because these, too, could impact life and limb.
[James’ Reply: My brother was a volunteer firefighter in college. He still has a sort of ultra-responsible ethic, grounded in that training and experience.]
Interesting piece. I openly admit I am still relatively green in the industry and my technical skills aren’t the sharpest but I always manage to form good relationships with those that matter (clients, developers, leaders) so when I come to them with a concern or issue they know it is serious, even though I don’t have the qualifications.
Communication is such a huge part of the testing industry, yet so many forgo it for reports and metrics. Tell someone what is wrong and who it will have an effect on, you’ll probably get more of a realistic, human response than leading with the technical jargon.
Great description of what you can do to get more attention. Personally I would have dealt with the problem from a different perspective. We categorize the defects based on severity. Typically, higher severity defects get more attention. To deal proactively with this, I suggest a well-constructed defect severity scale. If the question of persuasiveness implies that other team members do not consider my bug to high severity, then I will discuss the scale and the criteria for deciding how severe is a bug.
[James’ Reply: I liked your comment so I rewrote it in more idiomatic business English. If I misunderstood it, please advise.
Yes, my post is about being persuasive in general. What I haven’t covered is the specifics of how to make a case, in general, to get a bug fixed. To do that, severity is one thing to talk about. Another thing is cost– you could argue that the fix would be easy.]
Thank you James. I like your editing on my post. It is much better now. Thank you. Your article has very good points. What you describe is very valid. .Yes indeed cost also it could be a factor. I just emphasize that we can do also some proactive work. If team disagrees on severity level then obviously the severity scale is not well defined. By fixing it, we may address the root cause of the problem and eliminate future disagreements.. Thank you again.
I would also add that sometimes a necessary step is to know what your bottom lines are, and be clear about what that means to you. Sometimes as James states, it is going to be necessary to leave an engagement if you are going to retain your sanity and your professional standards. There are a couple of occasions during my professional career when I have had to be very aware of those bottom lines, and walk away. I have so far managed to do this consciously and by choice. Understanding my bottom lines helps me to remain calm and level headed during the process.
Great article that comes at the right time.
Big thanks for your work!
This is always so refreshing to read your blog posts. I have done it since 2010 and reading that one reminded me how valuable was that meeting with you in one of your public classes. Thanks and keep up those blogs!
Thank you for such a thought-provoking and insightful post! As a software tester, I often encounter situations where persuading stakeholders about the importance of a bug or process issue feels like an uphill battle. Your breakdown of persuasion dynamics, especially the emphasis on trust, credibility, and relationship-building, really resonated with me.
The anecdote about the error messages and the deeper context behind why they couldn’t be fixed immediately was a great reminder for me to step back and consider the bigger picture before jumping to conclusions. It’s so easy to focus solely on the technical aspects and forget the real-world constraints teams face.
Your suggestion to “make the case with vivid examples” and build connections with allies in the organization has given me a new perspective on how to approach resistance. I’ve realized how underutilized customer service feedback can be in bolstering a case for fixing critical issues.
This post not only brushed up my skills but also reminded me to approach testing with empathy and strategic communication. I’ll definitely be more mindful of developing trust and negotiating my role within the team.
Thanks again for sharing your wisdom—it’s posts like these that inspire continuous learning and improvement in our field!