Developers and testers are on the same side – it does not matter if a company puts them in the same (agile) team or in separate teams of developers and testers. It is up to both testers and developers to build a great application. To achieve this goal, they will have to collaborate together in a productive way. To do so and to get their job done better, faster, and easier, there is different practical advice and hands-on advice that can help. I will start with tips and approaches that focus on individual cooperation between a developer and a tester. In the second half of this article, I’ll share advice that will help to improve cooperation on a team level.
Better cooperation on individual level
As a developer, I consider testers as my safety net. I would prefer a bug to be reported by a tester, rather than the end user finding a bug in production.
Generally speaking, people do not feel comfortable when someone criticizes their work. Developers should not think of testers as somebody who is constantly telling them that they did something wrong. Instead, developers should consider testers as partners who are trying to keep end users from criticizing their work. Testers at the same time should be aware that junior developers might feel uncomfortable when they receive a bug report. As they build up experience, developers won't, or at least shouldn't, get defensive when they receive bug reports.
I can tell from my experience, cooperation between a developer and a tester will be better if mutual respect is clearly visible.
Practical approaches to hard to reproduce bugs
Sometimes, a developer cannot reproduce a bug that a tester has reported. In my 17 years of professional experience as a developer, I found that there are a few tips and tricks that can help.
When a tester sends a screenshot to a developer, it is more effective to send a screenshot of the whole application — and not just a piece of the user interface. Sometimes, when a bug is on one part of the UI, I manage to find a clue for reproducing it on the other part of the UI. Simply by sending the screenshot of the complete tested application interface, a tester can facilitate the developer’s work to reproduce a bug.
But what if a screenshot is not enough to reproduce a bug? What if the additional information provided by a tester are not sufficient? Video is a great assistant. Use the screen recording app to record everything that goes on the application UI as part of the test. In my experience, a video is useful because a developer can find a (small) clue for reproducing a bug somewhere between steps that were already mentioned in the description of this bug. A small detail could trigger a bug, and a video helps a developer discover that detail.
Please note: It is not necessary for a tester to speak in his/her recording. Hearing the tester in video was never crucial for me to reproduce a bug. Many testers will feel more comfortable if they are not asked to record themselves commenting on the video.
Managing conflict
In case of a conflict between a tester and a developer, everyone involved must use effective communication, be diplomatic, and not take things personally. Both parts need to look at things from another person's perspective – this other person also has timelines, tasks, priorities, etc.
The aim is to prevent a conflict. In everyday life, there are times when a short message can prevent a misunderstanding and conflict that follows.
Always remember, that we are all on the same side as we build the same application.
Teamwork from scratch
I would recommend, especially if all developers and testers do not have lots of experience, to make sure that developers know all about the testers scope. And the contrary.
To avoid possible misunderstandings between testers and developers, or even conflicts between both teams, it is essential that everyone knows other teams’ responsibilities.
If developers are spending some of their time maintaining production, let the testers know which percentage of time developers are spending on that task. This way, testers will understand that sometimes developers are asked to drop what they are doing and focus solely on maintaining production.
Testers in a team might be involved in onboarding and training newly employed testers that are not assigned to their team. Sometimes, testers are asked to help another team. It’s also important to inform developers that testers have an additional (temporary) task, so that the whole team is aware of workload.
I would recommend that testers and developers, but also all other team members, learn theory about teamwork.
For example, I find it helpful to know that when even one team member joins or leaves a team, we end up with practically a new team. The team dynamic will be different, even when one team member changes. The dynamic will change even between team members who stay on the team the whole time.
Agile or waterfall teams
I have worked in agile teams using mostly Scrum. But at some point, we also used SAFe (Scaled Agile Framework). At other times, I have worked in teams that used the waterfall process. Based on my experience, I can say that working in an agile way, where developers and testers are part of the same team, brings multiple benefits.
One of the advantages of having both testers and developers in the same team is visible during sprint planning meetings. While the team plans the workload for the next sprint, the PO can discover additional work throughout the meeting. Previous experience, and inside knowledge of the application can help individual developers share valuable insights and useful new information. That information can impact upcoming tasks. It is great to have both developers and testers present at the planning meeting, so everybody immediately hears that additional information. It helps testers to get the job done faster, as all test cases are covered.
Without testers and developers both present at sprint planning meetings, time would be spent on additional meetings, emails, or calls between developers and testers, just to have developers repeat information that testers could have heard in the sprint planning meeting.
Also, and from my experience, testers can improve precision of estimates, because they have more information about the testing process itself. They sometimes realize during sprint planning that additional testing should be done.
Another advantage of testers and developers working in the same team is that on daily scrum meetings, valuable new information is often shared among all team members. Sharing information will improve productivity, but also increase team spirit. In fact, it increases willingness to help each other. Some people, more than others, will be inclined to help those colleagues who are in the same team.
In that case, the waterfall process is used, so testers need to be included early in the task work. This is referred to as the shift-left approach meaning that work of testers is shift left, in other words it’s shift toward the start of the process.
Better communication
Many people will agree that communication between testers and developers is important. I would like to expand on that.
It’s essential to share strategic information like deadlines, change of priorities etc. with everybody involved in building an application. Even if it seems that some information is not vital to all team members, remember that sharing information will make people build a team faster. Keeping people in the dark, and not including them on important topics can decrease team spirit, cooperation, and productivity.
If someone in a team keeps information and knowledge about the project to itself and shares bare minimum with the rest of the team, that will hurt both the team and the complete project in the long run. It does not matter if this person is a developer, a tester, a business analyst, a product owner, or somebody else. Eventually negative effects will arise. A team leader should be informed and should take responsibility for handling the situation.
Conclusion
To improve their cooperation, testers and developers can choose from a long list of advice. Cooperation between testers and developers is crucial to complete the application on time. From day one, incorporate advice for individual cooperation between a tester and a developer, and also apply advice for better teamwork. Think about the advice changes and what's best for your team.
.png)
