Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Talk So Testers Will Listen and Listen so Testers Will Talk

DZone's Guide to

How to Talk So Testers Will Listen and Listen so Testers Will Talk

Learn how to work with your testers to make them a part of the team and improve developer-tester relations at your organization.

· DevOps Zone ·
Free Resource

Can you release faster without sacrificing quality? See how with our free ebook Strategies for a Successful Test Automation Project and a free trial of Ranorex Studio today!

Communication Tips for Effective Developer-Tester Collaboration

Software development teams traditionally cope with the developer-tester communication challenge. Even with the advent of agile testing methodology and having cross-functional teams, the communication challenge remains paramount especially when trying to change the team’s mindset and bring everyone onboard working towards a single goal. Developers and Testers frequently face challenges conveying their points and communicating with each other.

Here are some tips, gathered both from testers and developers, to make developers lives easier when approaching an angry tester.

Don’t Think Testers Are Not Technical Enough to Understand You

When discussing any user story, design or architecture plans with a tester, do not assume that they are not technical enough to understand the intricacies of code. View testers as co-owners of your feature or user story, share all details and ask for their input in all phases of development. Most testers have a technical background or degree and are familiar enough to understand the issues you are dealing with even if they don’t know the actual programming language. Assuming otherwise will give the wrong impression and discourage testers from participating in design and architecture discussions.Image title

Do Not Disturb Unnecessarily

Testing is a creative and exploratory process, hence it requires immense concentration and flow. You must not assume that you can walk up to a tester just anytime for a chat - That will probably interrupt their work and give them the impression that you don’t view their time and their work as important as yours. Show appreciation for the creative and challenging job they do by respecting their time, scheduling discussion time pre-hand and not interrupting their exploratory test sessions.

Invest the Time to Know What Software Testing Is All About

Most developers do not invest time in understanding testing and hence do not have knowledge of what testers do or what their day-to-day tasks entail. Scrum teams enforce the rule of daily stand-up meetings where each team member discusses their work and progress. So developers must make an effort to listen, understand and keep track of test-related activities, especially for their own features and user stories. Over time, you will get a better picture of the daily activities, tasks, and challenges of testers, and also begin to help and provide feedback to your fellow testers. Try to help out by giving advice on test ideas, unique ways of experimenting with the features, reviewing test plans and documents and sharing internal design documents which can help design better test scenarios. This will help you better appreciate the art of software testing and will make the tester’s and your work more valuable.

Image title

Team Up

Testers and Developers must think of themselves as co-owners of the features they are creating together. So the failure or delay of one task must be seen as a failure of the team as a whole. This mindset will bring them to work together as a team wherever they see impending risks. Communication and trust are key to making this a successful partnership. Developers must endeavor to openly discuss all defects, their causes and resolution status with the testers, while testers must help by bringing maximum issues to light as soon as they can and aid them with all possible information. Defect counts are not as important as better quality!

See Testers as Product Experts

Testers typically have the most information about the product, its various functionalities and intricacies. Developers should think of testers as the first users of their software and consult with them about the behavior of the product. Testers are the best people to advise on areas like usability, functionality and replicating user scenarios. They are also the most knowledgeable people within the team about the real-time usage of the application. So while you as a developer are the technical expert, think of the tester as a domain and product expert, and both of you paired together can solve any challenge that comes your way and release the best product possible on time!

Conclusion

The developer-tester relationship has been strained from the beginning, and it is time to fix that. By having better communication, ensuring trust, respecting each other’s work and encouraging open conversation, we can have happier teams and better quality releases.


About the writer

Nishi Grover Garg is a Testing and Agile corporate consultant and trainer with hands-on experience in all stages of software testing life cycle since 2008. Together with Agile Testing Alliance(ATA), she conducts various courses, trainings and organizes testing community events & meetups. She has been a speaker at numerous conferences. Check out more of her content at the PractiTest QA resource center.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user's needs.

Start a free trial

Get your test automation project off to the right start. Download your free test planning template and a 30-day no-obligation trial of Ranorex Studio today!

Topics:
qa ,software testing ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}