Because at times, one bug can be considered a coin tossā¦ but two bugs, on the other hand, are quite substantial proof. 
So which team are you on the instant reporters or the bundle droppers? 
1 Like
Hey @ramanan49 , it all comes down to context. The volume of bugs does not necessitate seriousness. The scope of where the bug is and the āriskā to the ācore functionalityā has to be considered.
Additionally, it would depend on how your team operates.
- Is this not meeting the Acceptance Criteria,
- Was this area of functionality considered in the change,
- Has this story introduced the bug, or was it existing and not noticed,
- Is it user-facing.
Whilst you are correct, one bug can cause the old spaghetti pull, where it can also manifest elsewhere - that is where the investigation of the QA / Tester comes into it, along with skill and knowledge.
My approach - āHey Mr Developer, I am seeing this - did you get the same when you were testing it, and any thoughts on how it got thereā 
Bugs do not appear - they are developed.
3 Likes
I provide a list at the end of a session.
2 Likes
If one bug found is not enough to sound serious, then you have another issue which is not in the product under testā¦
Iām definitely an instant reporter. But from my experience being operator for emergency service, I know how powerful it is being a quiet one, so that your voice has more echo when you open your mouth.
2 Likes
For me it depends, if itās something related to the tested feature/product, it would go in my long list of feedback that I provide once Iāve finished my tests.
If itās unrelated, the dev for the project would get a new task for the issue and Iāll leave it to them to sort out whenever.
Each project team has its own slack channel and as soon as we raise a bug, we share it. For Jira we created a new subtask called āstory bugsā so stories and regression testing tasks will have bugs added to them as subtasks. As per our definition of done for standard issue types, all subtasks need to be resolved but how the story bugs are resolved is a matter for discussion. Ideally fix them, but if the we collectively choose to defer the fix due to the bug having a low impact, weāll convert it to a Bug as a standard issue type and move it to the backlog.
I certainly donāt believe in hoarding them until we think we can convince others theyāre important enough. That sounds very āthem and usā so I would suggest if anyone adopts that tactic, they have deeper problems with culture.
2 Likes
I suspect this is more of a communication question rather than a testing one.
If the developer is looking for a rapid feedback loop I will often flag the basics of an issue to them telling them Iām going deeper into it. I do this because some developers will know immediately what the root cause is and can let me know and others will happily wait until I have full information.
That similarly applies to the one or many, if they are really busy its going to annoy them with pings of one issue after another and theyāed likely prefer a grouped bunch of about ten with full details. If they are sitting waiting ready to work on things it makes sense to drip them as I find them.
No hard rules on this, different developers have preferences and it makes little difference to me so I adapt to what suits them.
The sound serious part, probably not relevant for experienced testers who are very comfortable and experienced in making judgement calls. Junior testers I tend to advise to go deeper, find out as much as you can, related issues, issues hidden underneath, take their time and give as much info as possible, others can judge seriousness.
4 Likes
I tend to report quickly, though if there are a few minor bugs, Iāll batch them up.
If itās a serious enough bug, Iāll focus on that and bring someone else to confirm before I move on.
Little niggles will likely get saved up and Iāll write them up when Iām ready to share my testing results. However if anything is a must fix, Iāll raise it sooner. Or at least ping the Dev to say FYI, this is incoming later.
1 Like
The only time that Iāve ever felt it was acceptable to properly queue up and hold on to bugs was when our bugzilla was nearing bug id 20000. I found and drafted 15 in the day and started submitting them as soon as bug 19985 was entered.
2 Likes
It really depends on what we are validating (a ticket or the entire feature before release) and what the bug is.
If we are validating a ticket for an engineer, we report feedback as soon as it becomes available. Engineers need to move on to their next tickets, so we want to get things back to them as soon as possible.
If we are validating a feature before release, then we report critical bugs as soon as we find them in Slack channels and create tickets for minor things that can be fixed later.
2 Likes
Instant reporter here. Sometimes, I even throw up a red flag, meaning that I canāt always reproduce it, but Iām working on finding reproducible steps. I want everyone to be aware of any issue I find, even if itās just the hint of one.
6 Likes
Me too in this Approach !!
For people who like to report immediately even if you donāt have reproduction steps, have you ever had to deal with someone reviewing the bugs you enter?
In my previous workplace I used to encourage adding something to Jira/Bugzilla ASAP, however there was some senior folk in a different continent who would leave snarky remarks about incorrectly filled in bug templates (even if I had a line saying āThis bug is WIP as investigating to get more informationā). Many people (sometimes including myself) ended up not putting them into Jira until understood, but this meant visibility was poor and discussion was recorded on Slack, not the ticket.
1 Like
First time we encounter an issue we refer to it as āObservationā and if the stakeholder sees it as something which needs to be addressed or fixed, we go and convert it into bugā¦ 
1 Like
I have mixed feelings on not reporting issues. I like the simplest bug report possible then closing wonāt fix as it records that weāre accepting a quality issue ā¦ plus from my experience someone else will raise the minor issue and youāll debate it all over.
1 Like