Hello everyone
I’m a newbie, on this platform as also in this field (Product Management). I had a query and wanted to know how you guys track things. We have an internal tool, and occasionally while the user is using the tool, one or more bugs appear. However, it becomes quite difficult to identify what caused the bug. What route the user took, so that our tester can duplicate the error and fix it. Can somebody explain how you handle this? (Is there any reasonably priced or free tool?)
In the gaming industry where I work, bug management is crucial. Because we accept that not all issues can be fixed and that we must prioritize what needs to be fixed, we refer to bug backlog management as “Bug Triage.”
Engineering can add more logging around issues that are difficult to reproduce but have significant risk or effect so that they can be found when they recur. If it has a minimal effect, poses little danger, and is challenging to replicate… It might be closed as Cannot Reproduce or moved to a later release for retesting.
The secret is to work quickly but thoroughly, and to prioritize problem fixes in our milestone plan. Bugs are almost always present in games, even with competent software because they are often quite complicated.
When we can’t reproduce an issue, we add logging (using Splunk) or stats (using a database). There is a label we apply to the Jira ticket once that has been added. We check to see if these bugs have any stats or logging during our weekly bug review meeting. If there is, we’ll work to appropriately fix the bug. Since some bugs just seem to fix themselves after a month, we stop paying attention to the ticket if there aren’t any.
Unrelated, when you say gaming do you mean casino gaming or video gaming?
I’m a senior PdM and was curious about the latter since it’s something I personally love as well.
@EvaRichardson, I’m in video games. I’ve contributed to games for mobile and PC/console platforms, from midcore games to huge MMOs.
That’s fantastic!
Have you produced something for other industries? Like, it doesn’t seem like games truly follow Agile because I’ve never heard of bi-weekly releases, with the possible exception of some MMOs where they occasionally just stealthily repair stuff and there’s a new, megabyte-sized version to install. Are the Agile ceremonies Kansan?
Additionally, I’ve heard that it’s difficult to work as a developer in the video game industry, so I was curious if your own experience matched that perception.
No worries if I ask a lot or if you’re too busy, I’m simply interested, lol.
Happy to respond! My entire career has been in gaming. Despite the fact that my job title of “Producer” is more delivery-oriented than an idealistic Product role, I interact with users, user data, and the larger market frequently enough to have the impression of being a non-gaming PM.
It’s important to keep in mind that although PM positions are frequently available in the mobile gaming industry, they are nearly exclusively focused on owning the revenue output of a product. This division is intriguing. And those are just the technical, UI/UX features. For instance, there is a multi-milestone waterfall process to ideate, concept, model, animation, polish, add FX, and release a new character or class in a shooter game. Large Gantt charts are incredibly useful when you’re making multiple of those types of updates at once because that can be broken down into iterations or stages but is still primarily a waterfall approach.
Anyway, it’s difficult for games to be truly agile. Here are a few causes for this: Before a final product is ready for distribution, game products may require the creation of several layers and dependencies. Internal CI/CD, internal testing, and internal prototyping are all encouraged, but it may take longer cycles to polish something for external release.
Oh, that makes perfect sense. Although I haven’t really used waterfall previously, I have had to run a few moderately huge Gantt charts on department-wide projects (under odd circumstances, lol).
It’s also really intriguing that a PM in mobile gaming has that split, haha.
I’m grateful. I adore games, thus I think creating products for them might be interesting at some time. I was just really interested in your viewpoint.
Cheers!
This isn’t soley product problem, every tech stack in existence will have obscure bugs in them like this. Your job as product manager is to make decisions around how important fixing these bugs are and which ones to go after.
Obviously log everything but sometimes it just isn’t worth it if it’s obscure enough and low impact enough
Excellent advice @LuisNeilson. Put it on hold until it returns. Consider including bug tracking and detection mechanisms in the scope of this ticket and treating them as discovery.
Additionally, solving it might not be worthwhile. There are usually more essential things to focus on if it returns every few weeks or months with a bearable affect.
We have this great tool these days (that you’re likely already using) called video conferencing and screen sharing.
If nobody else on the team can reproduce the issue, ask the user if they can. If they can’t, shrug your shoulders, tell them to keep an eye out, and go on with your life.
If they can, ask to watch them do it in a Zoom session. Record it. Show it to the team in a Refinement session.
I spent a while working as a quality analyst. Such bugs would be recorded as ad hoc bugs. Describe the problem in detail. In order to avoid testing in the same region where the bug happened in the future. If you are still unable to recreate it after regression testing, you can close the test with the remark cannot be recreated.
The fact that the bug finder doesn’t have to write everything down makes video recording tools useful.
A bug’s discovery and remediation times should be based on the problems it causes. For some users, it is insignificant and difficult to pinpoint. Nuf said. It won’t be fixed, unfortunately.
We put all of our efforts into locating the bug and fixing it, even if it leads to random aircraft crashes or nuclear power plant explosions.
Close as “can’t reproduce,” but make sure as much info is tracked in the ticket (description, reported steps to repro, user’s device info, browser, etc.)
If you haven’t done so already, add logging to your app (Papertrail/ELK for server-side; Sentry/Firebase/Amplitude for client-side).
Tracers are your friend: some unique identifier associated with a user. Store this in a cookie for web apps. For mobile, the user’s device-id should suffice.
Users should screen-record bugs in the future!
Implement ways to gather more information when the bug happens. This can include enhanced logging on certain areas, meetings with the ones who detected the issues, or even better instructions on how to log the defect.
You can also classify the issue regarding its impact. If multiple users are reporting it, the issue has higher impact, and deserves more attention.
Don’t feel bad closing a defect without any fix if you don’t have enough information, or if the issue doesn’t worth fixing…
For example… if the fix is 10 times the cost of keeping the issue on the system, a decision can be made to keep it there
Pay attention as well on old defects. If a defect was created against a version that is 2 years old, maybe it was already fixed. Engineers can fix defects while implementing a feature or refactoring a code.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.