Five Tips On How Testers Can Collaborate With Software Developers

Previously Published August 27, 2019 on the Threat Stack blog, based on the TestingGuild.com talk I gave back in June 2018, How to Work With 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 improves as the quality of communication increases.

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

Developing a good working relationship with developers can be tricky. I am really fortunate working here at Threat Stack where my work is valued and my ideas are appreciated, but in my career — like many of you — I have had my struggles.

With that in mind, here are five tips that I’ve found helpful in nurturing and developing relationships with my 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
• Reporting too many bugs
• Making the team look bad
• 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 actually 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, they can bubble up while I’m interacting with developers if I’m having a bad day or if I’m working under pressure. The longer your career goes on in this field, the more the baggage can accrue.

In spite of all that, it is important that you don’t allow these past experiences to interfere when you’re working with developers.

So 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 your local Ministry of Testing Meetup, or start your own.
• Speak to a mentor or career counselor.
• Talk to a manager you are friendly with.
• If a job is just too difficult to deal with, finding a new workplace may be an option.

Find a way to deal with past negative experiences so they don’t end up haunting you. Do whatever it takes so the next time you start working with your development team, you can do so with a clear and positive mind. 

Tip #2: Participate in the initial planning sessions.

When a new product feature is being planned and the initial work is being scoped, don’t be a bystander or a spectator. Work with your teammates to make sure your voice and your experience as a tester are being heard.

Developing a good working relationship is more than just grabbing lunch with the developer on your team to build and test the feature (although that helps). Getting to know the developer not just as a co-worker but also as a person creates a better environment for communication and collaboration.

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 whether there is enough information there to build the new feature, work with the developers and business analysts to figure out whether there are enough metrics listed to test.

Examples of metrics could include the following:

• Is this feature testable?
• How do you know if 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 there sample screenshots of how the product is supposed to look and behave? Screenshots, mock-ups, 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 to the conversation.

Will a feature take a lot of time to test? If testers don’t speak up and state 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.

Tip #3: Dive deep with developers before your testing starts.

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

The developer’s 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 and testers aren’t opponents. We are teammates — we’re partners.

If a new feature is being developed and you are unsure how it 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
• Whether new fields need to be created in the database
• Whether data needs 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 as a thin veneer that covers 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 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 will get to know more about 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 change more quickly than you can keep up. Things can fall apart. It is easy to get overwhelmed.

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, or Vue, and whatever JavaScript framework Google, Amazon, or Facebook is 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 at the last minute that the product does not have the structure to support all 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, and 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 test plan creation, and pair testing with the team can all help establish good collaboration amongst the team members.

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


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

Twitter | YouTube | LinkedIn | Articles