- This topic has 17 replies, 14 voices, and was last updated 9 years, 4 months ago by
.
-
Posts
-
In a recent blog by Eric Jacobson’s he argues that reporting trivial bugs tends to waste everybody’s time and that you shouldn’t log them.
Do you agree or should all bugs be logged despite the severity?
survey toolAlthough I like the idea of not logging, I still think we should log it.
We might think it is trivial, but what if we are wrong? Logging it makes sure it gets reviewed / judged by others and that cannot be a bad thing.
Furthermore, a few trivial bugs is no problem, but how are we going to figure out if we get to a treshold where we have an alarming number of trivial bugs, if we do not log them? A few trivial bugs is okay, but if you release with a lot of those, it just yells “sloppy work”, and that is not the impression you want to give your customers.When that is said, we have agile teams and most of the trivial bugs are actually not logged. The team fixes it as soon as they are found, so no need to log it. If they can’t fix it the same day, it is logged, to make sure it is not forgotten.
Definitely yes.
For my team I’m always explaining that bug is evidence that you test.
And as well I agree with Frank, that what for me is trivial, maybe is not trivial for others.
And bug is fixed not when developers says that it is fixed, but when tester confirm that it is fixed.I have had this exact same conversation just the other day!
I was taught to log anything and everything but maybe that is because I used to work for a third party games testing company providing a service and then I worked with a distributed team across different time zones.
So there was no time to discuss that we were aware of minor/trivial bugs but decided to not log them. We just documented everything.Currently I still preach the same philosophy but in my last job we had a nice turnaround where any bug not touched in 6 months was closed, BUT trivial/minor bugs which tended to be grammar or spelling mistakes were actually prioritized as they are customer facing and cause the customer an annoyance.
I think it also depends how you define minor or trivial?Trivial as described by Eric Jacobson – don’t log them.
Especially when you are working in an Agile environment – only log what is not immediately fixed by a programmer after bringing it to his attention.I just searched for this and found the following:
‘If a trivial bug gets logged, often…
a programmer sees the bug report and fixes it – I personally have no issue with this as trivial bugs can be very visible even they do not threaten the inherent value of the feature immediately.
a programmer sees the bug report and wonders why the tester is not testing more important things – this I find a silly assertion but maybe it can happen? Has anyone experienced this?
a team member stumbles upon the bug report and has to spend 4 minutes reading it and understanding it before assigning some other attribute to it (like “deferred” or “rejected”) – I see how this wastes time but in the beginning it could help create a shared understanding of trivial that may be wasting time
a team member argues that it’s not worth fixing – that is the case with a few bugs in general, but in the end our product owner decides and needs allege information we can provide so we would log all trivial bugs
a tester has spent 15 minutes documenting a trivial bug.’ – I try to note down the more trivial ones and keep them tip the end to log but yes I understand the value of using the 15 minutes to try and test to find something more juicy to log.
I think I will struggle with this concept for a while. Is it more of an issue in very big teams?
1stly, I feel trivial is subjective. What’s trivial to a developer is not necessarily trivial to a tester, or a product owner or even the customer. If you don’t have a shared understanding for what trivial means between stakeholders/team members, all bugs not dealt with there and then should be logged, at least until there is a shared understanding.
2ndly, there are benefits to logging all trivial bugs as Frank Pedersen says. One or two ‘trivial’ bugs have minimal impact, but lots particularly in one area screams shoddy. Maybe the question isn’t should we though, but how can we quickly and efficiently?Kim, we’ve had all of the above responses when discussing defect reporting and I agree with your observations. We even tried, prior to moving to agile, to measure the time it took to raise a defect – our time to summarily rose by another 2-3mins per ticket. That went down well! 🙂
In our current agile methodology, like most of the posters we now only log defects that a dev can’t/won’t fix that day/sprint (our sprints are only 2 weeks long and a post-it suffices in this time). We have moved away though from formal defect tracking using a tool like quality center. Instead defects are tracked as issues in JIRA and treated like any other backlog item, to be addressed in a sprint of the team’s choosing. The defect, or list of defects in some cases, are raised as a single item with minimal information. Just enough to provide context for the developer/product owner to review quickly. If more information is needed, the dev/product owner can discuss with tester. Eventually, if the item never gets addressed it’ll be removed from the backlog I guess – we haven’t reached this point yet but I can see it happening.
I think you should log everything as well. most arguments have been said, so that I just want to add something a customer once said to me: “How can we trust you to find big issues, if you don’t even report the small ones?”
@christian I like the quote. I think this conversation could run in circles. In response to the quote, one could say “I didn’t report the small bugs because I’m spending my time finding the big ones”! but your customer makes a valid point.
If it’s a bug, it must be logged for audit purposes. Not just so we can show what we test but also for the developer(s) who fix it to show it has been fixed. Even if it means it only exists for a couple of hours, it still should be logged
I would not expect to see a log created every time a developer runs unit tests and discovers a typo in the code which can be fixed immediately. However generally it is a good idea to log even trivial bugs.. Some of the reasons have been mentioned. I would add
– it ensures that the responsibility for accepting the product with tolerated bugs lies with the customer (or whoever signs off the product)
– if a bug is fixed and appears again then it suggests that there may be a problem with the versioning or the fix has been undone by a later change. (It could also mean that the ‘fix’ only appeared to clear the bug. Not good news for developer or tester)..The logging systems I have used have allowed you to allocate a severity level to bugs so it is clear that which bugs are (probably) trivial.
So… let’s get a couple of things clear. If the working environment is such that a developer can just get torn in and fix the bug then there’s no need to log it. In effect it never happened. If we’re talking about a situation in which either we’re in wholly independent, old-school testing after a formal handover from development, or where a developer can’t (or won’t) fix it straight away then it should be logged.
Trivial, as has already been said, is a subjective term. But the bottom line is that if a tester can find the bug, so can a user. Even if the test is a highly technical one and perhaps bypasses input validation, that does not mean it couldn’t affect a user. Software is a complicated beast. If one bit of it doesn’t behave as it should then the consequences could be considerably more far-reaching than is indicated by the result of the test.
That’s true for any functional defect. But remember even the font, layout or colour can be a serious problem in many circumstances..
Testing is a process of discovery. If a tester is truly raising loads of defects that add no information that is of use to someone who matters, then there is a “learning opportunity”. Perhaps their peers or their manager ought to have a conversation with them to reset their expectations of what actually adds some value to the operation. But ultimately any new information is desirable.
I’ll address some of this in my Eurostar talk https://huddle.eurostarsoftwaretesting.com/event/2015/testing-scientific-method/
@Cristi,
Not all bugs is fixed so why every bug should be logged.?
Well we work in an agile company as a development process and for almost 2 years we didn’t log bugs witch could be fix right away, but after a wile we realize we lose time ( 10 minutes – 30 minutes or an hour for such a bug) from our development sprint and we couldn’t justify it, because of that we log all bugs now and we also prioritize them at backlog refinement( low, medium, hi……wont fix)
- You must be logged in to reply to this topic.