Testers vs Developers - The Rivalry Continues

It’s been a while that I was not able to write due to many reasons; hectic professional life routine, some project deadlines and other lame excuses. I have decided to write a piece about the professional collaboration of cross domain agile team members in SCRUM environment. Actually, to be very precise; I want to share my personal experiences with the readers of this article on a hot topic in any organization; yes as a tester or QA you can guess it, nothing other than – Testers vs. Developers. 

Well, it’s not the fault of developers, no one like to hear faults in all the hard work he/she has put in. And the same thing which we (testers) are doing, of course, the intention behind that is to deliver quality output to the client.

Constantly, there is bitterness at some point in the game between these two roles.

Source: Getty Images

I believe that this tussle is good for the overall quality of the software, provided that it is carried out and managed in a healthy professional manner. There should be a challenging environment in which both sides boost their skills. For Example, a developer can friendly challenge a tester to find a bug in his piece of functional code and vice versa. I have seen this practice over the years in different corporate sectors and I personally know some disciplined developers who are capable of this efficiency having minimal defects percentage.

Let me share some personal aspects point by point to enhance this rivalry relationship and transform this so called negative energy into positive one for the overall quality of product and meeting deadlines in due time. In the end, it’s the responsibility of both to ensure that the ultimate output is to work at its best.

1-      Inter Team Communication

While working with your team, let's say you notice that the team works well together for the most part of the sprint, but there are some trouble spots in any particular window. Why not become the team builder yourself and improve team cohesion? Take the time to observe and figure out ways to improve team communication and cohesion. You can develop team skills outside the QA realm by improving the team's performance and productivity. Cross training, along with active, communicative stand up meetings and alert participation in team discussion, is essential to being able to communicate well and produce a higher-quality application.

It's true that the team as a whole must bake quality into the software, but the QA member must own and encourage it. How? By setting a personal example. Speak up, actively participate. Acknowledge openly when you don't know something. Be willing to adjust how you work to suit the needs of each team member. In other words, figure out how to communicate effectively with each and every person on the team. It's not as hard as it sounds, but it does require the ability to be humble, assertive, and flexible. Doesn't that sound like a QA professional? It should.

2-      Building respect

Try to build friendly relations with developers, so that they can feel comfortable to share anything with you. This relationship is based on the pivotal pillar of respect.

We need to create the environment where the collaboration is carried out with mutual professional respect, no private agendas, and the ties are developed. To testers, do your homework; don’t just flag things because you don’t understand the functionality. To the developers, when your QA asks for time/meeting, make it happen; a tester seeking answers is a bug resolved before it happened.

As QAs lead the team-wide effort to build in quality to the software, they will also be garnering enough respect from developers that they'll test their code completely before moving it forward. With the creation of mutual respect comes cleaner code builds, with far fewer obvious defects. With a strong team, developers take additional pride in what they deliver to QA because they respect QA.

This mutual respect naturally leads to better code deliveries, because respect helps grow and nurture a support system of developers on a professional level. You don't have to be everyone's best friend, but as a QA you can certainly build and carefully develop a professional relationship with your team members. In order to gain your team member's respect, focus your testing by including all the details. Ask educated questions. By educated, I mean to make sure you've read all the design documentation and have more than a clue about the feature being developed. When it's clear that you've done some research into failures before asking questions, your team members know that you've done your part, as opposed to expecting them to take up the slack.

3-      Bug Reporting Style

Keep your issue reporting style positive, it should not hurt someone’s feelings. Try to be polite and professional instead of boosting the weakness of your fellow team member. I have seen testers literally jumping from their seats and running around whenever they find a major defect log in the system. Keep yourself composed and calm while reporting and interacting the team after observing any functional issue in the flow.

Source: Getty Images

Let’s take a simple example; rather than saying this is defect, say if user will do this then he will get this so do you think this is a right use case / behavior for this particular flow ?

After this he himself will say no this is a defect; please log it. (That’s it, your job is done.)

I personally believe that If QA personnel know how to present his/her issue in front of developers then many problems can be solved effectively.

4-      Bug Report Timing

Don’t report critical bugs at the release time. It’s going to hurt the developers as well as management. Beside that it is a bad professional approach as well on tester’s behalf.

Source: Getty Images

Testing will inform and benefit construction the most when testing is present early in the development process. The clearest manifestation of this is the test-first approach. The developer should know what tests will be run so the tests can be anticipated as part of construction. Before construction of a user story begins, the developer and tester should discuss the kinds of testing to be performed on the story.

The idea of a code drop or hand off implicitly assumes that the developer's job is done and the tester's job is ready to begin. A better approach is to have the tester testing on the developer's machine throughout the process, even before the code is fully completed and checked into the source repository. A tester who is looking at the developer's work in near real time can give earlier feedback that identifies ambiguities and prompts needed improvements. There's no reason to wait for a formal build before giving such feedback, although the formal build also must be tested.

Well, in the end. I would say that let this rivalry grow in a positive manner and keep expecting the bugs. I have already a challenge pending from my fellow team member who happen to be a developer. So, fingers crossed till we meet again for another exciting topic.

Sources :

https://techbeacon.com/app-dev-testing/are-developers-more-important-qa-testers-probably

https://www.softwaretestinghelp.com/how-to-make-developer-and-qa-relationship-healthy/