How Important is it for a Tester or Developer to Communicate with Each Other?

To start with the discussion of the above-said topic, I wish to take a real-life example:

Imagine a husband and a wife, living in the same house, are not communicating with each other. Or let’s say there is nothing to communicate between them. They just text each other if anything important needs to be taken care of. Otherwise, both are busy with their own lives and do not disturb/take care much about each other. What happens after days? A frustration rises, irritation multiplies, anger surfaces and finally an explosion occurs. Any relationship strengthens only if there are frequent communications, rare fights and multiple agreements and celebrations exist with each other.

Now, compare the above situation with the software project lifecycle.

A developer and a tester’s relation

is something similar to that, they work together for a project to make it successful. No project in the world had been successful because of tools, budget, code or infrastructure. It was always real people who made the project successful. And to make something successful, a team is required and not an individual.

After drawing that brief line, I would like you to take a deep dive to understand why a tester and a developer should communicate/work as a team?

Why tester and developer should communicate and work as a team?

First, let’s cover what are the benefits if developers and testers work as a team:

#1. By default project is successful:

When the project does not see development team and testing team fighting frequently for trivial issues and ego, the project is guaranteed to be successful. Most of the time, development and testing teams play a game of assignment. Yes, it is a bug assignment. Everyone wants to show that the problem is from the other end. If it’s understood that ultimately the problem is within the premises (project) and if tried to resolve it together, all the other problems can be taken care easily.

#2. Individual growth:

Everyone grows because there are a healthy competition and no hidden fights. Ideas shared and suggestions accepted will give everyone a chance to progress.

#3. Team growth:

Ultimately a team becomes stronger and competent, by having team members who understand each other and respect each other’s work.

Also read => How to Build and Grow Your QA Team

#4. Learning for future:

After delivering a successful project, everyone learns something new. The future project for the team becomes more successful, hassle-free, and smooth.

Ok, now we know the benefits of working together rather than being a developer or a tester, but how to make it work?

Tester and developer: communication is a key

Ideas to work together:

#1. Leave work related ego:

Knowingly or unknowingly, we carry an ego with ourselves while entering the workplace. We think that we are doing the best work (no doubt about it,) but that does not mean others do not.

If a developer thinks that any defect reported for the module he developed is ignorant, trivial, a malicious idea or an effort to harass then the defect is an ego problem rather than a bug. If a tester thinks that the bug he reported was rejected because developer wanted to hurt, or the developer does not like to resolve bugs, or the developer thinks that the specific tester does not understand things properly or because developer thinks he is a developer and he does the best, then the testing ideas and bugs, both are going to decrease.



By showing and acting ego, we are trying to deprive ourselves of growing and others from working.

So, if possible, do not think that you are a tester, first think you are a team member who is working hard to make things right. Do not get hurt when bugs are rejected, rather try to know the reason behind it. Do not stop yourself from knowing that the estimated time for testing was completed. Do not underestimate yourself by accepting that development is a great job and finally do not be overconfident by assuming that you are superior because you are finding problems from others’ work.

#2. Be realistic:

As a tester, the most painful time to face is when the bug you reported gets rejected. Be realistic, try to understand the reason behind the dismissal, try to understand what did you misunderstood or presumed, try to convince the developer or the project manager if you think that the scenario you presented was correct and then try to move on.

#3. Prioritize the project:

Always look at the bigger picture and prioritize things accordingly. The project is more important than a bug or an individual. Leave your ego behind and go to developers’ desk, discuss, share, understand and then work accordingly.

#4. Be patient:

Things do not change overnight, so be patient and keep doing your good work. Do not get de-motivated if someone remarks negatively or a developer does not consider your bug/suggestion once in a while.

#5. Share ideas but do not emphasize on implementation:

The frequent communication between development and testing teams helps to generate more ideas on each side. The developer can suggest about how to test a particular module better and at the same time, the tester can show how to correct the defect. Open yourself for new suggestions and sharing ideas.

#6. Accept that human being is mistakable:

After finding a critical bug, do not make fun of it, in front of the developer. Understand the tester works under time and budget crunches, same as the developer. No one can create a bug-free software, otherwise testing would not have existed. So understand your role and help in rectifying the issues rather than making fun of them.

#7. Understand multiple teams always work better than an individual team:

A testing team isolated from all the other development team, cannot be productive. When a tester adjusts himself/herself among the developers and develops a mutual relation, a good environment of the team is created and when all the developers and testers work together, it’s a win-win situation for both the parties.

#8. Agile and pair testing:

Prefer agile methodologies, work together, do pair testing, work with developers, discuss and meet frequently, document less, give equal importance and respect to everyone’s work.

I would conclude the topic as below:

If you think you are a sweeper, you will be a sweeper always.

But

If you think you are trying to make the world better and clean and catch up with trash collectors and put in efforts in doing things strategically, the world would surely be a better one.

About the author: This post is written by STH team member Bhumika Mehta. She is a project lead, carrying 7+ years of software testing experience.

Happy testing, as usual. :)

And please don’t forget to share your ideas on how to make developers and testers work together for a project success.