Forem: Judy Mosley

🗺️ How-To: Create a Bug Report

Judy Mosley — Tue, 25 Nov 2025 17:05:44 +0000

Great! You’ve found a bug! And, wow, is it wreaking havoc! You did your homework. It’s reproducible, you know which environment it’s in, and it’s not been reported because you did your due diligence by searching through the ticketing system (insert Jira, Shortcut, Clickup, etc. here). This means you get the gold bug award.

Finding the bug is only the beginning. Here’s how to create a great bug report.

What Qualifies as a Great Report?

Information. The more details you provide, the faster the engineering team can find and fix the issue. Let’s start with the essentials.

Browser Information: What browser are you using? Does the issue exist in other browsers?
Environment: Was the issue discovered in production? Does the issue exist in the Staging or QA environments? Sometimes the fix is on the way, and you didn’t even know! Is the opposite true? The issue is in Staging but not in Production? Being able to identify which environments the issue is helps spread awareness across teams and prioritize a fix.
Reproducibility: Are you able to reproduce the issue when you follow a specific number of steps? Bugs that are reproducible are easier to find and fix. Intermittent bugs? Not so much.

Armed with all this information, here’s what to include in the ticket:

Form Fields:

Expected Results

This describes the outcome of what should happen when a user takes a specific number of steps through the application.

Actual Results

This describes the outcome that’s actually happening when a user takes those steps.

Steps to Reproduce

Provide a clear numbered list that outlines where you started and what happened. For example:

Navigate to the homepage (include the url: this helps identify the environment you are working in)
Login as a client user
Click the profile icon
From the profile page, click the “Reset Password” link
The user is not redirected to the Reset Password page

Videos/Screenshots

While Steps to Reproduce may be enough, sometimes it’s more helpful to include videos or screenshots of what you are seeing. Providing visuals is a great way to bring deeper insight into the issue.

Notes:

This is where you can include browser information, which environment the issue was discovered, and the version number of the application.

Important Links:

Any conversation surrounding the issue provides context for the engineering team. These conversations can come from the communication tool the company uses (i.e., Slack or Teams) or any other source that creates a shared understanding of the issue and why it appeared.

Smash that submit button.

🤔 Hmm, did I miss anything? What other information do you use in your bug reports to help provide additional information? Let me know in the comments!

Till next week…

Want to support what you're reading? You can support my caffeine addiction writing by buying me a ☕️

👓 Quality Experience: Easy Ways to Introduce Accessibility Testing

Judy Mosley — Tue, 11 Nov 2025 23:54:52 +0000

Testing for accessibility can feel daunting. The first time my Director asked me to add accessibility as a category for testing, I didn’t know where to begin. Considering the high standards for reaching the WCAG 2.1 AAA rating, I felt overwhelmed knowing the site I was testing would not rate well.

After deep breathing and good mentorship from the engineering team, we searched for tools that helped identify fast and easy fixes to make our site more accessible.

First, The Why

Again, Empathy is a fabulous place to begin. My ability to see content on a site page is a variable, not a fixture that every user experiences. I know people who are color-blind or dyslexic. My willingness to see through their eyes affects how I test for users with accessibility challenges. Even if your website looks fine and seems intuitive, don’t expect it to look and feel the same for your entire user base.

Resource: Check out Seren Davies - Death to Icon Fonts

With What?

Thankfully, there are many tools (free and open source!) that support identifying web accessibility issues. For this post, we will focus on a few easy-to-implement options.

Support for users with Dyslexia

Use: OpenDyslexic Browser Extension

This browser extension was an easy add for our QA team's test suite. Listening to Seren Davies' story helped me realize that using the extension would be an easy way to see how the site would look when the browser extension is turned on. I was pleased to learn that our site uses SVGs instead of Icon Fonts. Using the extension, we catch bugs that display when the extension is enabled.

Accessibility for Broader Audiences

Use: WAVE Browser Extensions

Accessibility for users with Vision Impairments

Use: Screen Reader Browser Extension

How does your site sound to those with low vision? For users who aren’t able to use their sight, screen readers are perfect for those wanting to browse the internet. If they found your site, what would be their experience? Turn this extension on and click on different elements to hear what your site sounds like to those using screen readers.

When?

Now. Start today. Add testing for accessibility to your current test plan. No, it may not be the company’s top priority now. Building data, identifying easy-to-fix issues, and showing easy ways to achieve accessibility for many types of users will help create a case for providing a more inclusive environment in your organization.

Recently, I was working with someone from Support. As we spent time troubleshooting an issue, she shared her screen so we could look at things from her perspective.

“Is that Open Dyslexic Font??” I asked.

“Yes! I use it all the time! It makes web pages so easy to read!”

I was so excited to share that we use Open Dyslexic in our test plan. She was excited that someone was looking at the world through her eyes! Exhilarated, I returned to the QA team to report that we were on the right path.

May all your users be this happy with what your team creates.

✅Quick Tip: .wait() a Second

Judy Mosley — Tue, 11 Nov 2025 15:31:12 +0000

TL;DR - Add a .wait()

cy.get('YOUR-SELECTOR').wait(1000).click()

For the past week, I’ve been working on the simple task of automating the click of a tab within a page. This should be simple, right?

//Navigate to the page
//Click the tab on the page
//Click the button that displays within the tab contents

.click() failed to open the tab.

.invoke() set the correct attribute, but the clicked tab contents did not display.

I applied breakpoints to the click action and watched each point in the code that triggered the click.

I added .trigger() and used mouseover, hover, and mousedown

.focus() was added.

At this point, I was throwing everything in my power to click. this. tab.

It wasn’t until I found this answer on Stack Overflow that I found my first clue.

At first, I laughed. Not at the person but with them. My word! We’re just trying to click a thing! Then, for funsies, I applied their answer to my code.

The tab opened.

Happy to find a solution, but wanting to know what triggered the click, I stripped away each part that might not be necessary. Here’s the result:

cy.get('YOUR-SELECTOR').wait(1000).click()

All it took was a second.

I know, I know, as QA Engineers, we stress and strain not to add waits to our code. It’s a code smell. It will slow down the tests, etc. And, that’s correct. But, sometimes, in code and life, all you need is a second.

Hope this helps someone and saves you DAYS of searching.

🙏

Want to support what you're reading? You can support my caffeine addiction writing by buying me a ☕️

🫱🏾‍🫲 Quality Experience: How to Introduce QA Practices to Your Organization

Judy Mosley — Sat, 08 Nov 2025 14:46:55 +0000

🖥️ Whether your tech stack is brand new or teetering with age, any time is a good time to introduce Quality Assurance practices within your organization.

What do I mean by QA practices? For this article, QA practices are defined by specific standards set within an organization that increase the product's efficiency, quality, and reduce communication confusion when bugs or defects are discovered during the development process.

Wait, why didn’t you say “best practices”? I avoid the word “best” because “best” could be applied to any type of practice that hasn’t been verified or fully vetted. It’s a word that’s easily applied but hard to prove. This idea comes from one of my favorite talks by Viktor Slavchev in his talk “‘Worst’ Practices of Software Testing”. This is a recommended watch for anyone wanting to learn about the QA process.

I’ll approach these practices in a more holistic sense. Creating processes that provide clarity and ease of use is more likely to be embraced by those within your organization.

We’ll discuss:

Empathy
Documentation
Process
Mindset

🌊 Let’s dive in:

👂Empathy - “I believe you.”

Creating a thriving QA culture needs to begin with empathy. Our users can be anyone from our clients to the developer building the feature. As unfortunate as it feels, when a developer says, “It’s working on my machine,” that’s absolutely true! Their process and their environment shape their experience. This is true for the end user as well. When a report comes back with a user stating that something is broken, we can fully trust that their process and their environment are shaping their experience. Where communication breaks down is when we take both the process and the environment as truth. These are variables, not elements that can’t be changed. When any user comes to the QA and says, “This is what I’m experiencing”, continue the conversation by believing them. (And, devs, if a QA says that it’s broken on their machine, believe them.) Beginning conversations with empathy fosters conversations of openness and curiosity, which leads to solutions for all users working with the end product.

🗺️ Documentation - “This is the way.”

Each tool a team embraces and the process applied in the SDLC should have documentation around it. The documentation should include why the tool or process is chosen and how it should be used throughout the organization. Documentation should be clearly written, accessible to the appropriate teams, and organized for easy discovery. This also includes documentation that covers the application the engineering team is creating and how it should operate for anyone using it.

Yes, documentation can become stale. Giving teams the freedom and time to update their docs often helps keep them up-to-date and evergreen.

🥾 Process - “This is the how.”

Do your users have a way to report issues? Does everyone in your organization know how to report a bug if found? Creating defined processes for every type of user paves the way for clear communication when bugs are discovered. Who is the person responsible for triaging issues that come in? Do you have channels dedicated to bug reports and status updates? Included are some easy ways to report, triage, and find resolutions for bugs reported:

Create a system for end users to report bugs and make this system clear and available so they won’t spend time hunting your site for how to make a report.
Within your organization, set up a form using Google Forms, ClickUp, Shortcut, or any tool that your team already uses. Again, this form should be easily accessible when a bug is discovered.
Set up specific communication channels that are dedicated to bug reports. To avoid unnecessary noise, limit these bug reports to reports with higher severity levels.

Select specific people in your organization to triage and troubleshoot bugs as they are reported. This can be anyone from the Support team, the Product Management team, or the QA team. Clearly defining who will do this helps keep “too many cooks out of the kitchen” when a bug is reported.

Define when status updates will be given on high-severity bugs. This can be anywhere from 15 minutes to an hour. Lower severity bugs can have an increased time status since the issue may be more annoying than limiting functionality for the user.

🤔 Mindset

Taking a note from Ted Lasso, “Be curious, not judgmental.” When issues appear (in any software or process), it’s easy to start the blame game. It’s much harder, but more helpful to start the problem-solving game. Begin by asking questions - what browser is the client using? What type of device are they using? Is there any event within the tool suite that could be disrupting the use of the application? So many variables can disrupt a user’s experience. Being curious will open far more paths than blaming a team within the organization.

Making these changes within your organization may feel nerve-wracking in the beginning. Choosing to change what’s always been done will create an environment where users can speak freely when issues arise and team members can find and fix what prevents a smooth user experience for your clients.

What practices have you introduced to your organization that have increased efficiency and connectivity with your users? I would love to hear your thoughts.

Want to support what you're reading? You can support my ~~caffeine addiction~~ writing by buying me a ☕️