Software Developers and Testers: Friends or Foes?

I have often observed situations where developers and testers working on the same project seem to be in a constant struggle with each other. But why – why are the two different roles so prone to working against each other rather than working together? My personal view on the subject has actually changed over the years. In this article, I would like to share my thoughts in the form of a story that I’m sure everyone who has been working in the software industry can relate to. The story is a brief overview of my time in software development, highlighting on events that have contributed to molding my view on how teams should interact with each other to allow the highest probability of success. I will share some of the key items that I have taken away from my experiences thus far, and hopefully they will provide tools that both developers and testers can use to positively affect their work environments and the way in which software is delivered.

Over the past 18 years, I have been involved in small and large scale software projects: starting as a tester, moving on to a developer, off to team lead and so on. Through this progression, I have been able to look at the implementation of new software systems from many different views. Most importantly, I have been fortunate enough to experience software development both as a developer and as a tester. In the beginning of my career, when I was working as a tester, I could not believe that the developers were even trying to write working code. If they were, how could they have possibly thought that they had performed well in their roles? Moving on to development, I was astounded by how the test team would try to tell me how I should fix a defect and, even worse, that they thought some of the items they found even qualified as defects. There was a lot of frustration on both sides and, as frustration built up and deadlines loomed as they always do, it often escalated to a point where there were open conflicts.

Why would I want to do this over and over again? At the time, I was not sure. I pushed through and, throughout the years, I worked on both good and bad projects. I didn’t really know why some projects were good and some bad, or what criteria I was even assessing them on. They were all delivered, and customers were happy, yet some were still better than others. One of those “good” projects occurred just over a decade ago. It is only looking back at that project now that I can say it was the moment where my views on the roles of tester and developer changed. After all, keep in mind, I was a tester who criticized developers, and I was a developer who criticized testers.

On this particular project, I was one of two lead developers. As most projects do, we had a development team and a test team. Same old stuff, I had seen it many times before. But something was different on this particular project. Please do not get me wrong; the project was not perfect. Like with any project, all the team members did not get along at all times. The biggest difference that I know now existed on that project compared to the previous projects I had been on, was that everyone was treated as equals and, as a result, respected each other. During good times, we celebrated the successes of each other. During the bad times, we were open and honest and picked up our fellow teammates to push through. All the while, there was no judging and no accusing – just a group of people working together, each using their individual strengths for the best of the team. The developers didn’t get upset by a defect being logged, instead they looked at it as someone helping them to make the product better. The testers understood the complexities that the developers were facing and were simply informing the developers of discrepancies between the product and the requirements. It was a wonderful experience, not because we were successful in delivering the product (which we were), but because we were all in it together and all took responsibility for the project. We looked out for each other and cared about all team members. Successful delivery was never even a question in that environment. Everyone just took that part for granted. What we did not take for granted was each other.

In the title, I asked the question, “Friends or Foes?” Hopefully, you were able to draw the conclusion that I believe that with those two roles on a project – developer and tester – being friends will provide the best outcome and the most favourable view of your career as you look back. I described my sample project as one that had a development team and a test team, but in truth it was one team: a project team that consisted of development professionals and test professionals. It is up to each and every team member to work to make it a single united team; it won’t just happen, but it is a rewarding experience when it does.

To sum up, I want to leave you with a few lessons that I took away from that experience that may hopefully help you move forward in the creation of that one team approach to software development projects. I believe that these hold true regardless of the role on your particular project. As a disclaimer prior to continuing, please note that these will all seem like very simple things – common sense even. One key lesson that I have learned over the years is that what appears common sense is almost never seen to be common practice.

• Remember that everyone on the team has the same goal.
• Do not attempt to perform the roles of other individuals, or tell them how to perform their role.
• Trust your team members and value what they do.
• Learn what others on the team do to better appreciate the value they bring – all team members bring value.
• Place yourself in somebody else’s position to better understand their struggles and see how you can help them.
And finally, I believe that the most important lesson is…
• Respect everyone on the team.