"I can't find the issue, this is working on my machine."
As a tester, you probably have seen this message on a closed ticket more times than you'd like. I know that throughout my software engineering career, I've admittedly used similar phrasing to address bug reports, usually because I couldn't replicate the reported bug and had a dozen other tasks competing for my attention. I'm not justifying my actions, but I know that plenty of developers share similar mindsets, and it's incredibly frustrating for the QA team to see this happen to their bug reports.
Unfortunately, I don't expect this behavior to stop anytime soon. Development teams will always feel under pressure to build new functionality and prioritize these tasks over fixing bugs. Some developers also think a little too highly of themselves and refuse to believe that they introduced a defect in their carefully crafted code. It's also the unfortunate reality that most organizations don't fully value QA, dismissing this valuable work and instead focusing on the more tangible work of software engineers.
If you're a tester, does that mean that you should just throw your hands in the air and give up? You shouldn't. Although you might not eliminate the "it works for me!" attitude entirely, you do have the ability to reduce these situations before they turn into a deep-rooted problem that will suck the life out of any software project over time.
Take a Closer Look Before Submitting That Ticket
One way to begin shutting down dismissive closing comments on your tickets is to double-check what you write when opening one. I can't tell you how many bug reports I've received that contain vague details with little else to support them. There's no information about what led up to the error, the circumstances that triggered the issue, and so on. Some bugs may seem easy to fix, but many occur under a specific set of circumstances that aren't readily apparent for someone else to reproduce.
As an example, let's use a hypothetical bug report that I've seen plenty of times before:
Sure enough, I run a test on my local development environment and everything works as expected. I try a couple of more times, and each time I can create a new widget without a hitch. Let's see some details missing from this bug report that can shine some light on the issue:
- What data was entered when the bug happened? There may be missing information in the widget form, or some of the input may be triggering a backend validation that the app is not displaying on the frontend.
- Where is the bug happening? Knowing whether the bug occurred in production or a test environment can narrow down the possibilities for where the developer should check.
- What device/browser/operating system/etc did this bug happen on? Many applications behave differently on different systems, and a bug that occurs on a specific mobile device may not appear on other devices.
These are just three details that come to mind, which would drastically improve my chances of finding the culprit. The more information you include in your bug reports, such as screenshots and error messages, the higher the likelihood of getting that bug fixed quickly. Another tip is to include those details directly in the ticket instead of linking to external pages, since many won't bother to click on them. Even seemingly irrelevant details can lead developers straight to the root cause, and having it all easy to access removes any excuses about not having all they need to work on the problem.
No More Working in Silos
If you work in a company that focuses on software, there's a pretty good chance you have completely separate development and QA teams that rarely interact with each other. I've never understood this clear divide between developers and testers, since the final product heavily relies on inputs from both sides. Regardless of the reasons behind the isolation, this kind of separation creates an environment where it's acceptable or even encouraged for developers to dismiss QA concerns.
Still, just because there's an invisible line between development and QA in your workplace, it doesn't mean you can't "cross the line". That means reaching out to development outside of Jira or your preferred issue-tracking software and working together, rather than having each side throw work over a wall and hope for the best. Unless you're a tester in a toxic workplace (in which case, try to look for another job), spend some time pairing with a developer on urgent or tricky issues and work together to figure out what's going on.
As a developer, I've always appreciated the moments when I have worked with testers to get to the bottom of an issue (although I might be an anomaly in this case). I can have plenty of blind spots when deep into development work, and the critical eyes of QA help me see things I missed. Having direct contact with developers might be able to show the problem more clearly than a bug report, or you might realize that what you thought was a bug is actually a feature. Whatever the result, these moments provide closure on both sides instead of leaving an ambiguous hole of uncertainty.
Send a Signal to Stop the Behavior From Spreading
Sometimes, you might notice a pattern of "it works on my machine" coming from the same developer or even across the entire development team. Once you start seeing this and you're sure they're being dismissive about the QA team's bug reports, it's probably time to escalate the issue. It sounds like you're throwing someone under the bus, but if it's affecting the work of QA, someone needs to address a potential systemic problem that can rapidly corrode the team's morale and ability to do their best work.
Reach out to your QA lead, tech lead, or the person who manages the relationship between the development and testing teams regarding the situation. Pointing out a potentially faulty process can help them identify where to begin addressing problems, whether it's a technical issue, such as inadequate test environments, or a cultural issue that has developed over time within the company. You'd be surprised at how many higher-ups are not fully aware of the problems happening on their teams until something explodes. Tech and QA leads will also likely have better insights into what's causing a bottleneck, like a sudden spike in the team's workload because someone quit and they don't have the resources to find a replacement quickly.
The key here isn't to begin pointing fingers and placing or deflecting blame all around, because that will only lead to unnecessary drama and strife that makes the situation a lot worse. The right approach to this is to consider it from a standpoint of curiosity and how you can help. Instead of saying something like "Dennis keeps on dismissing my bug reports without checking them!" (which may or may not be true), you can say "Can I do something to make these bug reports better?" or "How can we ensure that we're all using the same test environments?" Leadership will do more to improve the system when you talk about solving problems instead of shoving another crisis onto their plates.
Sometimes It's Better to Do Nothing
You've written detailed bug reports, you've reached out to collaborate directly with developers, and you've escalated the issue to your team leads. If there's no visible change by this, you might have reached the point where you need to accept that you've done everything within your control. It's not a fun feeling, especially when you know that your ignored bug reports could impact the quality of the product. Sometimes, the best thing you can do to avoid your career from being affected is to take a step back.
However, taking a step back doesn't mean doing nothing. At this point, documentation becomes your most valuable asset. Keep records and evidence of the times when the development team dismissed your work. Screenshot whatever you can, save chat and email threads, and keep a general timeline of the work you do. When that bug you reported inevitably surfaces later in production, no one can tell you that you didn't do your job correctly.
I know it's a crappy way of dealing with the problem, but some battles aren't worth fighting, and you can't force others to care about quality as much as you do. When you've fulfilled your responsibilities by reporting bugs and trying to help resolve any issues stemming from that, the ball is in their court and out of yours. Focus your energy instead on improving the overall quality of the project, rather than trying to change something that clearly isn't going to change by your hand anytime soon.
Wrapping Up
Having your bug reports shut down with a single "works on my machine" comment isn't going away, but you can take some steps to reduce the likelihood of it happening. Taking the time to write detailed bug reports, bridging the gap between development and QA, pointing out patterns of dismissive behavior to higher-ups, and knowing when to take a step back can chip away at the frustrations of having your hard work ignored.
These steps shouldn't be limited to testers, as developers should also take an active role in eliminating any negative attitudes across team boundaries. The important thing to remember is that your role as a tester is incredibly valuable, even when others don't always recognize it. While you can't control how others respond to your reports, you can control how you handle these situations. Continue advocating for quality in your organization, trusting that your skills will prove their worth when the project is completed without any issues.
