Is there? Eh… I think not really.
I’ve seen a number of posts that imply a good QA person should only report or talk about significant bugs.
And it’s understandable. We’re often faced with tight deadlines and have to do something–anything–to get the product pushed out.
So, some unexpected behaviors that we know are bugs are considered trivial.
They won’t hurt anything. Probably. And there are bigger bugs to spend devs’ time on.
That’s a good policy to have, except for when it’s not.
So: Is it actually trivial, or is “trivial” just a euphemism for “we don’t have time to fix it”?
To me, a bug is like cancer. A small amount can become a big problem if you leave it in there long enough.
I’ve seen “trivial” bugs stay in code, and cause problems later on, just because the code “mixes” around and the bug comes more to the surface, where then it causes problems.
With software being as complex as it is, there’s a chance that a bug which is considered trivial can become non-trivial later on.
Who knows what other software will touch/use that code?
Trivial Bug Fallout
If we’re letting bugs stay in because we don’t have time to fix them, then it’s likely because the software’s so complex that we have to decide what bugs to focus on.
I’ll get to why this is a symptom of a larger problem later.
Software will continue to get more complex, which will lead to more bugs (unless there’s some kind of breakthrough on that front). So there will be even more trivial bugs putting products at risk.
Bugs that are left in cause workarounds. When everything’s working well, people only have to be aware of the code and how it works, and how the tests interact with the code.
But with a bug left in that will be fixed at a later date, now people have to be aware of the code and the bug, and the tests and the tests that will continue to fail until the bug’s fixed.
This is a lot more information to have to lug around in a brain, and it increases the chance of problems.
Consider too, onboarding.
Usually what happens with a new person is they find out the hard way there’s a bug requiring a workaround.
If the cycle of “oh, yeah, that’s a known bug. Sorry lol” happens enough, then the new hire eventually gets two messages:
a) This team is kind of rickety and their stuff’s in a perpetual state of brokenness, and
b) I’m not sure what to spend time actually raising bugs on so… maybe I should keep my mouth shut.
I’m sure you can see how this would be a problem.
How would you feel if you got in a car with a person who is busy fixing the car with duct tape while they’re driving?
How would you feel if you got in a company with a team who was constantly using workarounds and explanations instead of fixing the problems?
The Larger Problem
I don’t believe any bug is trivial. A bug is unexpected behavior in code.
It could have a negative effect, and usually does. Occasionally though, it could be something that isn’t causing a problem directly, but could later, depending on how the code organically changes with time.
Right now it might not be hurting anything, and there may be workarounds in place.
Right now that freckle on your arm might not be a problem… but one day it could be.
Maaaaaaaaaybe you should get that looked at. I’m just sayin’.
If having these small, trivial bugs is a given, then there must be a larger problem that results in them.
I believe it’s because the rate at which we’re expected to produce software.
Yes the market drives software to be done quickly, because we have a need for instant gratification. But if this comes at the cost of destabilizing the software, it’s not a good idea to ship quickly.
If you need to ship quick, here are some tips which are meant to mitigate bugs:
Don’t code so much. You know how many times I’ve seen teams try to cram 4.53592 kg of crap in a 2.26796 kg bag? A lot. And it destabilizes the codebase when that happens. Just don’t code so much! Find out: What is the minimal marketable thingie that you can make that provides customer value? Ship that. I mean, test it first, of course, but ship just that. And then ship the next small thing. Small.
Refactor ruthlessly. Refactoring will help churn the code around, and get hidden bugs closer to the surface. As you refactor more, it not only shrinks your codebase, it provides fewer places for bugs to hide and makes it easier to maintain. If you can’t refactor or you don’t want to, that says you probably don’t have enough…
Unit tests. Get you some. Unit tests are the smallest, lightest, cheapest way to get pretty good protection for your code. You can move and jostle your code and have a good idea if you broke something. Fail early, fail often. Not all the time, but. You know. When you stop failing, it’s time to ship. Maybe.
Finally, automate your tests. The technology is out there for you to kick off unit tests, integration, system level, functional, whatever kind of test, so that the only thing you need to worry about is writing production code, or writing test code. As soon as your production code changes, the tests can run–start with the quickest running ones, then build up to the longer running ones–and you’ll know sooner whether you broke something. Basic Continous Integration 101 here and it’s fairly easy. You should be doing this.
Anyway, the key to getting rid of small bugs–trivial ones as it were–is to make it so you can stir your code around regularly. Get in there and start moving things around, and see what happens. Touch stuff. Turn over stones and find the grubs.
Hey, I went independent! Arch DevOps, LLC was launched early September 2015. Turns out what I’m doing is testing, automating, continuous integration/delivery, and that’s DevOps. Here I thought DevOps would be a complete career change, but apparently not.
So I rebranded. Neat!
I look forward to the chance to see how I can serve your company, and help you drive quality with test-centric automation.