Bugs: Should we go for numbers?
Background: One of the primary job of QA team is to find bugs in the application under test and there are situation when QA team bombards with number of bugs to dev team. Sometimes all this is done regardless of the relevance with a motive of just to increase number of bugs in the system and putting QA team on top.
Is it an ethical practice? ... As a tester should we go for number of bugs OR with relevant bugs?
From my point of view it’s NOT. Let’s look starting from basics.
What are Bugs: Put simply any deviation from the stated/agreed upon requirements of any software application should be termed as a “Bug”. There are two major characteristics of any bug its severity and its priority. Every single bug in the system revolves around these two characteristics and the decision to fix or not depends on these two.
Browse the internet and we can find numerous articles on “Severity” and “Priority”. In simple terms, severity is application impacted/related and priority is business impacted/related. Certainly there are cases when a high/medium severity bug has low priority. Recently I saw “Blank White Screen” in my old nokia (now Microsoft) phone during normal operation but when I tried same/other operations for quite a long time I was not able to get that screen again. This certainly is a high/medium (depends on the perception) severity bug but with a low priority.
Should this be logged? Yes it should be.
Why low priority? Probability of occurrence is very low.
Throughout testing we encounter such (And other relevant) bugs number of times and in my opinion all these should be logged but the decision to fix should be left to other senior stakeholders (Leads, BA’s, PM’s). In my opinion, we should consider following major things before logging such OR any bugs:
- How much it is impacting the functionality? Functionality is completely broken or partially
- Business impact of the bug.
- Impact on end users usage experience.
- How much is it noticeable?
- Time of reporting is also an important factor. Bug reported early has high probability to be fixed rather than reported later in the cycle.
As a tester,
# Our intention should not be to increase the number of bugs in the bug tracker but we should be focused and concentrated to find out relevant bugs which actually impacts the usage of the application.
# We should find major bugs and keep a note of all little observations.
# For the sake of project / stakeholders interest we should not be rigid and should be flexible on priority and severity of the logged bug. This does not means that we should not report issues or we should be biased in reporting. Reporting should be fair.
#Better practice should be log “queries” for the scenarios which we are not sure of that it’s a bug or not. And again there should be a proper follow-up for these as there are situations when these are ignored by other team members and is released to the client and then its logged.
Retired.
10yI can't, and will never, accept that the primary job of testing is to find defects. I can't, and never will, accept that one of the primary jobs of testing is to find defects. I can accept that one of the primary jobs of testing is to prevent defects. I can accept that one of the primary jobs of testing is to provide accurate, precise and relevant data about the product that others can use for considered decision making.
Principal Consultant-Trainer
10yAmit, most of what you've written merits a mention, and are right. However, on an article of any kind, typically the first paragraph is what sets the tone...which is especially hard to alter later on. I see that you're an author, and you might realize (and possibly ignored, in this case) it more than I do. In fact, any writeup on a topic like testing (wherein, anything you say will result on a debate!), certain philosophical thoughts creep in too, even if that wasn't your intention at all. Here, the bitterness or the disagreement is on the very first line of your article. Testing isn't about bugs at all, even less so about the number of bugs. So, when you say "QA team’s primary job is to find bugs in the application under test ..", the damage has already been done. It's a generally accepted fact that testing team's primary job is to act as risk informants to the product stakeholders. I believe that's Andrew's point too.
Rebel App Studio, Software Tester, Quality/Team Coach, Test Management/Consultancy, IT QA Consultant - Mobile and Web specialist.
10yAmit, I suspect your post will do more harm than good. I respect the attempt to share software testing knowledge and ideas across a broader field but there is a lot in your article that could contribute to a significant misunderstanding of software testing and the immense value it offers. Could I suggest moving it to one of the testing forums first and getting some experienced input, it is both a good learning opportunity and it may help you the re-present a more valuable article to the broader field.