As a junior QA, I learned quickly that not every developer liked the type of bugs I found. Some bugs existed years before I discovered them. Others were incredibly tricky to reproduce. I joked that I needed to keep a pile of lollipops at my desk for whenever the devs walked over to my cubicle to ask for a demonstration of the bug I’d written up. It’s hard being told that something isn’t working. Sometimes, a little candy goes a long way.

After years of testing, I realized that QA is more than merely verifying if a bug exists. Quality is about zooming out and assessing all types of feedback loops. This could be a process, meetings we participate in, reports, or bug intake forms. Evaluating our feedback loops can help us discover if we’re getting the type of effective feedback that we need to make clear decisions.

Of course, I’m not talking about actual candy. For this purpose, we will use the CANDY heuristic to help teams provide fabulous feedback to each other, and ourselves. 

🍭CANDY is feedback that is always:

• Clear
• Actionable
• Neutral
• Directional
• Yarely

➿ First, let’s define a feedback loop.

Feedback loops 

TechTarget defines a feedback loop as the part of a system in which some portion (or all) of the system's output is used as input for future operations.

In simpler terms, a feedback loop is any information we receive as the result of introducing a system into our organization. Common examples of feedback loops:

• Automated test results
• Refinement sessions the team participates in
• Bug reports
• Feature request
• Error logs in production

Feedback loops are imperative, and structuring them to provide accurate information is crucial when making decisions based on the type of information any one person or an entire team receives. We don’t want to make decisions based on insufficient feedback. We want fabulous feedback.

To create a culture at large where quality is everyone's responsibility, I think we need a little joy. And, what is more joyful than candy?

CANDY acronym

• Clear: 
  • The feedback received is not confusing. The process is documented, accessible, and maybe pinned to a Slack channel. The Steps to Reproduce help identify where the code is breaking. The report gives us the courage to release or the wisdom not to. Whatever we are using and what we are saying, what is being communicated is clear and understood by everyone.
• Actionable: 
  • The team member who finds the bug knows how to report it. The engineering team knows how to fix it. The Acceptance Criteria are understood by the developer working on the feature.
• Neutral: 
  • There is no blame and no ego when it comes to great feedback. If something is bad, we fix it. If something is good we celebrate it. The team doesn’t mire in finger-pointing. No one person is responsible for a successful feature. We all play a part and we honor each other in the process.
• Directional: 
  • Time spent with team members feels valuable. When a person speaks up, they receive the help they need. There isn’t a need to micromanage because everyone feels safe to discuss next steps.
• Yarely: 
  • (Y words are hard, okay??) But, seriously, Yarely is the perfect word. Its root “Yare” means ready. The feedback prepares the team for the next steps and the team is nimble enough to pivot with the new information.

Are you drooling yet? 🤤 Me too! But, in order to receive fabulous feedback, we need to consider our mindset. It’s not easy to take in a ton of CANDY.

Lessons learned 

Here’s what I’ve learned when both giving and receiving effective feedback:

• Assume the best of those around you. Unless you’re working in a very toxic environment, the majority of people care about what they do for the organization. Assume that people are doing the best they can with the information they had at the time.
• Be willing to hear the hard things. The truth will set you free but Truth can also punch you in the gut. Realizing that what the team built is not what the stakeholders hoped for is hard to hear but it helps us make better decisions.
• Be willing to speak up. Many times a thought will pop up in my head and it doesn’t “feel” important but the question will bother me enough that I want to ask it. Ask the question anyway.
• Be honest about the tools we’re using. Is it giving us the type of effective feedback that we need to make good decisions?
• Be willing to rock the boat. With the assumption that people are doing their best (circle back to the first point), ask why we added a particular type of feedback. The answer “We’ve always done it this way” may not help us grow into what’s possible in the future.

Using CANDY in the SDLC 

With this framework, let’s look at points in the SDLC (software development life cycle) where we can add some CANDY. 

The basic cycle:

Typically, we expect to receive feedback in two places - on intake, the feature request or bug report, and in the testing phase. The practice of Shifting Left and Right reminds us that we can offer feedback throughout the entire Software Development Lifecycle. However, depending on the processes in place, we can’t be certain we’re getting the type of feedback we want. Patrick Prill details this well in his post: Having a process doesn’t mean you get good or consistent results.

Where else can we add some CANDY? 

You probably know where I’m going with this…

🍭 What about deployments? Are our error logs clear? Do we have error logs? What do they tell us? Who has access to that information and can they get to it quickly?

🍭 What about the Design phase? Is accessibility discussed? Do you know what tools exist to check for accessibility? Can anyone speak up in the design phase and advocate for any type of user?

🍭 What about Bug Reports? Are they clear? Can anyone write them? Is there a guide on how they can write them in a way that gives developers a clear path to finding the bug? How are bugs reported? Is there a bug board that is assessed often by the appropriate parties? Who are the appropriate parties?

You get my drift. Zooming out can almost feel like you’ve walked into a candy store and regardless of how excited you are, you only have so much money and time. This is also true in the SDLC. You are operating on limited resources. Your organisation has a roadmap, stakeholders, and various pressures that drive development.

Challenges

So what can you do when you feel so limited?

• Start the conversation and be willing to take the first step. Sometimes, it’s enough for someone to ask, “Is this process working for us?” Hopefully, others will join the conversation and from there, be willing to take that conversation to the next level.
• Look for the small wins. What domain do you have a decent amount of say in? Is there a package that needs updating in the software that you are familiar with? Bring it up in the engineering meeting and take ownership of it. Talk through the scope and how achievable this action is. Point out the benefits of this change and what will be available to the entire team after this update.
• Create a spike ticket. Maybe you aren’t sure what the benefits will be if you switch to a different tool. With the buy-in from your team (if possible) create a spike where you can do the research and see what changes are possible. Discuss the results with your team and weigh in on the value of the change.
• Offer what you can with an open hand. This is a hard one. Not everyone will like your ideas and that’s okay. Try not to take a rejection personally. However, if every idea ever is shot down by the team, consider that your stress may not be coming from the work you are doing but from the environment you are in. That in itself is a feedback loop. Make decisions accordingly.

As we begin taking action on what could be changed, it’s possible that you might face some pushback. Not everyone may like the actions you are taking or even why you are choosing to take a process or a task in a different direction. At this point, it’s good to identify who your stakeholders are. In my opinion, it’s the people directly working with what is being changed that you should care the most about. Others may want to do things differently, and if they are directly impacted with the changes you are suggesting, take that into account. They may have valid reasons for keeping things as they are. Listen to them and communicate that you want to help them and that you are working to make their job easier. 

Others may have opinions that will not be affected by what is suggested. I think it’s safe to put aside someone’s disappointment about a suggestion or a change if this doesn’t affect their day to day work experience. You won’t be able to please everybody. Not everyone will agree with our decisions. So we need to decide who we are willing to disagree with. This could change depending on the type of feedback loop, the parties assessing the feedback loop, and who the direct stakeholders are. It could even be down to who has the authority or control. Being willing to disagree with someone to make a clear decision is a critical skill. Define your values, assess your feedback loops, and be willing to disagree, knowing that you are after a specific type of outcome.

To sum up

Getting fabulous and effective feedback is worth it and it doesn’t have to be rare. If we are willing to ask questions, discuss options openly, and be willing to change what’s already in place. You might find yourself bringing a lot of value to your teammates and having a bit of fun in the process.

Did you have some CANDY this week?