Developers and testers have different backgrounds, aspirations and, on many occasions, fight each other to the finish. Typically, this is because most developers join the workforce with computer science degrees, and testers come from all kinds of backgrounds and seem to just have a knack for breaking things—specifically, developers’ code.
Not only can that be frustrating to a developer, this rift in different experiences between developers and testers and the differences in their job functions can quickly spawn negativity in the work place. Maybe we need to take a step back and learn more from one another. When they collaborate, the difference in strengths of developers and testers can help to increase efficiency throughout a development team.
I’ve been to testing conferences in the past, but I decided to be more daring and head to a developer conference called SenchaCon. Sencha is a leader in HTML5 development tools and frameworks on Web and mobile. There were more than 800 attendees and I’m not completely sure, but I may have been the only tester there. It wasn’t easy to hide as a tester in a developer’s world—especially since most conversations at conferences start with, “What do you do?”
Many of the developers I spoke with were very excited to share their experiences with how they test their products. When I told them that I was a tester, they didn’t seem confused as to why I was there; rather they were excited to hear about how I see the connection between developers and testers. What I learned, however, was scary.
- A developer told me that they didn’t even have a QA team and that they did all the testing themselves.
- Another person told me they have QA but they don’t interact with each other the way they wanted.
- One developer actually said they’d feel better having a QA Engineer sitting right next to them as they coded to check their work.
It was definitely a mixed bag, but overall the sentiment toward testers was the same amongst all the developers I talked with—testing and testers are a necessity, much like editors are a necessity to writers. The developer who didn’t have a QA team actually wanted to recruit me right then and there when he learned I used to do QA. I kindly did not accept his offer but understood why he wanted to get a tester on his team as fast as possible. Imagine writing a whole program without testing it and then outsourcing the testing to another team. That sounds like an absolute nightmare.
The developer who told me that he wanted to have a tester by his side at all times was the most heartening to me as a former tester. The problem with working in a different room is that developers and testers won’t be completely synchronized and QA needs to be checking the code as soon as it is written. Defects can always fall through the cracks and not being side by side or face to face can allow more chances of miscommunication. If you’ve ever read a tester’s feedback to a developer via email as opposed to in person, you know that there is a lot of room to offend or misinterpret someone by accident via email. To a developer, they can take it as harsh criticism from someone who they don’t believe is as technical as them. To a tester, reading a developer email that states, “It works for me, so it must be something you’re doing wrong” can be infuriating. In-person communication, though not always possible for every team, should be highly sought after in all development teams. If you can’t be there in person, maybe a video chat would be better.
Although it seems that testers destroy what developers create, there is a lot of room to relate to each other. Testers are technical in different ways than developers but this is how one side can learn from the other. A lot of testing and development teams are cut off from one another and this is where the disconnect in understanding comes from. There could even be conferences where testers and developers come together to collaborate on the same goal—better quality software!
So what can we do to bring testing and development closer together?
- You should always strive for something better in a development workflow and change can be tough but it is necessary. In this day and age, there should be no excuse for an easy-to-recognize bug making it to the end users and ruining a company's credibility because there was little testing done or testing done by the developers themselves.
- Developers can only do so much and need that tester by their side, not as a nuisance but as a support system.
- Communication between developers and testers should not be cut off. It may mean more work for both sides but that's the price you pay to maintain quality and reduce liability.
SenchaCon was certainly a great experience, and seeing the other end of the spectrum from the developer’s point of view was enlightening.