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 ...


28

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 ...


9

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

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

"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 ...


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 ...


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

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 ...


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

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

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

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

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 ...


2

(even though it's been marked as duplicate, my answer is not ;) It is possible but no one can prove it, not for TeX size. http://ertos.nicta.com.au/research/l4.verified/ is an example of a verified piece of software. There are two things that anyone can do to say that their software is bug free (not saying that Don said it): test the hell out of it and ...


2

Yes, you could set yourselves up for trouble by blindingly accepting the client classifications of bugs/defects/features/they-don't-know-what-they-want/requirements. As Greg Bair points out, there are cases where "You are doing it wrong" is the issue not the actual software. These most often come up because the persons who define the requirements don't use ...


2

What you need to understand is that in large corporations, there needs to be a clearly defined process, or else everyone's off doing their own thing, and team A doesn't know what Team B's definition of "defect" is. So, there's probably a pretty strict classification system, so that teams can instantly know what other teams are talking about. However, this ...


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