Responsibility to reproduce bugs

Question

I'm developing a program using a library made by another programmer (he works in the same company). Recently I discovered a leak in the library, which happens under certain network conditions after a few hours of running. I filed a bug with description of conditions to make this leak happen. That developer answered that "this is not enough", "it's not his responsibility to reproduce bugs" and I have to create unit test to reproduce this bug, otherwise he doesn't do anything.

1. Is he right?
2. What I can do in this situation? Creating unit test is impossible, because it depends on some random network timings.

Answer 1

Is he right is probably a question that can't really be answered without knowing your company. However, he certainly isn't being very helpful.

I would raise the bug with him (which you've done), if it is causing an issue with your project then I would raise it as a blocker with your project manager and make it very clear that you've raised the bug with appropriate person but it's going to impact your project if it isn't fixed promptly.

I would also go over and talk to the developer and explain why it's infeasible to create unit tests but you'd be happy to show him it on your machine (assuming that's feasible?).

Answer 2

He is 100% right that you must provide enough information to make the bug reproducible - otherwise there is no chance to find out if any fix he provides will really work.

But - he is IMHO 100% wrong that this must be in form of a unit test. If you can describe a test scenario in a way so he can reproduce the failure (at least with a high probability in a reasonable amount of time, or by manual testing), you have a proof that the problem exists - which should set your colleague in the responsibility to fix it. Of course, if you are able to create a scenario which reproduces the bug quicker, that would be helpful for him. Ideally, one would make an automated test out of that, and it depends on your organization who has the responsibility for this.

Answer 3

Both sides should put some effort.

Library developer should put some additional effort even without unit-tests, because some issues cannot be reproduced with unit tests. Sometimes it's hardware, sometimes it's some specific sequence of correct actions from the rest of program which makes the library producing bad results.

You should put some additional effort, because after all this my not be a bug in the library, but result of incorrect actions from the rest of program (e.g. corrupted heap may make any library behaving weirdly). So it makes sense to reduce as much as possible non-library code involved into bug reproducing. And you will likely do this faster and cleaner than a person unfamiliar with code of your application.

Answer 4

If the author of the library is unable to reproduce the bug based upon your report, then it is unreasonable to expect him to spend a lot of time on it, let alone fix it.

But you also have a limited amount of time spend working on a product that is peripheral to your interest. Unfortunately, this may mean that the bug continues to exist, and no work is done on resolving it.

Fortunately this is not necessarily a disaster -- while in an ideal world, all software would be bug free, that isn't the case, and so we have to prioritize based upon the problems it causes US.

This means that it is indeed your responsibility to develop a reproducible test case IF YOU WANT IT FIXED. You may not care whether it gets fixed, and in that case, you have done everything that can and should be expected of you. You may want it fixed, but not enough to devote time to make it reproducible at this time. That is perfectly acceptable.

Reporting a bug to the best of your ability in the time you have to deal with it is simply good citizenship, you don't need to go beyond that unless it is necessary for your program. And you may not want to do so even then, there may be another library that you could use, or it may be possible to roll your own in a reasonable period of time. Basically it's up to you to decide what and what kind of effort it is worth to you.

Answer 5

I'd be inclined to let sleeping dogs lie for now - you've raised the issue and it is assigned to him. Presumably there are processes in place to track outstanding bugs and chase these up?

If you wish to actively progress this further, I'd suggest talking to your manager to see if there are any test tools available that can reliably reproduce the issue.

From the developer's side - it would be seriously inert of them to do nothing given that you've provided the required information. It may be possible however that they have a massive workload so can't devote the time required to track the issue through.

Answer 6

You found a bug, you reported it and he's being a jerk about it.

Had the two of you been close friends he would have done something to help, but he'd rather just push the issue back.

You can do more, by reporting more details and trying to support your claims that it's leaking memory. Still, you have your own responsibilities and need to finish your own work.

Log as much information into the bug tracker as you can, and move on.

If you see this person again in the future. Be friendly, try to talk about common interests and understand that good relationships are far more effect way of getting things fixed, then any amount of facts you can provide to support a claim.

Answer 7

Often, what I've come across in similar situations is an assumption that all bugs should be fixed and while it's admirable, it's definitely a great goal to have (lets face it we never set out to write bugs!) it is ultimately unrealistic in any project of a decent size to fix a bug just because it is a bug (if you can find it!) That's why we have project management and coding methodologies, patterns & practices etc.

So, one thing I'd say in the library owner's defence (and has been the case when I've worked on some big projects) is that dev time costs money and is a finite resource so the decision as to how a report is handled, who investigates, what tests are produced/needed and ultimately if (and if so, when) a fix is put in place is based purely on business impact. What is the impact of restarting your long running process once in a while if it fails and can you easily automate that instead (and perhaps shouldn't you be already as a defensive programming measure?) is it just time or is there more to it?

Also look at it from their point of view, a bug report from one user of an unpredictable problem in a bit of code that happens very rarely, only in conjunction with their code, possibly only on one machine and only under a set of unusual timing conditions just won't have a strong justification for a large chunk of dev time to find and fix - if it's even possible. But if it's a strong enough business case for that user to want/need to take the time to investigate more thoroughly and provide a reliable test case / application or a radically more detailed problem description than their initial one then it could be a whole other ballgame.

This is perhaps an issue of communication that the library owner has not considered putting it that way and if you've got a strong business case (such as your code is costly for the business, has a legal compliance requirement, security hole or has some other major knock-on effect) then it's time to kick it up to management and let them fight it out.

Answer 8

You have mentioned that ' I filed a bug with description of conditions to make this leak happen.'

If you are sure that description is really enough to reproduce bug then you already know exact conditions. Now, if you cannot write unit test after knowing conditions, then that clearly means that you cannot mock some of the components involved or some parts of code are too tightly coupled to allow to create practical unit test.

You should ask library owner to refactor code to allow you to create unit test. You will have to explain clearly what is in library that is stopping you to create unit test. He will have to refactor code otherwise concede that unit test is not possible with current code. Both ways, you win.

If this does not work, following are options you have:

• You can reproduce bug with more evidences.
• Try involving higher authority and ask him/her to evaluate your evidences.
• Try using library in prototype application with mock environment to be coded only to reproduce bug. That way, you will be able to prove at least that bug exists.