Anyone who has been in the software industry for a while has probably come across jokes, memes, or comments about the strained relationships between testers and developers. Testers get frustrated and complain about developers saying things like, “It works on my machine.” Meanwhile, developers dismissively joke that testers are people who couldn’t make it as developers because they’re too rigid and prone to thinking up new problems and unlikely edge cases.
Some people may read that and feel upset by these generalizations, thinking that this is not how things are anymore and that developers would no longer treat a colleague — tester or otherwise — like that.
I started as a developer, then moved into testing, and I agree that a lot of progress has been made. However, I still see the same jokes and new memes in the same spirit. I still hear many testers telling the same stories of feeling misunderstood, ignored, or left out. And I still hear about engineering organizations that struggle to assign the same value to a tester as to a developer.
So why is that?
The idea of “builders and breakers”
The notion that developers are builders and testers are breakers is mostly flawed but still holds a grain of truth. Software development is an act of creation focused on finding a solution to a problem. The art of software testing, on the other hand, focuses more on finding scenarios where our proposed solution does not solve the problem. Testers and developers have a lot of contradicting goals and values.
Developers often have goals focused on speed and delivery as well as working, compilable code. Testers' goals are often more aimed at stability and minimizing risk. It’s written into their work tasks, descriptions, and, not to forget, often what they are measured on.
Managers don’t set goals for or reward how much code a tester ships or how many bugs a developer finds before releasing to production. Who is to say if these goals would make any sense? The point is — leaders and organizations get what they measure and reward, so it’s important to be aware of how that might affect relationships between different teams, roles, and departments.
Testers and developers want the same thing for different reasons
Testers and developers focus on different aspects of the work, but they also share many goals and values. In the end, everyone wants to have a working product that users like. Everyone wants to sleep well at night without worrying about a lawsuit. They all want something to be proud of. But what gives one person that sense of pride might be very different for someone else.
For a developer, it might be seeing their code running and knowing how many tricky problems they had to solve along the way. For a tester, it might be knowing their work helped identify and solve a massive security issue. The problem is that people are not very good at talking about goals and motivators, even for themselves. And if they are not aware of them, how can they articulate them to someone else? And if they don’t express them, how will others know and understand them?
Lack of understanding complicates feelings of ownership
The concept of taking (and feeling) ownership over things is a common struggle. While phrases like “quality is everyone’s responsibility” and “the team owns their own solution” get thrown around, everyone might not interpret them the same way.
People will naturally feel a stronger sense of ownership of some things and less of others. This might be due to their skillset, their values, or what they feel they are “allowed” to take ownership of. When people feel ownership over something, they’ll gravitate towards it, which makes them feel a stronger sense of ownership while also pushing others to feel less ownership.
This is especially true when people don’t feel as strongly about certain tasks or areas. In a diverse and mature team, this might not be much of a problem. The natural differences in interest will spread across the responsibilities, and as long as the process doesn’t depend too heavily on certain people (and those people don’t leave the company), things get handled.
But if these feelings of ownership are not clearly expressed, it creates a breeding ground for a lot of assumptions. It can also stunt growth by preventing people from learning something new.
Talking about goals, ownership, and expectations creates a better foundation for good relationships. It creates a safe space where everyone can be open about their limitations and find ways to tackle problems efficiently as a team. But everything needs to be owned by someone. And everyone needs to feel and take ownership of something.
There’s a right (and wrong) time for everything
Developers do a few different types of work — sometimes, they build new things, and sometimes they focus more on refactoring or improving their (or others’) code.
There are, of course, nuances to this — a developer building a new standard feature that they have built a thousand times is different from building something completely unknown. Refactoring known code to a new design pattern is different than chasing a nasty bug. But in general, there are two different types of work.
Building is the time for ideas and creative thinking
Building something new and unknown involves very creative and positive energy. It requires an innovative mindset and somewhat abstract thinking focused on coming up with new ways of solving a problem. When a tester disrupts that energy by being overly negative and pointing out every potential problem, it can easily bring developers out of their flow and feel very confrontational.
If testers avoid focusing on details and instead use a “yes, and” type of communication, they can help keep that excitement and energy going in this stage of development. They can become partners instead of opponents — working with the developer on a solution instead of shooting ideas down. This is the time for testers to add new ideas, build upon the developers’ work, and think big. “Yes! And have you thought about the possibility of adding…?”
Refactoring is the time for problem-solving
On the other hand, when fixing bugs or refactoring, having a tester help spot those small things and acting like a safety net can feel very calming and helpful. In this situation, it doesn’t help to ideate ten different ways of improving things outside of the narrow scope at hand. This work requires attention to detail and the space to go slowly. If there is ever a time for “yes, but” type of communication — this is it. “Yes, but have you thought about what would happen if…?”
Testers are used to asking questions and are typically very good at it. However, they are not always great at not asking every question every time. Focusing on the wrong level at the wrong time is not helpful — it’s distracting or even annoying. When ideating, testers should focus on high-level questions. When problem-solving, they should focus on low-level questions. If a tester is met with resistance, they should ask themself if they are asking the right questions for the type of situation they are in or if those questions should be put on hold for now.
The right time for a tester might be the worst time for a developer
Testers and developers have very different needs and ways of working. While some testing activities can be very focused work, very similar to coding, testing requires keeping track of several perspectives, levels, and scenarios at the same time. Testers are the people who connect dots by combining information from different sources — linking what they heard at the coffee machine or something they noticed in a previous session.
A lot of testing work is less sensitive to context switching than typical coding work. However, testers often require information and details to be able to complete their work. Sometimes, the only holder of that information is the developer and the tester will need them to be able to complete their work.
What’s important for testers to understand is that while getting that information from the developer is crucial for their work, they are asking the developer to context switch. The tester may think the developer only has to spend five minutes responding to the question, while in reality, that interruption lost the developer half a day’s work because they lost their focus.
Instead of getting annoyed at not getting the attention they need, testers should consider discussing how to work together with developers to reduce interruptions and find a good middle ground.
Collaboration is key. It’s also very difficult.
One reason why collaboration and communication are challenging is that people have different levels of expertise. Testers and developers are constantly in situations where one has a high level of expertise and needs to collaborate with someone with low expertise in the subject matter at hand.
Very experienced testers need to talk about risk assessment with developers who don't know more than the bare basics, and developers need to collaborate with testers on details of code or pipelines or database performance, which the general tester would not be an expert in.
This can cause issues, one of them being connected to having different vocabulary. When a tester says “risk-based testing,” they will have a very different understanding of that than most developers. Unfortunately, people tend to think terms mean the same things to everyone, which is why it’s important to ask clarifying questions and spell out assumptions to avoid unnecessary misconceptions.
But it goes deeper than just vocabulary. People with low expertise in a topic are not able to do certain aspects of the work, for example, prioritizing properly. When a person is new to something, everything feels important because everything is unknown. This means abstractions like diagrams or other models, which are usually great for improving common understanding, can be unhelpful to someone who lacks the basic knowledge to unpack and understand the abstraction.
Furthermore, people with a high level of expertise are often unaware of how much they rely on their knowledge to make decisions. They might skip over explanations that they feel are obvious, forgetting that they are not obvious to a novice. When something is fundamental to the work a person does, they start to think that it is basic knowledge that everyone has.
And, of course, people also tend to think of others as either novices or experts when in reality, levels of expertise are topic-dependent. Almost everyone is an expert in some areas and a rookie in others. In a common work setting, the roles of expert and novice change constantly. However, this is usually not how people see themselves.
Having to acknowledge that someone else — perhaps someone junior to them — has the upper hand in a certain area can be a hard pill to swallow. Developers and testers alike should shift their mindset and instead embrace an opportunity to learn. All experts are novices in something. It can be difficult for some people to feel like a rookie when they’re used to being the Oracle, but great collaboration requires everyone to feel comfortable not being the smartest person in the room.
Everyone needs to understand what they contribute to the big picture
Once upon a time, movies only existed in black and white. Eventually, filmmakers figured out how to combine different colored strips of film into one picture. With each color, filmmaking achieved more depth, more perspectives, and the ability to express things like never before.
Personally, I think the same goes for software development. Without multiple perspectives, we end up with an inferior result. We won’t build the amazing products we want to build and proudly add to our resumes. Each of these perspectives has its own goal, and they also have clear boundaries. Without the perspectives, the picture is incomplete and lacking depth. Without the boundaries everything would blend into a big mess.
As testers and developers, we need to understand our part in the picture, how we influence it, and how we can contribute to it. But we also need to understand how others fit into it, how they differ from us, and how they affect us so that we can work together to create that fantastic software we could not produce on our own. And maybe, just maybe, we can adjust our ways of working and our view of the world to make the end result even better by blending our values and goals into the bigger picture.
