Hot answers tagged

72

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how can ...


35

How do they intend to verify that the bug in question was fixed? Do they want to ship untested code to the user and let them figure it out? Any test setup that was never shown to reproduce the error can't be relied upon to show absence of the error. You certainly don't need to reproduce the entire client environment, but you do need enough to reproduce ...


32

Revert your dev environment to the version that the bug was noticed in and verify that the bug is there. If it is there then you can investigate the bug and make sure that the current version doesn't have it. Then close the bug report with the comment that an unrelated change fixed it. Add a regression test if needed. If you can't reproduce the bug in that ...


27

Ideally, you want to be able to reproduce each bug so that, at the very least, you can test that it's been fixed. But... That may not always be feasible or even physically possible. Especially with 'enterprise' type software where each installation is unique. There's also the cost/benefit evaluation. A couple of hours of looking over code and making a few ...


24

It is absolutely possible to have those values differ. If you have a sale to make to an important government agency that requires high performance but won't ever use module X, then it makes a lot of business sense to fix a minor database availability error sooner than a severe error in the X module. Basically, technical reasons are not the only factor when ...


11

I don't think you should make a reproducing the error a requirement to look at the bug. There are, as you've mentioned, several ways to debug the issue - and you should use all of them. You should count yourself lucky that they were able to give you a log file! If you or someone at your company is able to reproduce the bug, great! If not, you should still ...


11

Show me someone who cares. Fixing bugs from an unfeeling checklist gets to be a drag. If the fix will put a smile on someone’s face, let me see it. Don’t make me work alone. Every bug fix is a chance to learn something and it is great fun to share something you learned with someone else. Let me do more than just fix bugs. Sometimes bugs show you a ...


10

If encouraging people to frequently interrupt each other just because of plain laziness is considered Agile, then I have to admit that my understanding of Agile is seriously broken. A sufficient problem description is not a (potentially superfluous) product documentation, rather it is a distinct collection of all facts necessary to efficiently reproduce ...


10

By your wording, you have defined your answer to be true. You talk about the first "wrong state." What defines a wrong state? What makes it wrong? Typically the answer is "it wasn't the state that was correct." By definition, the first wrong state is preceded by only correct states (or something went wrong on the first step, but that starts to be an OS ...


9

In my opinion ... as the decision maker, you must be able to justify your position. If the goal of the 3rd line support department is to fix bugs in the shortest time frame with the acceptable effort from the client, then any approach must comply with that goal. Furthermore, if the approach can be proven to give the fastest expected results, then there ...


8

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? I say yes, with some caveats. I think it's okay to read through the code and try to find places that look like they may be problematic. Create a patch and send that to the client to see if that resolves the problem. If this approach continues to fail, then ...


7

At a technical level, bugs, features, it's all the same, a change request. Do you ever decide not to add a feature because it's not worth it? It's the same with bugs. The only difference between bugs and features is commercial - 'customers' pay for features, the 'company' pays for bug fixes, or something like that. However, as with feature requests, every ...


7

Just to confuse things, if you delete an essential line of code from a program, then it will malfunction. Once you have done this, the logical error in the code will not be down to any line in the program. It will be caused by the absence of a line.


6

If you're not positive about the problem, you can't be positive about the solution. Knowing how to reproduce the problem reliably in at least one test case situation allows you to prove that you know how to cause the error, and therefore also allows you to prove on the flip side that the problem has been solved, due to the subsequent lack of error in the ...


6

You should have a triage and priorities meeting on a regular basis. At my previous job we used to have a weekly meeting that consisted of product owners and the dev lead (me). We would review current priorites prioritize new bugs prioritize new features The goal was to make sure there was a balance in what we worked on. I would explain the cost of ...


6

"Agile" does not mean you have no rules and processes - just that you should try to get by with as little as possible (but no less, to paraphrase the Einstein quotation). The Agile Manifesto expresses this as "Individuals and interactions over processes and tools". In your case that means you should discuss this with your colleagues. Explain the benefits ...


5

From the development manager's standpoint, it absolutely matters whether the defect is new or whether it is an existing defect because it has a direct and immediate impact on how the bug needs to be handled. From the development manager's standpoint, the most important question is whether a new bug needs to be resolved in the current release cycle or ...


4

I think your question boils down to semantics. The phrase "prevention of defects" doesn't really mean anything. "Prevention of defects in the product" isn't much more precise. My guess (and that's just what it is) is that when the authors say "prevention of defects in the product" they are not talking about preventing the creation of defects in any code ...


4

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? No, it very definitely isn't. That would be a stupid policy. The problem I see with your question and your proposal is that they fail to make a distinction between bug reports failures (errors) bugs (also sometimes called errors) A bug report is ...


4

I have read that it measures the effectiveness of QA but I do not get it It is surely a good idea to take any such statement about metrics with a grain of salt. The only way I can think of to use the given metrics to measure the effectiveness of QA, is to take the same piece of code, give it to different QA people and let them independently test it. In ...


3

As with everything else in software development, the correct answer is a compromise. In theory, you should never try to fix a bug if you cannot prove that it exists. Doing so may cause you to make unnecessary changes to your code that don't ultimately solve anything. And proving it means reproducing it first, then creating and applying a fix, then ...


3

Unless the error is evident, obvious and trivial, with a very specific error message, etc., it's often very difficult to fix a bug if the user or the maintainer is not able to replicate it. Also, how would you prove to them that the bug is fixed if you cannot replicate the steps? The problem with your case is that the user doesn't know either how the ...


3

Let's take it to the extreme, and assume that you found the bug much earlier: in your code, as you were writing it. Then you wouldn't have any qualms about fixing it right there -- you see a logic flaw in the code you just wrote, it doesn't do what you wanted it to do. You wouldn't feel a need to setup a whole environment to show that it's actually a bug. ...


3

QA ideally prevents defects by doing a root cause analysis on defects that have been discovered, and identifies and removes common root causes. In the context of software development, this would be things like replacing error-prone technolgies with more mature ones, having new developers by systematically trained, ensuring that there are unit tests for the ...


3

Looks to me that what have been missing in all answers is the main idea of the development process itself. What is a development process about? A development process is mainly about maturity, quality. And quality assurance is nothing but making sure the process is correctly followed. Therefore, its benefits are deeply related to having a development process. ...


3

Consolidation of defect management sounds like a good idea unless the projects are so orthogonal as to require separate defect managing systems. For instance, a solo developer doing his own testing could get by with bullet list, while a distributed organization with customers reporting bugs to a support team requires a much more heavy-weight process. This ...


3

You can say "Reported Customer Issue" or anything else if it makes people happy. I'm going to say "Bug" because it has such a grand history and is the industry standard term. In a brand new bug list, you might expect to fix near 100%. But the more bugs that are added to the list, the fewer you expect to fix. In fact, most bug tracking tools let you close ...


3

Date and time bugs Bug: Year-end processing will totally corrupt your database. That's clearly a severe bug. Date: December 15. The bug is very high priority. Date: February 1. The bug is low priority. Accidental launch of missile bug Bug: ICBM control software pukes when going from Feb 28 to Mar 1 in years divisible by 4. The result is an ...


3

If the array is only used within the inside of the class, and the fact of the variable's type as E[] is never exposed outside the class (e.g. returned in a method, or it is a public or protected field, etc.), then there is no problem as inside the class E is erased. However, if you expose the fact of the array variable's type as E[] to the outside of the ...


Only top voted, non community-wiki answers of a minimum length are eligible