Sometimes in testing, you spot something that’s not exactly a bug, but it doesn’t sit right either. It makes you pause and think “What’s going on here?” These moments are worth sharing, but how you share them can make all the difference in whether your team leans in with curiosity or misses the value in what you’ve spotted.
Here’s a small activity to help you practise framing those findings in a way your team can act on.
The Task: Share a surprising finding
Think back to a time something didn’t behave as expected. Doesn’t have to be a bug, just something that made you go “eh?”
If you don’t have a real example, imagine a scenario like:
"The password reset option on a login form only appears after three failed attempts.”
Write a short message (3–5 sentences) you could send to your team to describe what you noticed.
You might find it helpful to structure it with SBI framework (Situation, Behaviour, Impact) :
Situation – Where/when you saw the behaviour
Behaviour – What actually happened
Impact – Why it stood out or might matter
Reflect on your message by answering the following:
What tone did you aim for?
Who did you imagine your audience to be, and how did that shape your message?
I run into these occasionally and a lot of times, it’s functionality that is hard to replicate.
For example, things that appear or do not appear when I’m expecting them/not expecting them.
Example message to the team:
" Hey there! I’m noticing what I think is an issue but I can’t exactly tell and it’s hard to reproduce.
(Here I include a video of what I’m seeing. Visuals help)
Steps to Reproduce (If I can decently reproduce it but I’ll be honest when I can’t reproduce it always)
Login with username and password
Navigate to the profile
Sometimes my name appears correctly and sometimes it’s appearing as [insert weird behavior here]
I’m using Chrome (or whatever browser) and I’ve tested it across all the other browsers. Seems to be only happening in Chrome."
Reflection
Sometimes it’s user error and the user is me and I need to make sure that it’s not only happening to me.
I try to communicate the things that bother me early because 1) someone else might have seen this but they might have dismissed it also and 2) if it’s documented early, we have a timestamp of sorts of when the issue started showing up.
I use emojis because it’s eye catchy. Yes, the red flag could feel extreme to some. Another option could be the to represent a code smell
My audience is to the team working on the feature. This could be anyone from developers, product managers and designers.
Sometimes, a developer will go after it to figure out why it’s occurring. But, a lot of times, if the issue is really an issue, someone will bring it up later and I can circle back to my post and we can discuss next steps to document and fix the issue.
I try to avoid any type of language that could create blame. I don’t talk about who worked on what. I talk about the issue in the application and when it started happening.
Well, I’m going to break all the rules and just give a short answer that doesn’t follow your requested format because I think it would be hard to jam into that format.
Sometimes the most effective approach is to not say anything at all other than “hey, can you take a look at this?” I’ve had a developer say “yeah, that’s a bug” over my shoulder without having to point the specific behavior out at all!
often, this is the more polite way to ask for a second pair of eyes on something. And if the developer thinks that they have spotted the actual root cause bug, then not only do you not have to play bug-tennis, but they think they are awesome at bug spotting, and thus more likely to fix it soon.
But yeah, this is often a problem for me to bring up in a way that does not ruffle feathers, not just you @scottkenyon .
Nice framework.
I do it by setting the scene with all stakeholders, that all unexpected behaviour will be logged (usually as a bug, defect, or incident). The ticket can then be managed as part of the normal process. I find that this encourages the team to bring their own experience into testing and not just comparing to the requirements and helps with the discussion of behaviour. More importantly, it has helped ensure that ‘odd’ behaviour does not slip through the cracks. Where this has caused a problem is if you are counting defects, it pushs the numbers up.
Hey there! I’m noticing what I think is an issue but I can’t exactly tell and it’s hard to reproduce.
I’m using Chrome (or whatever browser) and I’ve tested it across all the other browsers. Seems to be only happening in Chrome."
to represent a code smell