(Edit on 10/1/2014) Although too long, a better title would have been “You May Not Want To Tell Anyone About That Trivial Bug”. Thanks, dear readers, for your comments.
It’s a bug, no doubt. Yes, you are a super tester for finding it. Pat yourself on the back.
Now come down off that pedestal and think about this. By any stretch of the imagination, could that bug ever threaten the value of the product-under-test? Could it threaten the value of your testing? No? Then swallow your pride and keep it to yourself.
My thinking used to be: “I’ll just log it as low priority so we at least know it exists”. As a manager, when testers came to me with trivial bugs, I used to give the easy answer, “Sure, they probably won’t fix it but log it anyway”.
Now I see things differently. If a trivial bug gets logged, often…
- a programmer sees the bug report and fixes it
- a programmer sees the bug report and wonders why the tester is not testing more important things
- 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”)
- a team member argues that it’s not worth fixing
- a tester has spent 15 minutes documenting a trivial bug.
It seems to me, reporting trivial bugs tends to waste everybody’s time. Time that may be better spent adding value to your product. If you don’t buy that argument, how about this one: Tester credibility is built on finding good bugs, not trivial ones.
RSS
Ummm, no. Logging trivial bugs is a CYA activity for QA. I have logged thousands of bugs in my career and just last week someone from the business, found a very small item and the question was ... Why didn't QA find this? QA did find it, it was marked low and never fixed. Are those trivial bugs a waste of time? Maybe, but they have saved my job more than once.
But trivial in whose assessment? I could presume to know what other team members and customers think of the bug, but should it be my responsibility as a tester to make that decision on their behalf without their knowledge? Perhaps what I interpret as a superficial bug is, to a better-trained eye, an indication of a significant problem, like a small bulls-eye rash is a precursor for Lyme Disease. Should the limits of the single tester's imagination really be a criterion for deciding whether to log an issue? By subjecting the issue to review by multiple other perspectives, wouldn't we increase the chances of bleaching black swans?
In my opinion, logging what might be considered a trivial bug is an expression of safety language (http://www.testthisblog.com/2011/08/safety-language-and-preservation-of.html). I'd much rather have the product manager exercise his role and decide to close an unimplemented issue than have to confess that a problem that turned out to be a show-stopper was something I had observed but written off as unimportant weeks before because I was short-sighted.
What happens when a customer/client/user reports a trivial bug? That's when we log the bug or also ignore it?
And in this above case, would management ever then say "why was this not reported by QA"?
This post makes good sense, but it may still be good to log the trivial bug regardless just for tracking/audit purposes. And the logger of the bug should fill in all the details (and tag correctly) if they knew it was going to be trivial anyhow so that there would be little work following up on the bug (in terms of defering it, categorizing, etc.).
If no one reports the bug no big deal, but when customer/client reports it instead of QA, that can look bad for QA credibility. Might as well be proactive to prevent the possibility of that case, unless tester is in time crunch to have to pass on logging trivial bugs.
Hi Eric,
Usually, I like your perspective on testing. However, on this matter, I have to disagree with you.
Questions:
a. So, what about when you work for an organization where trivial bugs show up in Production and QA get's blamed for missing it? In some organizations, a "trivial" bug can through the User/Customer "off" and then the repercussion is a flood of calls to the Help Desk!
b. What if you work for a company that gets audited by SOX?
c. What about trying to get to the closer to a 'bug free' product?
d.
As a QA Manager, I tell all my testers to log everything.
Who cares how long it takes to log or review it, etc.
Some times the "trivial" bugs become a big issues.
I could not disagree more.
If you genuinely care about the quality of the software you are testing, then you should log every bug you see.
Well I agree from the perspective of saving everyone's time for it. But I also agree with the last comments, sometimes do not log a 'trivial' bug may hurt you and your team. Because trivial bug in one situation may become critical in another. Well I would say it sucks if someone catch it but failed to realize the impact. But that happens. Also trivial bug to one tester may become good bug to another. It is always good to look at it from different perspective. I think bug triage is the right way to define if a bug is trivial or not. Tester should not do the job for others.
It is true that a lot of trivial bugs get logged but never fixed. It is just the price of testing.
Though i agree to main point that functional/imp/high priority bugs should be top priority. However trivial bugs (after finding imp bugs) are what differentiates world class product from normal ones.
At the same time rather logging each and every trivial bug at the time of finding, I always suggest to collect them and log them at the middle/end of day (for 10-20 bugs it may roughly takes 30-40 mins in total).
When I find "trivial" bugs, I try to test around that bug. More often than not, I find something more serious. Even if I don't file an official report, I'll talk to one of the programmers on my team about it - often times, they're happy to fix it, because they see it as a silly mistake and have some professional pride in their work.
Hi Commenters. Thanks for making this a lively discussion! You are certainly giving me pause.
I think some of you are over looking an important statement I made in my post:
"By any stretch of the imagination, could that bug ever threaten the value of the product-under-test? Could it threaten the value of your testing?"
So if the answer is yes to either question, go ahead and tell someone about the bug.
So bugs that keep you employed, CYA, might get reported by users, etc. (all the cases you mention) should be shared.
I'm talking about ignoring those that can't threaten the value of the product. Who are we to identify those, right? Best left to the stakeholders, right? I want to argue that is not always the case. I think a skilled tester, who knows her domain, is capable of identifying trivial bugs (bugs that can't threaten the value of the product).
An example of one I found recently:
I can open a read-only message box, click on a certain spot in the box and start typing. As I type, the message box's title bar displays whatever text I type. There is no way to save changes and upon reopening the message box, the title is back to it's original value.
This product has been in production for 6 years with this bug. To my knowledge no user has noticed, much less complained.
I decided not to share said trivial bug and instead used that time to find (and share) a non-trivial bug.
Anonymous (CYA tester), if people are asking, "Why didn't QA find this?", it's probably not a trivial bug. Those are not the kind of bugs I'm talking about.
If you choose not to share a trivial bug and nobody asks your question, that is a sign that you may have found a trivial bug.
Get it?
man9ar00, if customers are reporting it, it's probably not trivial.
Let's say you make a bad call:
You find a bug that you believe cannot threaten the value of the product by any stretch of the imagination. You choose not to share it. Later a user reports it. Then shame on you. Apologize and adjust.
Anonymous (asking me questions),
a.) You (the tester) were wrong about it being a trivial bug. Explain that at the time, you thought your time was better utilized running more important tests.
b.) I test on a SOX audited product. I don't believe SOX addresses trivial bugs.
c.) a bug free product is a myth most testers don't bother chasing, especially since bugs are subjective
d.) I used to be like you. Over the years I've noticed how much time testers can waste on trivial bugs when more important bugs are being missed. Often, testers will side track themselves from really important testing to pursue the perfect phrasing of a message box that seldom displays.
Eric,
I am leaning towards agreeing with you a lot on this one. I think it's important to point out that the industry might be a bit messed up if someone is going to lose their job over a trivial bug not reported. In general I'm not the biggest fan of spending time doing something just for the sake of CYA. If I'm doing my job right I shouldn't have to constantly feel like I'm C'ing my A. I should feel confident that I'm an important contributor to the team, and by that merit am trusted to do my job.
Yehuda, I was thinking the same thing when I saw Anonymous's CYA comment. The more trust is earned, the less CYA is on one's mind.
What Yehuda said.
Also, assuming the triviality also corresponds to its triviality to fix, go ahead and fix it yourself.
For example, I noticed recently that some of the text in our log files was mispelled. I fixed it. Took less time than it would have to log it.
Hi Eric,
You are talking about a veru interesting topic here. In my opinion, if you find a bug, you must report it, spending as little time as possible. And then you, or someone else, can decide if fixing it, or not.
Congratulations for your blog.
I dissagree, because many times PM comes to QA Team and is not happy if there was some trivial bug, they always ask how come out QA Team didn't find it, and some user that doesn't have any IT skills and isn't informed about the product as we are, did find it. I think that it isn't on tester to make priority, maybe QA Lead, but it should be done by PM while they organize developer's time and discuss with client on daily basis.
This is only true for freelancing testing, because frelance testing sites (etc. uTest, Testlio) don't care about low priority bugs and tend to make as much reported bugs as they can to be low priority. This is probably because they pay mostly for medium and high priority bugs, and low isn't paid or is paid minimum fee, so they always note to testers not to report it.