Early in my career, there was a line I’d use in job interviews that the interviewers seemed to respond to pretty well; “If I’m having a good day, the developer is probably having a bad day.”
Some would laugh, some would nod, but oddly no-one ever pointed out that actually, it was a horrible statement. I cringe when I look back to those interviews. Not just at my dumb statement, but also at how people ate it up.
No-one does their best work out of fear of criticism. People do their best work so they can be proud of it, to feel like their hard work was worth it, and that people appreciate the effort they put in. When I’m writing one of these blog posts, I’m not focusing on the errors that Jane, the proof-reader might find; I focus on the experience of the reader at the other end. If, after I had submitted my first article, she had berated me for every little spelling and grammar mistake, my focus would have been on avoiding the criticism, rather than writing something worth reading. In fact, had that been the start of my writing career, I can’t imagine I’d still be writing these blogs at all. The reason why Jane knows not to take such a negative approach is because we’re trying to achieve the same goal, which is to produce an informative, and hopefully entertaining, piece of writing. In the same vein, a tester and a developer are also trying to achieve the same goal; to produce a good piece of software that’s a pleasure for the user to use.
Defeat a Toxic Dynamic
Historically, there has been a culture where developers and testers work as opponents, using terms such as “chuck it back over the fence” as if we’re feuding neighbours rather than teammates working to the same objectives. The origins of this toxic dynamic potentially come from methodologies like Waterfall where the development and testing of the software are cleanly partitioned. Meaning, that when the tester is looking at some functionality, the developer that wrote the code has moved on to other things.
This means that when bugs are inevitably raised, you’re forcing the developer to go back to something they may not have worked on in weeks, maybe even months. Imagine how frustrating that’d be if you’re in the middle of something new and you’re in the zone making good progress, then you get a notification that there is a problem with the code you wrote ages ago and now you have to stop what you’re doing to fix it. On top of maybe not knowing the code as well as you did, you might not be as familiar with the requirements now or remember the reasons for making the decisions you did. This makes talking about the bugs more difficult too and raising tensions further. In a perfect Agile world, this shouldn’t be an issue, but let’s be honest here; the perfect Agile world doesn’t exist. It’s often not possible, or even practical to test something immediately after, or even during its development.
Talk To Each Other
So if this is the problem, what is the solution? In my opinion, it’s one word: communication. Yup, surprise surprise in a blog about diplomacy, I’m suggesting the solution is to talk to each other!
For every user story or requirement you pick up to test, just talk to the developer about it. Ask them how it’s gone, how they’re feeling about it, and ask them to show you the work they’ve done. Compliment them on the things they’ve done well, ask questions about the technology they’ve used and the decisions they’ve made. Ask if there are any areas they feel they’ve had the most problems with, or are the highest risk. Then when you find a bug, talk to them about that too. The best-written bug report in the world can’t compete with a quick conversation, and maybe a demonstration of what’s happening, what you were expecting and why you were expecting it.
Same with if there is a comment or an email that you don’t agree with or understand. Have an actual conversation with the person rather than falling into a game of Jira (other services are available) tennis. Don’t fall into the trap of going back and forth endlessly when a face-to-face (or video call if you’re not in the same building) conversation could clarify the situation much faster.
Doing all of this not only saves time, but also helps to build a bond and understanding between yourself the developers you work with. Doing this will reduce so much of the tension that can often occur, while also likely resulting in a better end product.
Diplomacy isn’t just about being nice; it’s about developing stable working relationships and shared priorities. It’s about respecting each other’s work and ideas and being able to put egos to one side for the benefit of the bigger project.
In a nutshell, it’s people being respectful to each other, being nice to each other, and generally just being decent folk.
In essence, can’t we all just get along?