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


21

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


13

Absolutely. The whole point of scrum is to get the product owners feedback at the end of every sprint to make sure you are building the correct things. The sales manager should not be interrupting you in the middle of a sprint. But when you do the presentation at the end he should be there and you should be writing defects for each and every one of his ...


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


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

What you see as interference might simply be them trying to put over new and/or changed requirements. Your example of the colour issue is a prime example of this. However, your other examples could be seen as interference - especially the way you've phrased them. What you need to do is arrange regular meetings to discuss the direction and design of the ...


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

Ideally your requirements should be coming from the customer, but the sales staff is also a valuable source of feedback, and the fact that your sales staff is funnelling their requests through the sales manager (and not just inundating you with individual requests) suggests that they are trying to be helpful to the process, and not merely interfering. Does ...


7

No, such a metrics are absolutely counter-productive. With this kind of metric, people spend time gaming the metric, rather than thinking how to do their job well. I've actually seen a situation, where there was contract on maximum number of outstanding bugs. The effect was, that most of bug reports were immediately closed with bogus resolution.


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

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

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

"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

First of all, if you aren't yet using an issue tracker tool, get one and make it accessible to users. This way they can enter their bugs into it, rather than pestering you directly via emails or phone calls. You should of course train them to use the tool correctly - this may be a significant initial investment, but it will quickly pay off. Let users freely ...


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

Not all issues are created equal. Some are trivial changes and some are multi-developer multi-week projects. A simple issue count doesn't take these factors into account.


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

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

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


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

There's a difference between meddling/interfering and making suggestions. There's also a difference between valuable suggestions and useless ones. If you're being actively interrupted while working on code, that counts as meddling or interfering. In such a case, you have every right to get the salesperson out of your face. Additionally, if your decisions ...


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