Bug Reporting - how detailed without angering devs?

Hi All,

I would like to get your views on just how technical a Tester should be when logging a bug. My mantra has always been to provide the Developers with as much information as I can in order to help them debug the issue. This would generally include a summary of the issue and relevant test items (screenshots/steps to reproduce/reference numbers etc).

This is all fine, but sometimes I will go a bit deeper, for example if I discover a layout issue I may include a note suggesting a fix, eg: set margin-left: 1px for #thisID.

Is this good practice or am I stepping on the Developer’s toes? I’m trying to be helpful but I’m aware that this could be misconstrued as telling them how to do their job.

Interested to hear you thoughts :slight_smile:



It depends on the devs. Some welcome the deep research and appreciate you saving them time and effort. Others… don’t.

I’d recommend you do what works for the dev who’s most likely to get tasked with the fix, if you can. The other recommendation I’d make is not to be prescriptive about your suggested fixes, because if they turn out to be a red herring, the devs are more likely to be unhappy about it than if you hadn’t suggested anything.

I’ve found that language like “This looks a lot like issue X, which was caused by problem Y. This might be a good place to start looking” tends to work better than “This is a recurrence of issue X”, just in case it it’s a different problem with very similar symptoms.


Like @katepaulk said, it does depend on the dev.
3 examples:

  1. I had a dev once where certain types of issues would be met with resistance. But if I talked to him first about the issue, typically with a demonstration and asking him if that is how the functionality should work, then I could either make the issue official or let him fix it outside of the Jira (which is what we used for bug tracking) system.
  2. Different dev, I could post a potential fix and be guaranteed that that fix is NOT the one which would be implemented. From him, I learned that suggesting a fix was not a good thing for that team (saving me a lot of time in the process)
  3. Yet another dev. If I didn’t suggest a potential fix, getting a fix at all would be like pulling teeth. Often I would have to get a system architect or another dev to help him with the issue. But suggesting a fix would at least point him in the right direction.

In all of those cases, talking with your team prior to posting about the issue would save a lot of time, trouble and documentation. Especially in cases where:

  • You are confused about how the functionality should work (Or wrong)
  • It is a simple fix (the fix takes less time than writing about the issue)
  • The issue is complicated (talking about it reveals details which don’t come over in writing)
  • Backlog items don’t typically get attention
  • Getting a fix is more important than reporting metrics
  • The devs are easily approachable



I agree that how detailed you should get depends on the developer you are reporting to. Some get it from steps, result and expected result. Some need a video. Still, I think you should stay out of suggesting a solution, even if you know one. Why? Because of a number of reasons:

  • Your solution might not be the only one and therefore the best one.
  • When you deliver solution, your developer might stop thinking and start doing (really dangerous for juniors).
  • When you include a solution you might skip some important facts in your description of the issue, because you feel it is clear from the solution description.

In my team we call this: Solution mode. We don’t appreciate when our more technical customers do it. For the sake of a successful long term cooperation, we should be given a full description of the issue and be left to think about the best solution on our own. Think about a new developer in the team. They might need more time to solve some issues at the begging, but will be much faster later on when they get to know the software, domain, team members etc.


Fantastic responses, thank you all. This has made me realise that I am much better off turning off ‘Solution Mode’ when reporting any defects :slight_smile:

Totally depends on the context you are into. I am referring to the team members you are working with, their attitude, their rapport with you or vice-versa and many other attributes which helps in deciding how you need to go about your bug reporting. Either ways, you just need to be professional and I personally do not think that its bad to suggest a fix. If I were a developer, and you said “Maybe this fix helps?” I would be happy to see a tester like you.

Now, how you suggest matters a lot. It can be blunt, or it can be very pleasant.

Blunt --> "Fix this using set margin-left: 1px"
Pleasant --> “Maybe set margin-left: 1px helps?” What do you think?

By asking “What do you think?” you are valuing the developers view and you are taking his / her opinion. This makes it team work and also this kind of communication helps better team relationships in my view.


I really like what you’ve shared, @santhosh.tuppad! I’m a big fan of “What do you think?”. It’s such an incredibly inviting and collaborative question.

I’ve also experimented with the following:

  • Would you be up for trying something like that?
  • Do you think this might help?
  • Does this idea/suggestion work for you?
  • Would you be willing to give this a try?

Thanks :slight_smile: And also I usually use those questions that you have listed in experimentation in different contexts. Thanks for sharing!

“What do you think?” was just one of the example. Basically, “Questioning” helps and these questions should be mixed with respect and kindness ingredients.


I’ve had similar issues where I had to get it right depending on the team or person I was working with.

In one company it was frowned upon for testers to even suggest a fix.
If you could include logs or so that was fine but no suggestion of a fix.

In another place I have been sent bugs back because they were missing the solution. Which baffled me.

The main thing I learned was to talk to the team and ask them which approach works for them.
It’s been quite interesting to learn who likes to work how. :slight_smile:

Like everyone else said, depends on the team. As an embedded test engineer, it’s not uncommon for my investigation to lead me from the logs/stacktrace to the code, and often include the specific method, line, etc in tickets I enter.

I think this is key to me.

In your example, if you HAD to write the bug report first (e.g. developer wasn’t in the office, or isn’t immediately available to you) then I would perhaps include all of your investigation, logs etc in the bug report.

In terms of opinions on what the problem may be or how to fix it, I’d always leave this to face to face discussion and then put it into the bug ticket afterwards. There have been a few times where I’ve been SURE that the problem exists in area A and I’ve included it in emails/reports and when a developer has looked at it, they’ve found the problem is actually in area Z.

I try to avoid writing bug reports where possible. Any bugs I find I’ve been speaking to developers about and getting them fixed there and then. Of course, bug reports are still important for functionality which a) isn’t currently in development (existing features) and b) are complex and ‘unimportant’.

If you are avoiding bug reports, how does your team keep track of past bugs? At the current company I am at, getting a dev to talk to you can be difficult because they tend to be very busy. So it leads to a situation where it’s like their work is thrown over a wall to me when it needs to be tested. It’s not a situation I like to say the least.

Whoa… don’t turn it off your ‘Solution Mode’ just modify it to suit the dev your working with.

Example: Dev turns around to me test analyst and mumbles something about a production issue after a release. We had a very good relationship then but trust me it took time to get there. Sitting beside me was the system QA expert but he asked me. I told him it was XYZ and this was because of 123. He couldn’t replicate but trusted my knowledge based on all our past experiences (I don’t give an answer unless I am 100% sure). He came back about 1hr later to let me know this was confirmed with business/production.

Example: Dev who I have an limited relationship with mentions a bug in stand up and I offer a solution based on historical information/experience. He looks at me like I have sprouted a second head out of my neck and instantly dismisses my comments as irrelevant. He then goes back, wastes 2 or 3 hrs chasing his tail and came up with the same conclusion. Next day he mentions this in stand up and honestly he just lost a little bit of street cred by wasting so much time on a previously identified issue. But that is his issue not mine having said that this is NOT the way to make friends and influence people as it literally took nearly 2 years before we had the same relationship as described above. I was very green about tester - developer relationships way back then.

Nowadays,when we have Agile! Agile! scrum teams around the globe and scrum teams expect technical testers- a self-organised with automation + performance +security testing skills.Moreover,as JIRA is being used for stories,issues as well bugs,so in Agile world,new style of bug description has come up :Scrum masters/product owners everyone speak agile language and expect the same from testers ,for example,some use Gherkin syntax (GIVEN…WHEN…THEN) to write bug description similar to stories and attach any logs/screenshots along with it.Agile world - everyone is called “developer” in the team :slight_smile:

I write bug reports currently for bugs which are not deemed important enough to fix at the development stage. For example - bugs with existing functionality, UI bugs which will not stop the feature being shipped etc.

I’d like to get away from this, because I find that the bugs sit there for months/years, so why waste the time writing them up? I’ve floated the idea of having a bug expiration data - so if a bug isn’t fixed within 6 months, it is automatically removed from our planning board.

I was speaking to someone at a recent meetup who have a ‘zero bug policy’ - meaning that they don’t raise any bugs at all. If it is discussed with the team at the development stage and isn’t deemed important enough to fix then they don’t raise it at all. They still have ‘session notes’ with all the information, but no bug/defect is logged in Jira etc. I never got the chance to ask how this works with pre-existing functionality/customer reported bugs.

Either way, I’ve found much more success in getting bugs fixed by talking directly to developers, even the small bugs. If they have the code open in front of them and I’m explaining the problem then there’s a high chance it is getting fixed there and then.

1 Like

Nice to read in the part of the world you work in, Agile is completely applied. Can’t wait till the rest of the world catches up to the kind of environment you are accustomed to. I am a big supporter of Agile methodology in it’s purist form but unfortunately here, most companies apply a combination of previous methodology to the newly adopted Agile/Lean/Scrum. :slight_smile:


When I write bug reports I usually do the following -

  1. A list of steps to replicate the bug
  2. A description of the error and what requirement or expectation they contravene
  3. An example data set they can use
  4. Screenshots or when necessary video

I don’t tend to offer an expected workflow or solution. I leave that to the business or BAs to elucidate their wishes in this area.

The above has always worked for me.

1 Like

If the developer is sitting in the same building I’d simply walk over and show him what I found

1 Like

If I’m in any doubt as to whether I am looking at a bug or a feature, or if I suspect my understanding of the functionality may be suspect, I’ll talk to the dev and if necessary ask “Do you want me to raise that as a bug?”. Otherwise, I’ll raise the bug, if only to get it written down whilst my memory is still fresh (especially in terms of the steps to replicate); and then I’ll go and talk to the dev - or if they’re not available or working remotely, send them a personal e-mail (as opposed to the automatic one they’ll get from our bug tracking software), if necessary putting the bug tracker number in the subject line and the request READ THIS FIRST! in large friendly letters.

This usually works.

I think the ‘what do you think’ is a great thing to do - even better if it can be done face to face or on the phone vs. a ticket/email. One thing I find often happens is the interpretation of written updates can end up causing unnecessary issues between teams. More talking will not only foster better communication but also a level of trust and team work. I also recommend using any screen recording tools vs. screen shots - having the likes of Problem Step Recorder running in the background sometimes helps to show the steps taken better than screen shots.