|
|
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1539
   |
Posted - 2014.01.15 16:11:00 -
[1] - Quote
Dev tools don't actually help you reproduce a problem. They help you once you've reproduced the problem and let you start to zero in on what is actually causing it. I've been a developer for 8 years now, mostly in healthcare which, as you can imagine, is the most anti-bug sector you can be in. If something doesn't work right people start flipping tables.
People will report a bug, but if they can't give us the steps to reproduce it all we've got is "there's a problem". You can try screwing around in the app to reproduce it, but that's just a blind, dumb luck search. Until the developer can actually see it happen on his machine there isn't a damn thing that can be done to fix it. There is no such thing as a tool that reproduces a bug that the steps are not known for. |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1540
|
Posted - 2014.01.15 16:29:00 -
[2] - Quote
If the bug was crippling then we'd be able to reproduce it, and the logs would show clues that lead to the source of the problem. If the problem can't be reproduced then it is, by definition, not crippling. |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1540
|
Posted - 2014.01.15 16:36:00 -
[3] - Quote
Thumb Green wrote:Kristoff Atruin wrote:There is no such thing as a tool that reproduces a bug that the steps are not known for. True, but there is a tool that allows them to watch the code while it's running and when something randomly happens that isn't supposed to they can stop the program and analyze that portion of the code to see what's up. Of course the problem might not be with that portion of the code itself but it's a starting point and if they don't find the problem there they can look into other portions of code that ties into that portion. However it also extends beyond bugs into balance issues; take the current AV vs tank imbalance, how the fck did that slip by Q/A?
That tool is what I was talking about when I said "They help you once you've reproduced the problem and let you start to zero in on what is actually causing it". You can't step into the code where the bug is occurring if you can't make the bug happen. Without the steps to reproduce you're not going anywhere. |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1540
|
Posted - 2014.01.15 16:38:00 -
[4] - Quote
Ghosts Chance wrote:Kristoff Atruin wrote:If the bug was crippling then we'd be able to reproduce it, and the logs would show clues that lead to the source of the problem. If the problem can't be reproduced then it is, by definition, not crippling. so a bug that would cause your weapon to overheat, not fire, or randomly fire without you pulling the trigger is in no way crippling tot he person using it? (or have your shots shoot right through what your shooting at....)
It's annoying to you, but the game is still running and 99.9% of the other people playing at that moment are having no problems with their gun not firing. You're falling into the user reporting a bug trap of, "It happened to me therefore this is the most important thing ever".
Seriously, go work in software development for a while. It's absurd. Users will report bugs and if they're allowed to rate the severity every last bug will be critical or at the very least moderate, even if it is something that happened once to one user and didn't stop anything from finishing. |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1540
|
Posted - 2014.01.15 16:43:00 -
[5] - Quote
They're really not helpful at all until you can observe the problem happening. Quite often a "bug" isn't actually a bug, but a problem with the user's environment. I could start my debugger and run through the app all day long. If I did run into the bug then yeah, I've got what I need to get started. The problem is you're expecting the tools to also help you get through that reproduction step. It doesn't work and it can't work. If someone ever builds a tool that can do that for us then we've basically created skynet and are ready to let autonomous computers solve all the world's problems. |
Kristoff Atruin
Subdreddit
Test Alliance Please Ignore
1542
|
Posted - 2014.01.15 18:14:00 -
[6] - Quote
Nothing like a good ol' Heisenbug. One that only occurs when you're not looking for it. It is possible to fix bugs that can't be reliably reproduced, but it chews up a ton of development time. At that point it comes down to tradeoffs, do I fix several bugs that we know how to reproduce + add this other planned features, or do I fix this one annoying thing? This is why some bugs stick around for a long time, there was more value added by fixing other bugs first.
I've literally been told not to fix a long standing bug after spending a couple days looking into it and having a good idea where the problem was going to wind up being, because we had a date for when the next build was going to be released and the client preferred to have a handful of easily done (and boring, from a technical perspective) change requests than the fix for the one bug that had been annoying us for ages. |
|
|
| |
|