On the importance of communication between testers and developers _ test

Before I begin to discuss this topic, I would like to give a real example:
A couple live in the same house, but they don't communicate with each other, or they don't have any good communication. They only communicate in newsletters when something big happens. Otherwise they are too busy with their own lives, and have no time to disturb (take care of) each other. What will happen over the ages. A setback, a bit of frustration, a superficial anger, an outbreak. Only more communication, fewer disputes, some identification and mutual encouragement can make a relationship more secure.
Now, compare the situation above with the software project cycle.
The relationship between the researcher and the tester is similar in a way that they work hard for a project and are committed to the success of the project. No project in the world succeeds because of tools, budgets, code, or infrastructure. The real factor in project success is always people. The success of things is often inseparable from a team.
After smoothing out the main line, I hope you understand thoroughly why testers and developers have to communicate and work as a team.
Why testers and developers have to communicate and work as a team.
First, let's take a general view of the benefits of working as a team for developers and testers:

#1. The project is successful by default:
This project is successful when a project does not lead to frequent disagreements between the development team and the Test team because of trivial issues and self-esteem. Most of the time, the development and testing team is playing a task assignment game. Yes, that's the bug assignment. Everyone wants to prove that the problem comes from someone else. If you can understand that the problem ultimately belongs to the project and try to solve it together, then all the problems will be solved.

#2. Personal Growth:
Everyone will grow up because it is a benign competition and there is no dark struggle. Ideas are shared and suggestions are accepted to give everyone an opportunity to progress.

#3. Team Growth:
Mutual understanding and mutual respect among team members will ultimately make a team stronger and more competitive.

#4. Learning for the Future:
Everyone gets to learn after delivering a successful project. A team's future projects will become more successful, more convenient, and smoother.
OK, now we know that working together has an advantage over being a developer or a tester, but how it works.

Testing and developers: communication is the key.
The idea of working together:

#1. To put yourself down at work:
With or without knowledge, we take ourselves to the place of work. We think we did the best (there's no doubt about it), but that doesn't mean that others are doing badly.
If a developer thinks that all the defects reported in his module are ignorant, ignorant, malicious or intentional, the flaw here should be the ego rather than the bug itself. If a tester thinks that the bug he reported was rejected because the developer wanted to hurt them because the developer didn't want to fix the bug because the developer thought the tester didn't understand things correctly or because the developer thought he was a developer and did the best job ... The thoughts and bugs of the test will be reduced accordingly.
By demonstrating and practicing ourselves, we are trying to break ourselves out of growth and get others out of the work.
So if possible, don't think of yourself as a tester, first think of yourself as a member of a team and try to do things right. Don't feel the shock when the bug is turned down, but try to figure out why. Do not stop the test after the estimated test time has ended. Don't underestimate yourself, it is a great job to accept development and don't be too proud of yourself to find problems in other people's work.

#2. Seeking truth from facts:
As a tester, the most painful time is when you ask for a bug that is rejected. Seek truth from facts, try to understand the reasons behind rejection, try to figure out what you misunderstood, and if you think the scenario you are proposing is correct, try to move on and try to convince the developer or project manager.

#3. Prioritize projects:
Always focus on the overall situation, according to the actual situation to determine priorities. A project is more important than a bug or a person. Lay down your ego and go to the developer's desk to discuss, share, understand, and work.

#4. Be patient:
Things don't change easily, so be patient and stick to the good things you do. If someone gives you negative feelings or if a developer disagrees with your suggestions or bugs, don't give up easily.

#5. Share ideas, but do not enforce:
Frequent communication between the development and testing teams can help both sides generate more ideas. Developers can suggest how to better test a particular module, while testers can show if bugs are corrected. Open your heart to new ideas and suggestions.

#6. The recipient is going to be wrong:
After discovering a serious bug, don't tease it in front of developers. Be aware that testers work the same way as developers in times and budget constraints. No one can create a bug-free software, or the test will not exist. So understand your role and help correct the problem instead of making fun of them.

#7. Knowing that multiple teams are definitely better than a team:
Once a test team is disconnected from other development teams, there is no production capability. When testers adjust themselves to fit among developers, develop a relationship and create a good environment. When all the developers and testers are working together, it's a win for both sides.

#8. Agile and pairing tests:
Like agile methods, collaborative work, pairing tests, working with developers, frequent discussions and meetings, fewer documents, giving equal weight and respect to everyone's work.
I will sum up a few points:
If you think you're a janitor, you'll always be a janitor.
But
If you think you're trying to make the world a better place, cleaner, catch the garbage collector, and work strategically, the world will certainly get better.

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.

Please don't forget to share your thoughts on how to get developers and testers working together.

The original text reads as follows:

To start the discussion for said topic, I want to take a real-life example:
A husband and a wife, living in the same house, are not communicating with each other. Or let ' s say there be nothing to communicate between them. They just text each other if anything important to is taken care. Otherwise both are busy in their own lives and don't disturb/take care much about each other. What happens after? A frustration rises, irritation multiplies, anger surfaces and an explosion occurs. A relationship strengthens only if there are frequent communications, rare fights and multiple agreements and celebrations With each other.

Now, compare the above situation and software project life cycle.

A developer and a tester ' s relation is something similar, who works for a project to make it successful. No project in the world had been successful because of tools, budget, code or infrastructure. It is always real people who made project successful. And to make something successful, A's required and not a individual.

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

Cover what are the benefits if developers and testers as a team:

#1. By default project is successful:
When the "project does not" development team and testing team fighting frequently for trivial issues and ego, the Projec T 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 this problem is from the other end. If it ' s understood that ultimately the problem are within the premises (project) and if tried to resolve it together, all t He and problems can be taken care.

#2. Individual growth:
Everyone grows because there is a healthy competition and no hidden fights. Ideas shared and suggestions accepted give everyone a chance to progress.

#3. Team Growth:
Ultimately a team of becomes stronger and competent, by have team members who understands each other and respects each othe R ' s work.

#4. Learning for future:
After delivering a successful project, everyone learns. 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 tester, how do I but?

Tester and Developer:communication is a key
Ideas to work together:

#1. Leave Work related ego:
Knowingly or unknowingly, we carry a ego with ourselves while entering to work place. We are doing best work (no doubt about it) but that does don't mean others do.
If a developer thinks that any defect reported for the module he developed are ignorant, trivial, a malicious idea or an EF Fort to harass then the defect was an ego problem rather a bug. If a tester thinks the bug he reported is rejected because developer wanted to hurt because To resolve bugs, because developer thinks-specific tester does not understand things or properly because T Hinks He was a developer and he does the best......the testing ideas and bugs, both are to going.
By showing and acting ego, we are the trying to deprive the from ourselves and growing from others.
So, if possible, does not-do-you-are a tester, the ' you ' are a team-member who-working hard to make things Right. Do don't get hurt when bugs are rejected but try to know the reason behind it. Don't stop yourself after knowing that the estimated time for testing is completed. Do isn't underestimate yourselfby accepting that development are a great job and finally do does not have over confident by assuming That's are superior because you are finding problems from others ' work.

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

#3. Prioritize the project:
Always bigger picture and prioritize things accordingly. Project is more important than a bug or a individual. Leave your ego behind and go to developers ' desk, discuss, share, understand and work accordingly.

#4. Be patient:
Things do is nightly so is patient and keep doing good work. Do don't get de-motivated if someone remarks negatively or a developer does not consider your bug/suggestion for once in a While.

#5. Share ideas but don't emphasize on implementation:
The frequent communication between development and testing teams helps the more generating to each ideas. Developer can suggest about how to test a particular module better and in the same time 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, does not make a fun the IT in front of developer. Understand that's way a tester works under time and budget crunches, same applies to developer. No One can create a bug free software otherwise testing would not have existed. So understand your role and help in rectifying issues rather than making fun of them.

#7. Understand multiple teams always work better the than team:
A Testing team isolated to development team, cannot to be productive. When a tester adjusts himself/herself among the developers and develops a mutual relation, a good environment to team CREA Ted and then all the developers and testers work together, it's a win-win situation for both.

#8. Agile and pair Testing:
Prefer agile methodologies, work together, do pair testing, work with developers, discuss and meet frequently, document LE SS, give equal importance and respect to everyone ' s work.
I would conclude the topic as below:
If you are are a sweeper, you'll be a sweeper always.
But
If you are are trying to make the world better and clean and catch up with trash collectors and put in efforts ing things strategically, the world would surely to be better.

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 more ideas on "How to" developers and testers work for a project together .