Five Tips How Software Testers Can Collaborate With Software Developers

Whenever I join a new team, my first task is fostering and nurturing a good working relationship with the developers. Why? If there is good chemistry between testers and developers, the quality of work increases as the quality of communication increases.

The relationship between tester and developer shouldn’t be one of artist and art critic. Rather, it should be one between writer and copy-editor, each contributing to the quality of the product.

Developing a good working relationship with developers can be tricky. Here are five tips for nurturing and developing relationships with your developer teammates.

Tip #1: Don’t Let Bad Past Experiences Get In The Way Of The Present

It can be tough being a software tester. Testers can be blamed for:

… finding too many bugs
… for reporting too many bugs
… for making the team look bad
… for making the product look bad

Speaking for myself, I’ve seen managers foster an “us vs them” mentality between devs and testers, claiming that this heated rivalry is a good thing, keeping both camps on their toes.

I’ve had test managers insist that testers should only communicate with the developers through bug reports, and that I only have two jobs: Find bugs, and don’t bother the developers.

And I’ve had development managers dismiss me as “only a tester”.

Even though most of these experiences happened early on in my career, when I am having a bad days or when I am under severe stress, these bad experiences of mine can bubble up while I am interacting with developers. The longer your career goes on in this field, the more the baggage can accrue.

In spite of all of that, it is important that these past bad experiences do not interfere when working with present or future developers.

How can a tester cope?

• Vent with a friend -- outside of work -- if you need to. Unpack your baggage. Trade war stories.
• Join a networking group of other testers such as joining your local Ministry of Testing Meetup or starting your own.
• Speak to a mentor or career counselor.
• Talk to a manager you are friendly with
• Is a job just too difficult to deal with? Finding a new workplace may help.

Find a way to deal with these past comments that may haunt you. Do whatever it takes so that the next time you start working with your development team, you can do so with a clear mind.

Tip #2: Participate in the Initial Planning Sessions

When the initial work on the project is being scoped out, don’t be a bystander or a spectator when a new feature of the product is being planned. Allow your voice and your experience as a tester to be heard.

As the new features are first being introduced to your team, work side-by-side with the developers, brainstorming and reviewing each feature story by story.


Work together to see if the requirements are readable, understandable, clear, and concise. As the developers go back and forth trying to hash out if there is enough information there to build the new feature, work with the developers and business analysts totry to figure out if there are enough metrics listed to test.

Examples Of Metrics That Could Be Used:

… Is this feature testable?
… How do you know the feature passes? What does a failure look like?
… What is a critical requirement? What is simply “nice to have”?
… What inputs are acceptable?
… What is not acceptable?

If the feature has a UI segment, are their sample screenshots of how the product is supposed to look and behave? Screenshots, mock-up, and wire mocks are extremely helpful in creating conversations around functionality, usability, and testability while discussing requirements.

If your team is using Agile, work out how complex a story may be, comparing one story to another, assigning various points to the story. Trying to assign story points spurs a healthy and constructive debate, with testers right there in the thick of it, listening, taking everything in, and contributing the conversation.

Will a feature take a lot of time to test? If testers don’t speak up and say that they need to budget more time into developing and testing this feature, they are going to find themselves either blowing deadlines or working a lot of nights and weekends in their immediate future.

If you are using Agile, remember that you are trying to run at a healthy sprint. It is not supposed to be a death march.

Developing a good working relationship is more that just grabbing lunch with the developer you are working with to build and test the feature(though that works). Getting to know the developer as not just a co-worker but also as a person creates a better environment for communication and collaboration.

Tip #3: Dive Deep With Developers Before Your Testing Starts

The developer and the tester are two sides to the same coin. The developer is focused on drafting and building the product. My main focus as a tester is how a customer will operate the product.

The developer focus is on creating the product according to the ever changing specs.

A tester’s focus is to do risk analysis as the product is being changed and updated.

Developers aren’t opponents. We are teammates. We’re partners.

If there is a new feature being developed and you are unsure how the new feature will work, reach out to the developers. Work with them to figure out things such as...

… How data travels from the UI to the API to the database
… Checking if new fields need to be created in the database.
… Checking if data need to be processed before it gets used by the API
… Is the code being held together with paper clips, rubber bands and duct tape?
… Is there a risk that things related to this feature might break as things are being built or code is being cleaned up and refactored?

These concerns need to be addressed by both developer and tester. Work with the developers, business analysts, and user experience. Be the sounding board.

Tip #4: Enjoy Each Other’s Testing Perspectives

Developers and testers have different perspectives when it comes to viewing the software product under construction.

Developers see the product from the bottom up, sometimes seeing the user interface a thin plastic veneer covering the machinery of the product.

Testers tend to see the product from the top down, starting with how the customer uses the product.

This difference in perspective extends to the subject of testing.

Developers may think of testing at a code level, with a focus on unit and integration tests.

Testers may focus more on functional tests, examining the product as a whole.

By sharing each other’s unique perspective you help each other get better in your own profession.

When testers and the entire development team work together, they become more interdisciplinary. Ask the business analyst about how the requirements were constructed. Ask the user experience people how they determined what the product should look like. Ask the developer to give a code walkthrough while the feature is being built.

See if you can set up pair testing with the developer. You would get to know more of how the product is built and the developer will get more exposure to how to test this creation you are both shaping.

Tip #5: Under Times Of Stress: Try To Be Kind

It is very easy to get stressed out in the software industry. Deadlines are always looming. Things move so fast. There is always a new tool or technology to learn every few years. Requirements can changes quicker than you can keep up. Things can fall apart. It is easy to get overwhelmed. These stressful times are why we have done all this work, for these stressful moments.

If you are feeling the stress, the developer is too. Like in Alice in Wonderland, developers are running the red queen’s race, running as fast as they can just to stay in the same place.

Tech stacks change constantly. Front-end developers suddenly need to become experts in JavaScript, then Angular, then Ember, then React JS or Vue JS, and whatever javascript framework Google, Amazon, or Facebook are pushing next year.

Even if testers work side-by-side with the rest of the development team in planning how to develop and test a feature, communication can still short circuit. The bug you found might not be a bug at all:

The requirements may have changed, and a conversation or midnight email happened between product owner and developer that you are not privy to.

The developer might have realized last minute that the product does not have the structure to support all of the new requirements. Things were scaled back.

A bug was already found, and the designer, developer, and product owner had a meeting and decided that they could live with the bug, and they just haven’t had time to communicate that to you yet.

It may not be a bug at all. It could be a not-yet-documented feature.

When you find bugs in the code... try to be kind. Don’t act as if the bug represents a failing of their work ethic. In the software industry, we are doing so much with so little time, it is easy for things to get missed. Establishing a good rapport with each member of the team, doing a deep dive on technical aspects of the feature, soliciting feedback in testplan creation, and pair testing with the team can all help establish good collaboration amongst the team.

The most important part to remember? Under times of stress: Try to be kind.



Happy Testing!

-T.J. Maher
Sr. QA Engineer, Software Engineer in Test
Meetup Organizer, Ministry of Testing - Boston

Twitter | YouTube | LinkedIn | Articles