I hate “Invalid bug” label from developers for the bugs reported by me, do you? I think every tester should try to get his/her 100% bugs resolved. This requires bug reporting skill. See my previous post on “How to write a good bug report? Tips and Tricks” to report bugs professionally and without any ambiguity.
The main reason for bug being marked as invalid is “Insufficient troubleshooting” by tester before reporting the bug. In this post I will focus only on troubleshooting to find main cause of the bug. Troubleshooting will help you to decide whether the ambiguity you found in your application under test is really a bug or any test setup mistake.
Yes, 50% bugs get marked as “Invalid bugs” only due to testers incomplete testing setup. Let’s say you found an ambiguity in application under test. You are now preparing the steps to report this ambiguity as a bug. But wait! Have you done enough troubleshooting before reporting this bug? Or have you confirmed if it is really a bug?
What troubleshooting you need to perform before reporting any bug?
Troubleshooting of:
- What’s not working?
- Why it’s not working?
- How can you make it work?
- What are the possible reasons for the failure?
Answer for the first question “what’s not working?” is sufficient for you to report the bug steps in bug tracking system. Then why to answer remaining three questions? Think beyond your responsibilities. Act smarter, don’t be a dumb person who only follow his routine steps and don’t even think outside of that. You should be able to suggest all possible solutions to resolve the bug and efficiency as well as drawbacks of each solution. This will increase your respect in your team and will also reduce the possibility of getting your bugs rejected, not due to this respect but due to your troubleshooting skill.
Before reporting any bug, make sure it isn’t your mistake while testing, you have missed any important flag to set or you might have not configured your test setup properly.
Troubleshoot the reasons for the failure in application. On proper troubleshooting report the bug. I have complied a troubleshooting list. Check it out - what can be different reasons for failure.
Reasons of failure:
1) If you are using any configuration file for testing your application then make sure this file is upto date as per the application requirements: Many times some global configuration file is used to pick or set some application flags. Failure to maintain this file as per your software requirements will lead to malfunctioning of your application under test. You can’t report it as bug.
2) Check if your database is proper: Missing table is main reason that your application will not work properly.
I have a classic example for this: One of my projects was querying many monthly user database tables for showing the user reports. First table existence was checked in master table (This table was maintaining only monthly table names) and then data was queried from different individual monthly tables. Many testers were selecting big date range to see the user reports. But many times it was crashing the application as those tables were not present in database of test machine server, giving SQL query error and they were reporting it as bug which subsequently was getting marked as invalid by developers.
3) If you are working on automation testing project then debug your script twice before coming to conclusion that the application failure is a bug.
4) Check if you are not using invalid access credentials for authentication.
5) Check if software versions are compatible.
6) Check if there is any other hardware issue that is not related to your application.
7) Make sure your application hardware and software prerequisites are correct.
8 ) Check if all software components are installed properly on your test machine. Check whether registry entries are valid.
9) For any failure look into ‘system event viewer’ for details. You can trace out many failure reasons from system event log file.
10) Before starting to test make sure you have uploaded all latest version files to your test environment.
These are all small and common mistakes but can mostly impact on your relations and credibility in your team. When you will find that your bug is marked as invalid and the invalid bug reason is from above mentioned list – it will be a silly mistake and it will definitely hurt you. (At least to me!)
Share mistakes done by you while reporting any bug. This will help other readers to learn from your experience!
If you like this post then join our email newsletter. Click Here to get new article notifications via email.
19 comments ↓
Very informative. Keep it up.
It seems there is a small spelling mistake when you said:
“… it will be a silly mistake and it will definitely heart you. (Atleast to me!)”
Shouldn’t it be:
“it will be a silly mistake and it will definitely hurt you. (Atleast to me!)”
Thanks Meraj for pointing out. Just can’t avoid auto spell check suggestions
Vijay, great points. Testers should be striving for a 100% actionable bug count - most of that involves being sure they write actionable bugs (bugs which are true defects and which management can make a decision on), and to a lesser degree it involves advocating their bugs.
As a test manager, I track my team’s actionable bug stats ensuring they are effective. It’s not the most important metric in a tester’s performance, but (like cricket or baseball stats) it shows areas where a tester or a team can improve.
John O.
http://thoughtsonqa.blogspot.com
Good article but I disagree with “You should be able to suggest all possible solutions to resolve the bug…”
Possible solutions can often only be found within the code. For a white box tester it might be good to look into the code but is it really his job to search for the bug and propose a fix? I doubt, cause if he found it then he could just fix it. That’s the job of the programmer since he is the one with the background.
A blackbox tester will hardly look into the code. What he might suggest is a solution for a change request, e.g. handling of software, etc.
It is very important to verify the testing setup before executing any test case or test plan, other wise at the end of the day you will find more than 50% of the bugs found are invalid & that really hurts. Final output is that you might miss few important bugs & eventually with correct setup all test cases execution will start from scratch, waste of efforts & time.
Apart from this its really annoying to the programmer to debug an invalid bug to find the exact problem in the code, & after hours of debugging efforts, when it comes to know that the reported bug is invalid, programmer will definitely feel angry, & the tester will loose the respect from the programmer.
One of my experience that while testing some configuration security rules of the application I miss out to set the correct value for the configuration parameter while testing I found a bug which was producible only because of the incorrect configuration parameter value, bug assign programmer waste more than a half day to debug the problem, but he couldn’t able to reproduce it, eventually he found real cause of that bug (incorrect configuration variable). People start doubting tester’s ability & productivity just because of INVALID BUGS. Hence my very kind advice to all my tester friends please verify the test setup before executing any test.
Vijay,i think it would be better if we check the above steps before we start actual testing.(Ready with the test bed)
[…] if your data is not corrupted: Filing a bug without improper troubleshooting is bad practice. Before executing any test case on existing data make sure that data is not […]
Although no tester would ever want to see a rejected Bug report, still it is a part and parcel of our profession. Bugs keep getting turned down as rejected/invalid due to various reasons from time to time.
What would you do if your bug gets rejected by the programmer? Would you cry over the spilt milk or would rather take corrective actions to revive it? Here is a post that I had written few months back that you might find interesting! - A A Tester’s Dream - 5 steps to revive a Rejected Bug!
-Debasis
Please can some one help me ” where to find the system event viewer”
For any failure look into ‘system event viewer’ for details.
Hi Vijay,
I recently got information of this site.
I have read some of your articles so far.
Each of them has got really useful material in it.
Can u please tell me, how to test an application which has been developed based on another product like Busines Objects or IBM Websphere etc It occassionally happens that while testing this type of applications,testers give bugs which are related to the product itself rather than the application under test.
Thanks for this article vijay. It is very important that testers log bugs which have very least chance of getting rejected. Logging invalid bugs not only hurts your validity as a tester but also wastes a lot of time both on testing and development side.
I want details about white box testing techniqe….
Realizing you won’t be able to test everything - how do you decide what to test first?
Can anyone answer this question?
Hi Thiru,
How r u ?R u able to do QTP now.fine
white box testing is all abt testing the inner functionality means completely involving into the applications means getdown into the coding section.Logic they are used and some other cases.
ok
Thanks,
Haripriya
it’s superb….
very informative. it really help to improve bug reporting skills.
Hi Vijay,
It is Very Good Article,for Upcoming Testers..
Hi All,
I am a new member of this community and found the stuffs quit useful and interesting. I have around 2 years of exp in this field with a reputated US MNC.
In future i will try to involve myself with the articles more.
Best of luck
Hi all,
Oftenly I face the problem of rejection of my bugs.I think is because of lack of domin expertise,improper communnication and undersranding and interpretating,lack doc related to change request and even deve egos…As a tester we must be proactive in accomplishing the requirements for good testing of the appli…Tester should be in the commdnding position, but it is other way around in many organisations.Tester should have eagle eyes and heart of a child to create better working place
Dear navitha,
It better to do functional testing when u get a build after doing smoke for all ur concerned modules/application…
Leave a Comment