In my testing career, I have seen testers being pessimistic about the unaddressed bugs. I have heard sometimes “What is the use, even if I file it?”, “they will never fix it”, or “Leave it, they will not be able to reproduce it”. Sounds true!? Such reactions should not be the criteria to stop logging low priority bugs. The perception of a bug differs as we move from department to department or start climbing the management ladder.
The same “hey, it works as designed” bugs sometimes becomes one of the important bug which has to be fixed as soon as possible, and from corner-of-the eye I can see, once disappointed tester now smiling.
It is natural to get disappointed if the bugs are marked as “INVALID”,”WONTFIX” or “WORKSFORME”, but at the same time it provides ample opportunity to the individuals to learn, understand and grow as experienced professionals by analysing the root causes of it.
A bug as defined by dictionary is “A fault or defect in a computer program, system, or machine” but when taken in verb form it means to “Annoy persistently”. The bugs if not handled properly, will keep annoying us. To understand bugs we have to understand their stories. And to stop them from annoying us we have to understand the difference between Ego vs. self-respect and creating vs. existing.
Bugs have Stories
Every bug has its own story and tester is the story-teller. If the story is not told properly, the audience cannot understand it and they will start asking questions. Try watching a movie with Kids, they have lots of questions to ask and you have to answer each question patiently or explain them the story thus far and they will continue to watch it happily without bothering you. In the same way, if the bug story is clearly explained starting from how it looks like, when it occurred, in which way it occurs every-time, in which scenario it’s not observed and when we have captured the intricate details of it then it will not bother us.
Once the story is told to the audience, the work of the story-teller is finished. Now the response of the audience will be decided by the type of story (severity of the bug) and how well it is presented.
Even if initially the bug could be rejected (as it may be not reproducible) but if you present it in a different way and make the developers and the involved team understand, you could as well win a bug bounty of 12,500$ as one of the individual got from Facebook even though initially his bug got rejected. He made a proper video and showed Facebook Inc that it’s a security flaw, and he was awarded. There should be synergy between developer and testers, if testers can make developers understand the criticality of the bug it becomes imperative and it will be fixed.
Ego versus Self Respect
Ego comes when we start thinking that we are the best, and when we start comparing ourselves with others. In this process if we come across some bugs which were rejected, it hurts our EGO and we feel hurt. But if we know that we did our best work and the issue we filed is valid, then that boosts our confidence and self-respect. When we respect ourselves, nobody can hurt us. We should not fall in trap of EGO; it has tremendous power to make self-inflicting wounds.
Self-respect also comes when you have domain knowledge. Question each and everything that causes doubt in your mind. ”Why apple falls? “A simple question resulted in discovery of gravitational force. Issues can be seen from outside but when you know the internals of the system then you can find real issues in the system and log bugs efficiently. When we identify the real issues then certainly it can be fixed.
Ego comes from comparing ourselves with others and self-respect comes when we compare our past to present. For becoming better we have to learn, enhance our skills and be better than yesterday.
Creation versus Existence
When we create something we get emotionally attached to it. We want to protect it; we seek appreciation for our work. The things which are already into existence, we use it and move on to next thing. Bugs are not the tester’s creations but were part of system even before it was discovered. When a tester finds a bug, he/she is only discovering which was in existence even if it was never discovered.
Once we understand that bugs always existed, and we are merely a keen observer whose job is to find it and help the team to fix it, life becomes much easier for a tester and a developer. Defend your bug to a point where you don’t take it personally nor hurt anyone professionally. If still there is no result, it’s still fine, analyze it and understand ways in which it could be presented well or ways in which we could have found a higher priority bug in the same feature or functionality and move on to next issue.
Kill the bug not the relation
We should not write bug reports which reflect the problem of an individual developer, but it should be specific to the feature. Let them understand we are doing our job to make the product better. Maintaining healthy relationship with the developer causes many small but important bugs to be fixed fast.
Every bug like humans has a complete life-cycle. Filing bugs is equally important as having them fixed in the product. We should always file the bugs even if it seems very trivial, but we should not get annoyed or disappointed if it’s not fixed. Every feature and every product poses new challenges, once bug is filed its time to move on and keep hunting. Life is made up of many events and each disappointing event offers opportunity and assists us to turn stronger and better. Don’t let any bug, bug you instead analyze it, report it and let it go. Happy Hunting!
About the Author
Sujata Verma has over 14 years of experience in Software industry and is working in Proxim Wireless as QA manager. She is responsible for complete system level product validation. Prior to joining Proxim, she worked in Analog Devices and Ikanos Communication and has extensive experience in Embedded and network domain device testing.