It’s not flexibility, can-do attitude, or patience. These are all important, of course, but there is one that stands out above all — diplomacy!
Here’s a succinct definition:
the art of dealing with people in a sensitive and tactful way
Given this definition, we can argue that diplomacy is a perfect blend of the most vital soft skills a tester should have:
- Communicative: a project has many stakeholders — technical, sort of technical, and not technical at all. So you have to speak at least three different languages with each group. Developers, managers, users, automation engineers, other testers — all speak using their own jargon.
- Empathetic: developer needs != business user needs. Not only do stakeholders speak “different” languages, but they also have different perspectives and sometimes conflicting interests. We have to learn to be on everyone’s side, no matter how paradoxical it may sound.
- Tactful: not just reporting issues, whether in requirements or software, but doing so without being arrogant or “I told you so” attitude.
Diplomacy is interwoven in nearly everything you do as a QA professional: bug reporting, emails, meetings, 1-to-1 conversations. I see developers as the most important stakeholders for both test analysts and automation engineers, and so this article highlights four key diplomatic actions you should start doing immediately.
1. Make personal commitments to the developer
In his superb YouTube lecture on testing, James Bach says that he tries to “charm” developers by giving them a piece of paper with 13 commitments.
I recommend watching the entire lecture, but here’s a shortened list from 1h 31m 17s:
You don’t have to use this exact wording, and you can phrase it any way you like, but the message you should deliver is clear
“I am on your side, I am here to help you, and I shall do so to the best of my ability”
Try to sit down with a developer over a cup of coffee, chat, and try to get this message across. They are important, and you’re here to help them. When you do so, you’re being communicative.
2. Make a simple diplomatic suggestion
QA people are the bearers of “bad news” — we find bugs and this means developers have more work on their plate. But you can frame it differently and turn “bad news” into “good news”.
Here’s THE sentence that helped me build a smooth relationship with 4 out of 5 developers, especially in 1-to-1 conversations:
“I just wish for us to find and fix bugs in QA environment and not in production”
There are three important things to unpack here:
- “us” — place yourself and the developer in the same team. “You” and “I” are unnecessarily divisive. You want to minimize any kind of division. If possible, sit at the same desk by their side as you say this, not opposite or across the table. It may not be possible with an increasing trend to work from home, I get it.
- “find and fix” — even though we all know who will do the finding and who will do the fixing when it is used together with “us”, it sounds more like teamwork. (and it is!)
- “and not in production” — have you ever met a developer who is keen on fixing prod issues late in the evening under severe time pressure? Me neither. That’s something any sane person wishes to avoid. And YOU just made a suggestion to prevent this highly stress-inducing activity.
You may have stated the obvious, but it helps! You just reminded them that you are here to help them do part of their job (bug fixing) in a less stressful situation. You are being empathetic.
However, there are two things that reduce the value of the above statement and the strength of the impression that it makes: bug-to-noise ratio and bug report quality.
3. Your bug report is your diplomat’s face
The nice diplomatic things you say must be backed by high-quality work. Your promises must not ring hollow.
- Bug-to-noise ratio: do investigate issues properly before writing up a bug. Consult with the developer beforehand if necessary. Why? You keep a decent level of competence and trustworthiness when you report at least 4 valid bugs out of 5. We all report duds sometimes, that’s OK. But if it’s the opposite, and over half of what you report turns out to be invalid, then why should developers waste their valuable time paying attention to you and your non-issues?
Once I had a streak of reporting several non-bugs due to insufficient domain and SUT understanding, and I felt quite worried that I’m damaging my reputation with the developers. I reassessed what I was doing wrong and improved. I also had an informal conversation with the developers and explained what led me to make those mistakes. I openly admit that I am a fallible human being and I will try harder next time!
2. Bug report quality: you might report only valid and critical bugs, great! But if your reports are short, vague, and don’t have the usual useful information, then you are making developers work much harder than they should.
Your bug reports should contain, among others:
- A clear description
- Link to relevant requirement section
- Steps to reproduce
- Expected vs. actual result
- Reproducibility (100% or randomly occasional?)
- Relevant log snippets or screenshots
Each missing point from the above means more effort for the developers. And who likes to spend more time on a task than necessary? Make it easier for them to accept and process your bug.
“If you’re a diplomat, then your bug reports are your diplomatic face*!”
*Especially if you never personally met the developers who read your reports because they are located in a different office.
4. Check your ego at the door
Ego ruins professional relationships real fast. Don’t be arrogant and don’t be condescending. Especially after you made promises such as “I am here to provide a service to you” and “let’s work on quality together”.
There is one area where you should monitor your Ego very closely — rejected bug reports.
“How could they?! I’ve spent an hour figuring out how to reproduce it, writing up a report with all the details and screenshots!”
It’s human to feel this way sometimes. However, it’s not a good idea to do any of the following:
- Reopen the bug without any comment
- Reopen the bug with a non-constructive comment (“THIS IS A BUG!”)
- Escalate to management
Doing any of the above is being the opposite of tactful. It’s a lose-lose! If you’re wrong, you won’t look good for insisting on the wrong thing. If you’re right — you just made someone else look bad! And they won’t like you for it.
You may decide not to raise this issue at all if it’s relatively trivial. You did your job and reported it, it wasn’t accepted, you remember that you should pick your battles and move on.
But you may be sure that you’ve uncovered a serious flaw and you need to fight for it. The best thing to do is to try and talk to the person who rejected your bug in private (chat or face-to-face, which is always better) and try to convince them to reconsider, because reasons A, B, and C! If they accept your reasoning — they will reopen the issue themselves and won’t lose face. And if they refuse — then respectfully state that you will ask other stakeholders for a second opinion. Now you’re being tactful!
- Being diplomatic isn’t easy, but it’s oh so worth it!
- Continuously remind developers that you want to help them, not criticize them
- Write high-quality bug reports if you wish to be taken seriously
- Be tactful. Don’t make people look bad. Help them look good!