This post has been brewing for a while, but a LinkedIn conversation today reminded me to put it in the bottle and ship it.
Testing is socially challenging. There’s a double meaning there.
One meaning is that testing involves challenging the product and our beliefs about it, in a social context.
The other meaning is that probing the product and people’s beliefs about it can sometimes be uncomfortable for everyone concerned. That makes testing socially difficult, or socially awkward.
Testers sometimes resist the first thing because of the second thing. That is: there’s a risk of social disharmony when we ask pointed questions, or “too many” questions, or when we look for deep bugs, or when we find serious but subtle bugs.
In some cases, testers might feel vulnerable to being rejected or dismissed by others on the team. In other cases, there’s a risk that someone will be upset by a question, or by a bug report. In those cases, care for the feelings and vulnerabilities of others might restrain us from voicing problems or concerns. Either way, someone — the tester or the one or more of the tester’s clients — may feel unsafe. How do we address that problem?
As testers, it’s important for us to feel safe in certain ways. For instance, we should not have to deal with abuse, harrassment, prejudice, racism, sexism, and the like; nor should our organizations tolerate any of that. It is appropriate and necessary for us to anticipate, desire, and require that kind of safety.
Even when those issues are managed appropriately, our job as testers is to identify real and potential problems. People don’t like having to deal with problems; they don’t even particularly like being aware of problems. For testers, the risk of controversy and social upset is always present as part of the job. That risk can make any of us feel unsafe to some degree from time to time.
To deal with that risk, it might be more important for us to feel strong. That feeling of strength can come, at least in part, from developing technical, social, and personal skills.
By “technical skills”, I mean not only knowledge of technology and how to apply it. I’m also refering to techniques of modeling, analysis, critical thinking, and so forth. That includes the ability to gather and organize evidence about what we’ve seen, and to describe facts about products, problems, and risks.
By “social skills”, I mean the ability to work with people collaboratively, as individuals and within groups; to frame our questions and our reports in ways that respect other people and the difficulty of their work; and to deal with interpersonal problems when they come up.
By “personal skills”, I mean the ability to organize and prepare ourselves to get our work done — including the development of technical and social skills.
One crucial personal skill is to accept that other people may feel bad about the questions we’re raising, the problems we’re reporting, or the risks that we’re identifying — and that we don’t have complete control over that. The feedback that we provide is a kind of gift, and sometimes people don’t like what they perceive when they first open the package — and maybe for a while after that.
A key element in all this is to focus ourselves and our work on helping our testing clients to be both safe and strong. We’re trying to help people to build and defend the value of the product. Alas, that often means invalidating some assumptions and puncturing some of their illusions about the product, It sometimes means delivering bad news. It means raising questions like these. All of these things can be painful at times.
We can apply our technical and social skills to the very best of our ability — to discover the facts about the product; to report them diligently and dispassionately; to honour the knowledge, skills, and feelings of other people. Yet when confronted with a question or a problem, people may still be upset: surprised, confused, impatient, frustrated, or angry.
When they’re feeling like that, their reactions may be misdirected towards us. In such cases, it can be really important for us to avoid taking those misdirected reactions personally. That’s both socially and personally challenging, but it’s an essential self-defense skill for a tester.
As testers, I want us to be strong, so that we can help our clients and their products to be strong too. We can do that.
Several years ago, Aaron Hodder pointed me to this video clip, which I consider profound and insightful. It’s about students and safety on college campuses, but I believe it has relevance for people and and safety in development groups too.
These words are very real-life facts and revealing so deep psychological wounds in the air.
Being a bad news bearer is a complex problem to deal with as Software Tester.
I was there recently, and the frustration was everywhere in the workplace, projects weren’t delivered because of repeatedly obvious seen bugs, and stakeholders were worried about trusting our work, so testers went so deep revealing more bugs, and every day they do this they were faced by rejection and devaluation of their work by saying for example maybe they are not knowing clearly the business processes or maybe they need more training. Obliged to more training testers continue to reveal more and more, projects still not delivered.
What is the solution to a situation like this for the team to succeed?
This sounds like a sadly common pattern.
Testers don’t have the political and managerial authority to address project problems; to change what developers and managers and executives do. That is, we don’t manage the project, and we don’t manage the business.
Testers do have at least some degree of control over their own work, including the learning needed to support their work. Consider disposable time for that (https://developsense.com/blog/2010/01/disposable-time).
Testing, and testers, can reveal product problems which represent business risk. Testers are often aware of project problems that drive product problems, and that make testing harder, slower, mis-targeted, or less valuable.
We can shine light on all of those things (https://www.developsense.com/blog/2018/02/how-is-the-testing-going/). For instance, if you’re not getting the information or training or trust you need to be effective, make that part of your report.
That is: do everything you can on your own, and ask for help. Help management connect the dots: if you’re not both self-directed and well-supported, there’s a greater change your testing will miss problems that matter. Those problems represent risk to the business. Remember, too, that as a tester, you didn’t put the problems into the product. They were there before you started testing.
All of these things amount to management problems. If management doesn’t act to address those problems, the pain and frustration will demotivate people, and the dysfunction will sink the business. As a tester, you can help people be aware of those problems, but you can’t fix things that aren’t under your control.
If you’re in a situation like that, and you’re not in a position to effect change, it might be a good idea to keep your résumé up to date.
Its been a while since I worked in such an environment myself, but when I have been there in the past, I have applied a basic triage process:
Pick an area to focus on where you have a stakeholder to work with that swings a big enough stick to effect some needed change
Feed that stakeholder. Work with them to get some sort of win.
Then talk about the win – this will hopefully help improve morale, and give you some impetus to work with for further change.
This process is not guaranteed to work, its incremental and slow – but I have seen it work.
Thank you for writing this post, Michael.
I work as a freelance tester and have 1-2 new projects every year at different customers, sometimes also new customers.
What you describe is something I have experienced several times. The team or stakeholder wants to “kill” the messenger aka the tester that reveals a problem.
I have even been asked to fix the problem since it was me that found it!
I still find it difficult to communicate with other team’s members and stakeholders about my findings. However, over time I have found ways to deliver bad news in a constructive way and try to avoid contributing to the blaim-game-attitude that often appears.
So, in my opinion as a tester I need to learn to communicate facts so that people listen to the content of my message and sees the tester as an allied.
This is a skill that requires coaching, practise and time. Sometimes feedback is a valuable source for developing one’s communication skills.