Who is responsible for pinpointing bugs?

Question

Let's imagine this common situation: a tester creates an issue for a developer to fix, providing the steps to reproduce, screenshots and other details (if available). Then, a developer does not think an issue is detailed enough and asks a tester to spend more time researching the conditions under which an issue is reproducible or add more observations and notes about when the problem happens.

In some cases, this kind of a request is really valid - adding more details would really help to further narrow down the problematic conditions, but I've oftentimes seen a developer not willing to spend extra debugging time even though this is easier for him or her to do than for a tester to pinpoint what happens. Sometimes, that is because this developer does not value tester's time as much as he or she values developer's time (which is not a healthy thing to have in a team). In cases like this, a conflict between a developer and a tester happens.

This kind of situation is, I guess, inevitable since both parties operate in this intermediate temporary shared state of a debugging and pinpointing a problem. But, what are the general ways to avoid having or deal with such conflicts keeping the relationship between the teams healthy and productive?

Answer 1

If request sounds reasonable (which includes taking into account my other priorities), I would spend some more time researching.

If not reasonable, I will respond "sorry this is the best I can", and if my polite refusal to spend more time researching is not enough for the developer, I will ask my manager to make the decision. I would also mention to manager:

• if developer is better positioned to investigate it deeper (if it is the case),
• if investigated code is in churn and there is a good chance that it will be changed before bug could be investigated (making bug report obsolete and moot)
• any other bugs in current QA pipeline touching adjacent code (if I am aware) so other developers might need to be involved
• any other relevant info to allow my manager make better informed decision how to proceed.

My manager will either tell me that:

• I need to spend more time on it and assign the priority comparing to my other tasks (which I will communicate to developer, so dev can decide to not wait)
• or decides that I already have spent enough time, and would talks to dev's manager.

Disagreement between peers is exactly why we have managers. Also, dev's manager would want to know if such requests to shift work from devs to testers are a pattern for a particular developer.

Quality is a team sport. Every member of a team has to play along, and managers are here to resolve disagreements if it is not the case.

Answer 2

It depends.

As Joe Strazzere explained, it is a matter of discussion between devs and testers. The question is what factors to consider in such a discussion. I think Danny R. Faught explained that pretty well in How to Make your Bugs Lonely: Tips on Bug Isolation.

There is no clear dividing line between the bug isolation and reporting that the tester does and the debugging that the programmer does. In most organizations, there's plenty of room for the testers to put more effort into bug isolation. On the other hand, there may also be reasons to have the testers report the first symptom they see and then move on.

Here are some factors in favor of having testers put significant effort into isolating the bugs they report:

• Testers may be more motivated than the programmers to show that the bug has a real impact and should be fixed.
• Because they spend more time on bug reporting than programmers, the testers may be better as bug isolation than the programmers.
• The information that the tester learns about the bug can be put into immediate use for further testing.
• Testers may have access to more resources, such as staff and lab equipment, than the programmers.

However, there are also factors that could indicate that it's best to put most of the weight of bug isolation on the programmers:

• The testers may not be highly skilled or experienced, so they may not be adept at bug isolation.
• Testers might put significant effort into isolating a bug that turns out to be a low priority for fixing.
• Testing resources may be more constrained than development resources.
• It might be more productive to use knowledge of the code to zoom in on the problem.
• Having the testers do significant bug isolation makes their somewhat unpredictable project schedule even more fluid, because it's hard to predict how many bugs will be found and how hard they are to characterize. Of course, the programmers have the same problem if we shift the work to them instead.

Answer 3

Many companies I've worked for shared a policy...

...and that policy is:

• Testers are free to consult with developers while attempting to characterize, isolate or reproduce anomalous behavior.
• Once a tester can document the steps necessary to faithfully recreate the behavior, the developer should be able to take it from there.
• Developers are free to consult with testers as well, for clarification, assistance in recreating, or any other reason.

The logic behind this is fairly straightforward:

• The developer should have better insight as to what part of the program might be responsible for the observed behavior.
• The developer can often use a debugger to step through the suspect code while observing call results and intermediate values.
• In systems where debugging is impractical, the developer can modify the code, inserting additional debug information outputs or logging around suspected areas in the code. The tester cannot typically do the same.

Therefore it is usually much more efficient to have the developer responsible for the code fix it.

Answer 4

But, what are the general ways to avoid having or deal with such conflicts keeping the relationship between the teams healthy and productive?

Both QA management and Development management must come to an agreement regarding the ground rules of bug reports.

In some shops, more detail is required before the bug report is sufficient to hand off to development for fixing. That may happen with inexperienced developers, or when maintenance/development is outsourced.

Other shops require less detail.

And some shops like to call the dev/tester over to demonstrate the bug in person (to whichever desk is more convenient) and have the dev write whatever notes he feels he needs.

It's always context and company-specific.

Answer 5

In my own experience, healthy personal relationship between developer and tester helps to sort out this problem. If a tester and a developer are friendly enough under company environment, then the negotiation will never be felt as negotiation. Rather both will consider as, this should be done with team effort and success or failure will be shared among both of them.

There will be always some rules and procedures for bug reporting and fixing but without dedication and proper co-operation conflicts will possibly go on!

Answer 6

To me, who is responsible depends on what kind of team you have.

If you have a traditional team, there will have to be an agreement detailing what the testers will do and what the developers will do.

If you work in a Scrum team, the bugs are the responsibilitie of the team. This means both developers and testers. Depending on how your team prefers to work, the tester will put more or less effort into describing and/or isolating the issue.

Personally, in this situation I prefer to take down the steps-to-reproduce for myself and then sitting together with a developer to show them what the issue is and how I produced it exactly. Depending on the issue, I then either go on trying to isolate it or the developer starts trying to fix it.

When things have to go through a ticketing system without any other interaction between tester and developer, you can lose a lot of time in ping-ponging which goes against the entire point of being agile and flexible. If there's a difference in the interpretation of the requirements (be it a user story or a spec) you can have a short discussion and either figure out the answer or go find the person who can. All within minutes rather than days.

Answer 7

Personally I think it's good practice to try to gather as much information about the bug so that the Developer in question can fix the bug - Yes...I just stated the obvious, but hear me out. I think providing the Developer with screenshots, stack traces, logs, recreation steps, general information (is it browser or OS specific?) and as much "evidence" as possible is the best way forward in my experience. It's not up to the test driver of the car to figure out where the weird engine noise is coming from, but what you can tell the Engineer or mechanic is that it only occurs at 6000 RPM and at X speed, while turning left, if you catch my drift (pun intentional). So in a nutshell, it's not your job so point out where exactly it breaks, but you can assist the developer in pinpointing while he troubleshoots on his/her own.

Answer 8

As a rule of thumb we follow is to provide sufficient information with screenshots to reproduce issues without assuming anything on the developer part.

Sometimes we are asked for additional info where we provide either video or show it live on QA environment to the developer/team however system internal states needs to be deducted by developer only.