Developer-Tester Relationships

In a development team, there are times when the relationships between developers and testers can become strained. How can you turn this potential conflict into something more positive? Is it part of the skill of team-working to find ways of avoiding friction, or should one blame a system that relies on good social skills to work well?

How to resolve 6 common conflict situations with colleagues

Programmers program. Testers test. In an ideal world, everyone would do what they were good at (or at least what they were employed for) and the result would be a stable reliable fit-for-purpose product that helped the customer stay happy, the shareholders become rich and you survive to work another day.

The world of software development, though, is far from ideal. Tight deadlines, unclear requirements, limited budgets, and human errors make the office a volatile place with constant fire-fighting. Tempers run high. Patience runs low. Programmers and testers are at each others’ throats. And may always be.

Here’s how to keep your cool and deal with some common stressful situations at work, when the tester says:

1. “It’s a bug, not a feature. It’s not supposed to work that way!”

Programmers, ignore the implied “stupid”. Get the business analyst or project manager to spell out exactly what the “feature” is meant to do, by updating the documentation.

If there isn’t any documentation to clarify the situation, it probably means the Business Analyst (BA) has not thought about the possibility of something working in a different way than expected. Ask the tester directly if it really is such a big issue. Does an exception need to be made? Does it need to be raised now? How often will it be encountered? Is it stopping any critical function from being completed? Testers may not always be in the best position to discern what is urgent and what isn’t. However, for most busy project managers, it helps to know at least roughly how critical a bug is so that they know which order to deal with a list of them in. It saves time. The programmer and tester can try to put their heads together to find if there is a work-around available to continue the business functionality and if the bug can wait.

2. “It doesn’t work on my machine.”

It works on yours, and you can’t replicate the problem, so how are you meant to fix it? Use the tester’s machine. Or ask the tester to demonstrate the exact bug reproduction steps on yours. Testers may not always be articulate, clear and accurate about bug reporting. Employ screen shots freely. Seek clarification quickly if the bug is reported in ambiguous language. “Tick the XYZ checkbox” means tick the XYZ checkbox. On the other hand, “Check the XYZ checkbox” can mean take a look at the checkbox to see if it is ticked or unticked.

Your customers are not all going to have the same system configurations, so the defect may crop up eventually. Yes we would all like to avoid confrontation. But we would also like to avoid embarrassment if there is a risk something may go wrong in live production.

3. “It was working yesterday, John’s broken it.”

It is possible something has regressed. Especially if more than one programmer works on a system or if the code is branched. Perhaps multiple updates happened on shared files. Perhaps a reference library has been modified. Get the configuration/release manager to check what has changed since the previous day or version and fix it. Don’t blame or accuse your fellow programmers for something that is inevitable. Software is unstable. The sooner everyone accepts this, the quicker they move on.

If manual regression testing is taking up too much time and resource, find out if it can be automated. If patch fixes keep breaking the system repeatedly, the deeper root cause needs to be found.

4. “This is not a requirement, just a nice-to-have suggestion.”

A tester’s role is not just to find and log bugs. It is also to see what happens when the unexpected happens. To act as a reference for the project’s overall progress. To ask questions no one else has thought of. To provide a different perspective. To anticipate future problems. To highlight gaps in requirements, understanding and implementation. To suggest improvements that will make the user’s life easier.

From your point of view, time may be short. Or testing may be wandering all over the place and not have a clear focus or direction. Ask the tester to log the item and mark the status “On Hold” with a remark about why the item takes lower priority. Make sure you don’t neglect the item out of miscommunication or personal prejudice. Nice-to-haves can turn into change requests and money-earners later.

5. “This is within scope and needs to be fixed now.” or “This is an implicit requirement.”

A programmer’s job is compartmentalised. He is given a requirement, asked to code the solution and barely has thought to spare for the surrounding system. A tester’s role is the antithesis. She looks at the bigger picture and observes, detects, analyses, cross-checks and reports several things happening simultaneously. She doesn’t go looking for unrelated bugs or unsatisfied requirements, but when she finds one, she cannot ignore it. As a user representative, she doesn’t care if it is something that is currently being developed or has existed from an earlier release. So the “scope” of testing is never the same as the “scope” of programming. To resolve this issue, get the management to step in and make a decision. It gets the pressure off both of you, and puts the responsibility firmly on the shoulders of those who can handle the repercussions.

6. “Why have you rejected this bug?”

The tester is the company tester. She is not the business customer. Nor is she the end user. But she is acting on behalf of both those people. A competent tester can imagine a lot of scenarios that an ordinary user can’t. A rejected bug hurts her, but not as much as one rejected for the wrong reasons or for no reason at all. Give your rationality behind the rejection with a short note, so that the tester knows better next time, then leave it alone. Further arguments or involved discussions will not serve any use. Only time will tell who was right.

Mike Myatt is a leadership advisor to Fortune 500 CEOs and their Boards of Directors. Widely regarded as America’s Top CEO Coach, he is recognized by Thinkers50 as a global authority on leadership. He is the bestselling author of Hacking Leadership and Leadership Matters, a Forbes leadership columnist, and is the Founder and Chairman at N2Growth. “Conflict in the workplace is unavoidable,” says Myatt. “The ability to recognize conflict, understand its nature, and bring swift and fair resolution serves everyone well.” He believes conflict rarely resolves itself. “Conflict normally escalates if not dealt with proactively and properly.”

Withdrawal, Confrontation, Consensus and Avoidance are some conflict management styles and one size doesn’t fit all. A high Emotional Quotient, Clear Thinking, Reflective Listening and Keen Observation are important skills to possess.

Jonathan Kohl is an internationally recognized consultant and technical leader. He is the founder and principal software consultant of Kohl Concepts, Inc. Jonathan helps companies define and implement their ideas into products, coaches practitioners as they develop software on teams, and works with leaders helping them define and implement their strategic vision. He is also a popular author and speaker. When asked how he avoids conflict, he says, “I don’t. It is a natural part of human interaction. If you try to avoid it, you just drive the energy and emotion underground and it gets expressed in unhealthy ways.”

Testers need to be tactful and diplomatic when raising defects. Their job is essentially to find faults in other people’s work, and they need to realise that for the programmers this can be unpleasant and difficult to accept.

On the other hand, programmers need to be aware that bugs are not personal. While more bugs found can mean more rework, longer hours and late sitting in the office, project delays, estimations getting messed up, more pressure and being labelled incompetent, programmers can also do a lot to minimise conflicts in the office:

  • Empathise – others may have a valid point you haven’t thought of.

    Kohl says, “People I’ve worked with tend to feel more comfortable if they feel they are being heard and their ideas are considered seriously, even if they don’t always get their way.”

    “Understanding the other person’s position and motivations is critical. Help those around you achieve their objectives,” says Myatt.

  • Attack the issue, not the person – never introduce a personal motif into any argument. “You always do this!” “It’s just like you to say that!” “He is so <unflattering adjective>!” Always keep things on a professional and courteous level.

    Myatt advises, “Don’t play favourites, don’t get involved in drama, and certainly don’t tolerate manipulative, self-serving behaviour.”

    Kohl adds, “I don’t tolerate personal attacks, and I don’t tolerate gossip.”

  • Anticipate and come prepared – like any good battlefield strategist, pre-empt your opponents by being forearmed with knowledge.

    Myatt says, “Most conflict results from information-poor information, no information, or misinformation. Clear, concise, accurate, and timely communication of information will help to ease both the number and severity of conflicts.”

    So how does he handle conflict when it happens? Kohl believes conflict helps encourage a diversity of opinions and ideas. “I facilitate healthy conflict by having some ground rules: any idea is worth bringing forward. I don’t judge anything no matter how silly it might sound. I encourage people to be self-critical, to speak from the heart and to go with their gut instinct. From there, I encourage people to investigate those feelings and see if they can gather some data to see if their idea is defensible or not.”

  • Take it slowly – introduce ideas gradually so that people get time to let them sink in.

    Myatt believes having clearly defined job descriptions so people know what’s expected of them and a well articulated chain of command to allow for effective communication will help avoid conflicts. “Creating a framework for decisioning, using a published delegation of authority statement, encouraging sound business practices in collaboration, team building, leadership development, and talent management will all help.” This creates awareness and sets guidelines are more easily acceptable to others.

  • Get assistance – seek out the key players and bring them over to your side. They will, in turn, be able to influence others.

    What does he do to facilitate conflict resolution? Kohl encourages team members to resolve problems by getting together to talk about them. “If people won’t get past arguing over ideas, I ask them to prove out their ideas. Reality, measurable data and criteria tend to prove which idea is better, and we all learn and move forward much more effectively.”

    Myatt advises seeking out areas of potential conflict and proactively intervening in a fair and decisive fashion is likely to prevent certain conflicts from ever arising. “Minimize the severity of the conflict by dealing with it quickly.”

Co-operation, collaboration, team spirit, and frequent communication are crucial. The relationship between programmers and testers keeps rebounding as forcefully as a stone and a catapult. Neither can achieve anything significant without the other. You could throw the stone by hand, and you could use a grape on a catapult, but it wouldn’t make the same impact. Conflict can be a time for discussion, reflection and action. If viewed positively, it can be a great building block of vibrant team dynamics that can reap huge benefits.

We are all developers in that we all help develop a piece of software that provides a solution to a business problem, that satisfies a business need or requirement, that creates an actual product out of virtual ideas. Where possible, we need to change the system that sparked the conflict in the first place. Remove the trigger and the fuse won’t blow. Where this is not possible, we still need to work together, so we might as well get along well and make the best of it. Celebrate our differences. Highlight our individuality. Adopt the necessary social skills. Learn from conflict and use it to grow. After all, how dull and boring the world would be if everyone always agreed with everyone else!

Tags: , , , ,


  • Rate
    [Total: 32    Average: 4/5]
  • Topcat

    As a project manager I would say ‘toughen up princess’ to any developers who are bothered by the test results mentioned here.

  • Mighty Tester

    Project managers say the darnedest things
    Topcat, I wonder if that’s any better than what a PM once said to me, "Don’t log so many bugs! The customer won’t find them, so why are you?" He wanted to get the release out the door so that the next payment would come in.

  • Anonymous

    Part of the problem can also be how testing is organized within a group. Ideally testing flows directly from requirements. If you have requirements, then you have a test plan. And if so, then the developer knows all about the test plan. In fact the developer should have executed the test plan before passing the code along. And if you think that makes testers obsolete, then good. They should be. Think about organizing your team so that there are no designated testers.

  • Mighty Tester

    Obsolete testers
    Testers will never be obsolete, not just because software isn’t perfect, but also because good testing provides more value than just finding bugs. And programmers seem to have blind spots when it comes to their own code. Perhaps it would be more practical to organize teams that have designated testers, but those testers don’t limit themselves to pre-written test plans. There’s only so much you can imagine and extrapolate from requirements. There are always going to be gaps and ambiguity.

  • Mighty Tester

    Obsolete testers
    Oh, and if there aren’t any designated testers, who will write those test plans in the first place? ūüôā

  • Bit of Both

    Content of this article
    As someone who has been both a developer and a tester, I love this article.

    When I have the testing hat on and I’m working with a developer, a lot of time what we do to meet our release deadline is we divide and conquer. He works on the next code release, and I work on testing the last one. When we are in this crunch time, if he has to take the time to test and replicate, it means that’s one less issue that gets squashed before we send the release out the door.

    Do I like it better when he has time to do his own testing, and all I have to do is perform a single acceptance test, and sign off on the code? I absolutely do. Wish the world were perfect like that all the time – it just isn’t.

  • Mighty Tester

    Team work
    Bit of Both, Thanks! And amen to working together to unite against a common enemy: bugs!

  • Anonymous

    Developers can test too
    I worked for a major software developer many years ago which sent a product to several customers for beta testing. The customer found a dozen issues, the testing team found two dozen, and the developers found almost 200. Being a developer did not preclude aggressive testing.

  • Mighty Tester

    Developers as testers
    Developers can make some of the best testers, if they want to. The trouble with giving a simplistic quantitative summary like this is that a lot of other variables remain unknown. What kind of bugs were logged? How much time did each group have? Were all bugs logged in a uniform manner? Did someone weed out the duplicates? Were all bugs of same criticality? Were all bugs accepted for fixing? Without understanding the context it becomes difficult to compare directly the performance of one group with another’s. Having said that and accepting that developers did find more bugs, in my experience, this kind of an outcome is rare enough to be memorable.

  • Anonymous

    Developers do not make the best testers
    Developers test their own code in the way it is meant to work with some lip-service to negative testing. The BEST tester is that person who breaks things simply by touching it. They use the application in weird ways that an end-user might. When this type of person reproduces a bug to a developer, the developer will be heard to say, "Why in the world would you do it like that?!"

  • Sandwichmaker

    What does the Customer want?
    Moving a step above testing, it’s also a culture problem. In some cultures, the developer’s bugs are counted and pulled out at review time. At that point the developer needs to fight for ‘what is a valid bug.’ The developer then blames the tester for his raise. That isn’t fair on either side. A number centric manager who doesn’t understand the process or craft implements this type of culture.
    I have worked with some great testers in my career. I try to get to know my testers so I feel comfortable asking them questions (what are you expecting here) and in return they feel more comfortable asking me questions (why did you do it like this). Two way communication is very beneficial.
    The one thing to remember, no matter what your role (QA, Dev, PM), we are all being paid to make the best product possible for the customer. One of the questions developer and testers need to ask is “What benefit is the customer getting from what I’m doing today?”

  • Mike Spurlock

    The Future
    The day may come when machines write code for applications requested by other machines.

    The day will never come when code can be tested by machines by machines by machines by machines by machines by machines by machines by machines by machines

  • Dogramone

    Where’s the PM
    I’ve had these scenarios a few times in my career as a PM and I see most of them showing that the PM hasn’t carried out one of the key roles, setting up the team. This isn’t just getting people into roles to get the work done, that isn’t a team in my dictionary. Everyone needs to be working together, fully understand each others roles and comparabilities and respect one another. I had one tester appologiesing for finding defects within weeks of go live. I’d prefer to delay by a day or two than deal with the stakeholders when the s%#$ hits the fan in production. Get the team moral, camaraderie and respect right and you end up with a great end product that we all then feel proud of.