Originally posted on my blog:
https://www.dowen.me.uk/it-works-on-my-machine/
So, you just found this great bug and it's returned "cannot reproduce", or you have been told "it works on my machine", classic right?
As a tester, in this situation, it can be easy to get defensive. Am I being told I am making it up? Am I being disrespected, why should I raise bugs if they are not important enough to fix?
My suggestion, turn this on its head and consider this for a moment. Time to get technical! What details can be added to help identify the root cause of the issue? Can you do more investigation and help understand what is different between the environment you tested on, and the one the developer tried to reproduce it in?
Ways you could add value in response to "it works on my machine" in include:
- Identifying the exact build or deployment you observed the issue on, and check is this the same build the developer is checking against? Can you check the build they are using, maybe the issue is already fixed, but you haven't been given the latest code?
- Identify what platform are you both using. If it's web, make sure to check not only the Browser but the version of that browser. If it's mobile, what version of Android or iOS is installed?
- Is there any additional logging you can get to help add context? If you can find an exception being thrown that is captured in a log, this can go a long way towards helping identify the issue.
- If you can continue to reproduce the issue, can you give the developer access to your machine or environment? If you are remote, can you set up a screen sharing session? At a minimum, it should be easy enough to capture a video of the steps. for this, I use Open Broadcast Software Studio https://obsproject.com/download, but many alternatives exist.
- If any of these have helped get to the root of the problem and get the bug fixes, try and use them more often in your usual bug reports, and see if you can reduce your "Works on my machine" count.
I hope my thoughts on this are useful, I am really interested to know if you agree, disagree, or even better have additional hints and tips! if you do, please let me know on twitter: https://twitter.com/dowenb
Top comments (3)
The developers' team is always on the defensive mode with the QA and that the relationship between both works well depends on the context of the situation. As a developer, it has happened to me, however, I believe that we should always try to find solutions to problems and not resort to the typical phrase "works on my machine".
One thing I believe that helps without much bureaucracy is having the QA as part of the team itself.
Frequently we see a QA Team that is responsible to test code from other Dev Teams.
What I really like is a cross-functional team that includes a QA inside it. This improves communication, ownership, empathy and avoid "passing the baton".
indeed, this is generally the way I've worked for a number of years. It still has not stopped me having to spend a fair amount of time dealing with the underlying causes of "Works on my machine". But it has meant a more friendly and collaborative partnership with the Dev's while I do it.
For all but the most basic websites, environment/platform are mostly non-trivial and can easily throw up the unexpected difference from running locally or in a Dev env vs "Test/UAT/Prod". And I've used docker extensively, it just means the discrepancy is hidden in some .yaml configuration :)