Timeline for How to report a bug that has no technical solution?
Current License: CC BY-SA 3.0
21 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 9, 2017 at 20:46 | vote | accept | oscar | ||
Jul 9, 2017 at 8:44 | comment | added | gnasher729 | @oscar: Your company policy is frankly idiotic (not your fault obviously). So when I bring my car to the garage to have a problem fixed, I need to tell them how I would fix the problem on a highl level? On a high level, you fix the problem by giving up your job, training as a software developer, and fixing it. No software developer will even take a look at your "high level solution". QA should report undesirable behaviour, how to reproduce the undesirable behaviour, and obvious desired behaviour. Even with "desired behaviour" you won't always be able to provide that, because there ... | |
Jul 9, 2017 at 3:01 | comment | added | rackandboneman | "Solution: disable feature." | |
Jul 8, 2017 at 15:43 | comment | added | alephzero | "Software bugs" and "User errors" are two different things. It's not very clear to me which category this issue belongs to. If a user supplies plausible, but wrong, inputs to the application, there is nothing much the application can do about that. | |
Jul 8, 2017 at 6:03 | review | Close votes | |||
Jul 8, 2017 at 14:23 | |||||
Jul 8, 2017 at 3:48 | comment | added | oscar | @DonHatch, provide a solution = how I would fix this problem on a high level. | |
Jul 8, 2017 at 2:29 | comment | added | Don Hatch | Please clarify what "provide a solution" means. Does it mean you are supposed to take a guess as to the cause and what the most reasonable way to fix it would be, if one were to try to fix it? Or does it mean you are supposed to propose something that you believe to be a feasible solution (as @pjc50 asked)? Or something else? Whatever it means, it seems dysfunctional for a person tasked with identifying defects to be required to provide a "solution"-- that would push many defect reports into the reporter's "too hard" pile so that defects never get reported. | |
S Jul 7, 2017 at 21:25 | history | suggested | gbr | CC BY-SA 3.0 |
grammatical fix + temporary junk to get past the stupid 6 characters minimum edit limit
|
Jul 7, 2017 at 19:13 | comment | added | Schwern | FWIW that's a bad policy. The person encountering the issue is often not qualified to analyze the issue, decide if it's a bug or feature, and find a solution. Even if they are, they're probably busy doing something else right at that moment (and probably not happy they found an issue). The end result is legitimate issues will not be raised. Instead, issues should be raised as soon as they are found. Triage should be handled in a separate step, possibly by somebody else, and the issue tracker used to... well, keep track of issues. | |
Jul 7, 2017 at 17:23 | answer | added | gbr | timeline score: 5 | |
Jul 7, 2017 at 15:17 | review | Suggested edits | |||
S Jul 7, 2017 at 21:25 | |||||
Jul 7, 2017 at 14:26 | answer | added | Peter M. - stands for Monica | timeline score: 2 | |
Jul 7, 2017 at 13:38 | comment | added | JollyJoker | Second @pjc50 's comment. If a solution needs to be proposed for every issue but the decision on whether to actually fix something is separate, you have no problem whatsoever. | |
Jul 7, 2017 at 12:35 | comment | added | pjc50 | Provide a solution, or provide a feasible solution? You could just put the desired solution in and leave the scheduling of the solution to "when we get round to it", ie never. | |
Jul 7, 2017 at 12:14 | history | tweeted | twitter.com/StackSQA/status/883298287083802625 | ||
Jul 7, 2017 at 10:28 | answer | added | Michael Durrant | timeline score: 3 | |
Jul 7, 2017 at 10:19 | answer | added | Kedar Tiwaskar | timeline score: 3 | |
Jul 7, 2017 at 8:40 | answer | added | FDM | timeline score: 20 | |
Jul 7, 2017 at 8:36 | answer | added | AdrianHHH | timeline score: 6 | |
Jul 7, 2017 at 6:20 | answer | added | Yu Zhang | timeline score: 9 | |
Jul 7, 2017 at 4:59 | history | asked | oscar | CC BY-SA 3.0 |