Nearly everything in the relationship between development and test comes down to trust.
Testers, do you trust your developer to think about edge cases? Do you trust dev to test? Do you trust developers to have your back if you say there's a blocking bug?
Developers, do you trust your testers to present valid defects? Do you trust them to fully document defects? Do you trust them to accurately represent use cases?
You might say yes—but how often do you feel some hesitation, thinking of when someone has let you down? It's a common issue with teams that's even more evident when the lack of trust is between developer and tester. A lack of trust causes a breakdown of team dynamics and undermines their effectiveness.
So how do you start building trust between these two groups? By improving one relationship at a time. Each relationship that holds more trust is an example to the team and makes developing the next relationship easier.
Start by choosing someone to start a relationship with. Look for a developer or tester who already has a quality team mindset. Starting with someone who is already inclined toward listening is much easier and will let you more quickly have a relationship to hold up as an example.
In Jenny's experience, choosing a mid-level developer or a mid-level tester has been very valuable. Such developers will generally have enough experience and pull to start positively affecting the other relationships around them.
Once you've decided to work on improving your relationship with a particular tester or developer, these three steps will help you on your journey. Begin by setting clear goals and needs, work on owning your mistakes, and make sure you respect the knowledge they will give you by learning on your own.
Here are three specifics you'll need to develop trust between testers and developers on your team.
1. Set clear goals and needs
Developers and testers form one of the most important partnerships in a software development team. When we are on the same page about each other's needs and goals, our partnership is even stronger.
Start by thinking about what your goals are as individuals and as a team. Is it to break software? To create bug-free software? To get paid? To create the next big thing?
Writing down these goals will let you formalize them and communicate them clearly. You'll often find that the team's goals are very aligned, which starts to set the stage for a solid, trusting relationship. Everyone trusts that the team is working for the same goals.
Needs are similar; these are things that you must have to do your job well. They might be uninterrupted spans of time to work, a different approach when there are bugs, or time to figure out a problem on your own.
Once you have clarified those needs, you can look at how others on the team can support them. For example, instead of sending an email every hour, it's best to batch queries.
Often, if you're starting to build a relationship, you may not have the ability to sit down together and make these lists. But take the time to make your own and consider the needs and goals that the other person expresses throughout the workday.
[ Partner resource: Agile Testing Days USA conference ]
2. Own your mistakes
If you don't own your mistakes, no one will trust you. It is a common thing to make mistakes, be embarrassed, and have an instinct to hide. But when we own up to our mistakes and make a plan to prevent them in the future, it shows that we can take responsibility and can be trusted as a part of a team.
Making a mistake and rectifying it quickly and humbly can build more trust than if you'd never made the mistake. When you find yourself in the position to need to own a mistake, use that to your advantage to build trust. Never run away or deflect, even if you can't address the mistake immediately. Take ownership first and foremost. Then, start working on your plan.
The most important part of owning your mistakes is to have a plan to prevent the issue in the future and to make sure you don't make the same mistake again. This can be difficult personally and within your team, though it will get easier with practice.
Jenny has test plans and Adrian has lists. Both of these are methods to make sure that we don't repeat our mistakes. You can find your own way, but you'll need to make an effort to show that you can be trusted.
3. Learn on your own
Asking someone for help and approaching that person with the desire to learn from the other's expertise is a great way to improve your relationship with a developer or tester. Jenny in particular uses this method when she has a new dev that she would like to talk to about automation.
If you gain knowledge from someone, respect that knowledge transfer by using it as a jumping-off point to gain more knowledge, not as a final destination. If you talk to someone and gain some knowledge, think of it as an invitation to find out even more.
When other people feel that you are self-sufficient and can learn on your own, they are encouraged to help you even more. Of course, if you don't understand and need clarification, that's a great reason to go back and ask for more information. But if you can go off, learn more, and come back to have a conversation about the knowledge, that's even better.
There's nothing that builds trust quite like teaching someone something and then seeing that he or she has applied that knowledge without you. When you see that, it's one more thing off your plate, one more kind of problem that you're not alone in solving.
How you know when trust is there
There are many more ways to develop trust in a relationship. Taking one or more of the above three suggestions will get you well on your way toward having a strong relationship between development and test.
When developers trust testers, they will treat testers as an authority on testing and user experience. If a tester is good at his or her job, developers will hold the mental model of the system in their minds—both the code and how humans interact with it.
Developers will make space for your concerns in meetings, in stories, and in tickets. You'll start to see your concerns brought up by other members of the team—as a tester, this can look like someone asking "Is this testable?" in grooming. As a developer, your tester will start to give you the benefit of the doubt and approach your concerns more kindly.
These relationships take time to nurture and develop. They don't happen overnight and they don't happen if you aren't in a place to put the work in. But when you can, do that work. Build those relationships, and shore up the ones you've got. After all, a company is no more than a set of productive relationships.
Want to know more about how to improve your dev/test relationships? Come to our talk at Agile Testing Days USA. The conference runs from June 23 to 29.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
