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?

  • 2
    I think a good way around this is to document the steps you took to achieve this state. The best way I've found of doing this is to use a screen sharing recording to demonstrate exactly how the bug is encountered. And of course, include as much details as possible e.g browser, OS etc. You could also have a template in which you fill out every time a bug is logged for consistency of reporting. Commented Sep 12, 2017 at 15:58
  • 1
    @alecxe - I am not sure if there is a badge for asking good questions, but it should should be, and you rightly deserve it. Commented Sep 13, 2017 at 15:26
  • 3
    There's simply no general way to decide. Sometimes it's the user's antivirus.
    – Joshua
    Commented Sep 14, 2017 at 3:43
  • 1
    "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)" Cough. You mean like the tester in 99% of the cases being paid less than the developer? It is totally sane to put more workload on the lower hourly cost side and free the more expensive resource to do more work that the lower paid resources can not do. People are NOT all equal, in terms of payroll.
    – TomTom
    Commented Sep 14, 2017 at 9:27
  • 2
    It is not the developers choice. Is it ethical to waste client resources? Is it ethical to bill more because you don't want to put more work to other lower paid assets that have exactly this job? I would argue a developer wasting his time is committing fraud. A tester is there exactly for this type of work. Nothing "polite" about wasting money and refusing to let a guy hired for a specific job make his job.
    – TomTom
    Commented Sep 14, 2017 at 12:57

8 Answers 8


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.

  • "Investigation" doesn't mean "find why the bug is happening so we developers can fix it", it means "we developers can't reproduce it so we can't work on it, please document the steps to reproduce better because this bug report is inadequate for us to act on it". If you report a bug, you owe it to the developer to show them the defect, or they won't work on it at all.
    – Beanluc
    Commented Sep 14, 2017 at 16:28
  • @Beanluc - You sound as a developer, and quite a conscientious one. You might be surprised that some (other than you) developers might try to push more work to QA ("more investigation needed") so they can spend more time on stuff like watching football games on their workstation during work time. I've seen it happen. Commented Sep 14, 2017 at 16:58

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.
  • 7
    +1 just for the second point of the second list: Testers might put significant effort into isolating a bug that turns out to be a low priority for fixing. Especially if we've already put work into the next iteration that made that bug irrelevant, or that fixed that bug incidentally - and the QA people would have no way of knowing that.
    – sq33G
    Commented Sep 13, 2017 at 10:08
  • 2
    @sq33G Exactly. That's exactly why I championed to get manager involved early in my answer. Commented Sep 13, 2017 at 13:48
  • 2
    @sq33G: At the same time, in general the exact scope of a bug is only understood after investigation. This one in a million chance of triggering the bug could actually reveal a security issue which allows dumping the whole database (Equifax!). Until the bug is fully understood, the assessment about its severity cannot be made. Commented Sep 14, 2017 at 14:23
  • @JoeStrazzere: My apologies for mispelling your name.
    – dzieciou
    Commented Nov 17, 2017 at 11:35
  • @dzieciou - no worries. I've seen far worse! Commented Nov 17, 2017 at 17:08

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.

  • 5
    Agreed, with the exception that the dev should have the option to ask a tester to perform a test focusing on something specific - e.g. "does it also happen if..." or "which of these 2 modified builds acts different...", especially if the bug takes a while to reproduce.
    – kaay
    Commented Sep 13, 2017 at 10:47
  • 2
    Developers should also have the freedom to consult with testers. Testers are usually far more adept at reproducing bugs, especially if timing is involved or actions that are hard to describe, and then it can really help a developer to see with their own eyes how he bug can be reproduced. Commented Jul 25, 2019 at 8:44
  • @BartvanIngenSchenau - So noted! Commented Jul 25, 2019 at 8:48

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.


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!


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.


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.