On sandwiches and QA feedback

I’ll confess something, back in time I graduated as a Legal Psychologist. What the hell is that?, it doesn’t matter much, all it means for now is that I know a little about human interactions and my experience, along with my academic research has taught me that humans don’t like others to mess up with their ego. Collaboration in a corporate setting can get rough if people get their feelings hurt, mostly because their work has been criticised. 

So, you can guess how a hell of a quest it is to hold a QA position and keep the waters smooth (both at the same time). Being the bad news bearer really poses a challenge when it comes to push product improvements forward specially because, if you are not a sociopath, it’s pretty obvious that it’s easier to dismantle something than building it (now, graceful dismantling is another story). 

So, being a QA engineer, how do you report defects to developers that put all their love in a project without eroding your relationship with them? Here’s how I approach bug reporting at a high level. 

Why care at all about diplomacy?

First let’s answer a critical question: Why would you even put extra effort in making bug reporting more appealing? As a QA specialist, you can make a strong case about the fact that you already did what you were supposed to, which isn’t either easy: to spot ways to improve a product. In my opinion, it’s also a QA’s job to take care of their relationship with devs. 

QA is probably the role that undergoes most friction in an IT department and things can get ugly if a QA is not able to handle it. It is their responsibility, in my opinion, to foster in devs a perception of allegiance to their work, not only because it will be essential to push improvements in a product, but also because it’s in QA’s best interest to do so. I’ve been continually told that QA is the scapegoat of IT’s mess-ups, which might hold some truth, but after watching carefully what happens when people’s feelings are taken into account, I can claim that not only that’s not necessarily the case but also that devs will help you do your job better. Now this doesn’t mean that you have to bring doughnuts to the office everyday and give the team palms on their backs constantly, but there are little things that can really make a difference between QA-ing the rough way or the smooth way. 

Want a sandwich?

There are several realms in which you can make a difference using diplomacy but I’d say the most critical one is bug reporting. Think about it: you’re a dev and you are laying back on your chair sipping some coffee after coding brilliantly, almost heroically, but ah, there it goes again, that notification on your inbox: another bug has been opened because that little prick from QA wants everything to be damn perfect. Now, this scenario is already not super good, your work has been rejected by another person who probably doesn’t even know how you did it. How would you like the content of that notification to be? Let’s make a difference. 

The “Sandwich Technique” is a feedback approach I learnt while I was mentoring in a security course because I had to review students work. It has received quite a bit of attention by team leaders, teachers, and psychologists alike but it’s often overlooked by many people in the corporate setting. It’s made up of three basic steps:

1 – Start with something positive

Once you create the bug report, just write something nice!  It will take you no time and the person reading it will approach the bug in a much more positive way than if it’s just laid out abruptly. Regarding to what you should say, there’s no hard rule, it can be whatever you estimate that will be likely to put a smile on the reader. 

The reason to do so is because, although the reader might not know it, his brain will process the bug and its reporter in a positive way right from the start. The first lines of a text trigger what is referred to as the primacy effect. This is a cognitive bias by which humans tend to recall better what it is said at the beginning of a speech (and its associated emotions) than what comes in the middle of it. 

So what I usually do after I find a bug is to create the report in Jira (you may be using a different bug tracking software), and put a descriptive title avoiding negative words such as “fail”, “defect”, etc. In the description I start right away mentioning something about the task that did work as expected or just writing some encouragement words such as “nice job!”, along with some emojis. Don’t disregard the power of emojis; as childish as they might seem at first glance, emojis do add a lot of context to text, and we should use it to communicate in a more human way. 

2 – Describe the bug in a neutral way

After starting with something positive, explain clearly what’s wrong with the code. Be clear and concise, devs will appreciate it if you provide them with all the necessary data they need to trigger the bug and troubleshoot the issue. This shows that you’ve taken a bit of care in making their job easier. 

As with the bug title, I’d try to avoid words with negative connotation and describe the bug in the most neutral possible way. You could say that here you will be writing almost in an academic fashion since here we’re more concerned with the accuracy of the events you write rather than people’s feelings. Now, that’s not to say that there’s no room to approach this section in a positive way: often times, something as simple as rewording your sentences to avoid a negative tone makes a big difference.

3 – Finish with something positive

Wrap up your QA feedback with something nice. You’ve started positively and also described reliably why you cannot pass forward the dev’s work this time. Your job is pretty much done, why say something nice again? Technically this adds no further useful information, nothing that can be valuable at first glance. However, this is not about actionable information, this is about fostering a climate of allegiance. It’s a long term investment. 

Similarly to the first lines of a text, the closing of a written piece influences the way the reader approaches the bug as a whole. In this case, this triggers the recency effect, another cognitive bias by which humans tend to remember better what was said at the end than at the middle of a text. 

Therefore, here you can drop a line or two just thanking the developer for his time and patience or congratulating them for their good work on the parts that worked as expected. 

Conclusion

What does this do altogether? Combining both the primacy and the recency effects and framing them positively makes people approach bug reports in a more open fashion. The reason behind this is simply that nobody’s feelings got hurt because feedback was communicated in an empathic way. This will be truly beneficial for QA specialists since will make friction with other team members less likely to arise in the future. 

I hope you found this article interesting and that the “Sandwich Technique” inspired you to rethink the way you approach communication with team members in the work place. See you in the next post!