Quality means bugs

Reading Time: 4 minutes

No, not that little fellow, I mean software bugs 🙂

Introduction

I’ve had a lot of conversations with co-workers on whether a bug should be logged or not, and I really enjoyed some very creative excuses on skipping the defect tracking part of the debugging process. I don’t know if it’s ego, or simply attempting to make the work less formal or fear but in my honest opinion it’s a huge mistake and it could pretty soon stab you in the back.

Insectophobia or defectophobia

I mean, there should be a proper name for “fear of software bugs” or may be “fear to admit you are a human and you make mistakes”. I can’t say for sure it is exactly fear, but it’s in most cases some kind of discomfort when a person doesn’t matter if QA,  developer or even a project manager, has to report an issue. And this is where the silly excuses start:

“I’m wondering if it’s an issue or it’s the way it works” – well newsflash – wondering wont make it any better so read the requirements and if they are not clear enough, just ask, developers don’t bite… normally.

“If it’s not an issue I will look like an idiot” – but if it happens to be an issue you will be an idiot for sure. You will never learn anything if you don’t try. We as testers make mistakes, too. And this is how we learn.

“It’s a minor bug, we can skip it for now and log it later” – this is kind of tricky, because what’s a minor bug? Google says nothing, because there’s no theoretical definition on what’s minor… well of course it’s a bug with low importance but what’s low importance, then. If you are making a video game some of the NPCs might behave a little bit moron-ish and this might be completely fine if it doesn’t affect the overall experience – Assassin’s creed 3 had a lot of these, but let’s say you work on a medical software for brain surgery or autopilot on an airplane – what’s minor bug there? Just a small crash, I don’t think so…

“Don’t log this one it’s an easy fix” – You will hear this a lot during your QA career from the developers and you will know that they do it because they want to reduce the formal stuff of reading and writing solutions in bugs, because it’s really boring, but hey we are all humans, are we … and we all forget. And if you forget to log it and they forget to fix it, it will be all your fault when the client finds it and asks why. And one more thing, what will happen if you keep that work flow but you work in a huge software project with a lot of issues? You will find a developer with incredible memory or you will just log the issue so you are sure it’s there waiting for solution ?

“I don’t want this to affect my defect trend” – this is a good one, well to have a defect trend you need defects, right? And it’s purpose is to actually measure how well you are going on fixing them. So if you don’t log any or if you log only the “important ones” you will corrupt your results, which will make the trend totally useless.

No bugs doesn’t mean high quality product

If you use more man to man approach on reporting your bugs, let’s say via skype or by personal meetings, that’s also good, this way you improve your skills as a team, but this isn’t always the optimal solution to achieve high quality product.
Once I asked a co-worker “Why aren’t you logging any bugs, but reporting them via skype?” the answer was “Because it’s faster”. So I asked “How are we going to prove we’ve done any work on this if there’s no hard evidence for it, like bugs found?” the answer was “By a high quality product”. Now, this is misunderstanding – I wouldn’t consider a product that has 0 bugs in it’s bug tracking system a  high quality one, but rather a timer bomb waiting to explode. It’s very important for the QAs to realize that from the perspective of a non-technical user/client if a software product goes well and has no bugs, it’s always due to the developers’ amazing coding skills, but if there’s some bugs after the release – it’s always QA’s fault. It’s life, you may disagree, but you can’t change it. So, save yourself some pressure and log your bugs where they belong – in the defect tracking system.
Yes I know what many of you will say: “What if I work with amazingly skillful hyper-ultra-uber-senior-master developer that never makes mistakes?”. Well, I’d say, I will really like to meet this Obi-Wan Kenobi of software development myself, but until than, they are all under suspicion. It’s simple, until there’s people writing the code and people testing it, there will be mistakes, it’s up to us to find ’em and fix ’em, or leave them and look like fools.

Don’t get me wrong, not that we have to be proud of how many defects we’ve fixed, that wont make us look professional, too, but having bugs is part of the developments process, don’t be afraid to deal with it.

 And that’s true, too. You will never be able to find all the defects and fix them, but at least give it a good try and make sure you are releasing a good quality product.

Conclusion

“There is no war without victims” they say and I will add “and there’s no software without bugs” and during your career as a software quality assurance you will have to find them and report them, this how it works. There’s no silver bullet for it, but try to follow the workflow, people didn’t invented the bug tracking tools just because they are cool, but because they are useful. And after all we are all humans and we make mistakes and by finding them and fixing them, we improve and go forward. Don’t be afraid to face issues and fix them, this will make you only a better professional.