Continuing my journey through the MoT Software Testing Essentials Certificate, there is a section on feedback, both giving and receiving, that caught my attention.
Feedback is a gift in nearly every circumstance. One of the worst things that could happen in life is never receiving feedback.
For instance, I got braces for my teeth last October. I’ve instructed every member of my family to tell me if I have something in my teeth. Eating is hard. Worse is not knowing there’s something stuck in there and learning about it later. My teeth are a work in progress.
So are we.
As QA professionals, we need to be able to give and receive clear and actionable feedback. When we signed the contract, we were given the role and the right to deliver feedback. Sometimes, that feedback won’t be good. We’re the ones pointing out who has what stuck in their “braces”.
How you deliver feedback to your teammates can make all the difference.
Know your audience
Cross-team discussions
These days, I post in the organization’s public project-specific channels to provide updates on the feature being tested. Knowing that my posts will reach different types of team members across departments, I provide a concise summary on the status of what’s been tested, what remains, a link to the report where everyone can view the test cases, and a list of defects found. Those interested can view the resources at any point. I do use emojis because these help (in my opinion) make the post more readable and relatable. Though it may depend on your work culture. If emojis are frowned on where you work, refrain from using them in more public settings.
Be ready and willing to answer questions about reports. And, at all possible, avoid DMs. If a question is being asked about a project, take it to the project channel. Avoid the silos at all costs.
What if the feedback I need to give is really bad?
Be honest. Be brief. If you made a misstep or missed something during testing, own it. I’ve apologized in public channels for forgetting something in my test plan. Then I describe what I will change in the test plans moving forward so that it’s not forgotten. Own your actions.
If something is clearly broken, regardless of the environment, take it to the appropriate public channel and alert others. The goal is not to cause panic. The intent is to provide clear information about what is wrong and to alert the right people so that it can be fixed as soon as possible. Avoid using emotional words or blame. There is a difference between:
“Hey, uh, y’all, Jack’s pr broke the login page…”
and
“I’m unable to access the login page. Can anyone verify? If so, what do we need to do to get it fixed?”
Person-to-person
Sometimes, I’ll need to offer feedback to a developer on their PR. Many developers want to know if their code has issues so that when released, the feedback is… crickets. A quiet release is a good release. Even then, when testing a PR, how you say it is as critical as what you say.
Ask how the developer likes to receive feedback on a PR. There could be an engineering practice where all conversations regarding a code change need to be in the ticket or on the PR request. Follow whatever is normal for your organization. If there aren’t any set practices, ask them if they’d like feedback in a project channel, in the ticket, or in a DM. Being able to have open and honest conversations about the code is the goal. Wherever that is achieved best is where it should happen.
Be clear and provide action steps. Again, DMs are fine, but it’s tempting to speak vaguely about an issue. Write down exactly what you are seeing, steps to reproduce, and provide videos or screenshots, as you do when writing tickets. Then, if you need to write an actual ticket for what you’re seeing, all you have to do is copy and paste the information you already wrote down. Easy peasy.
Ask the next question. Yeah, it probably does work on their machine. Be the one who asks why. What is the difference between your environment and mine? Earlier this week, I was seeing console errors while visiting a specific page. A dev asked if I’d pulled down the latest changes. I hadn’t. I pulled them down, the issue was fixed, and the conversation was resolved. They didn’t treat me like I was silly, and I thanked him for giving me more information. Keep it neutral. And, when you need to, keep asking the next question to figure out what is actually going on.
Treat people as they want to be treated. Some people are fine with making the occasional joke about their code changes. Some aren’t. Read the room. I am a light-hearted person. And, I’ve learned that, in hard moments, my light-heartedness can be read very wrong. Depending on your personality, hold back the jokes if you are discussing hard topics. Then, when the conversation turns light again, feel free to be your goofy self.
Find the next step
After having hard conversations, you may need to take a break from the situation. Perhaps everyone does. Hopefully, you’ve been able to have the hard conversations in a non-blaming, actionable way. Or, maybe it went so badly. Either way, take a minute, refresh yourself, and talk to the person you had the discussion with. Find a neutral topic if you need to. Saying thank you is a great way to move on. You can say things like:
“Thank you for talking that through with me. I was so confused.”
“Thanks for being so quick about fixing those issues. That was awesome.”
“Thanks for being willing to take the conversation to a public channel. I didn’t realize others were unsure about what to do next.”
One good hard conversation down. Only a million more to go.
Communication is hard. Being responsible for bringing bad news can feel like a lot. In between those times, be sure to create lots of positive experiences for your teammates. That way, when you have bad news to bring, you aren’t being the Debby Downer. You're the friend who doesn’t want their friend to walk around with something in their teeth.
Till next time…
All my posts are free to read and clicking subscribe will bring each post to your inbox. If my work brings you joy, and you’d like to support it, you can become a subscriber by clicking the button above. If a subscription is not your thing, you can support my caffeine addiction writing by clicking the button below! Thanks!
Written with Happiness is a butterfly playing in the background.
