Categorising bugs can often be more complicated than we think.
I once set up a Jira instance and got in a right old muddle trying to cater for everyoneās needs across the product development team. The bug issue type had so many options such as priority, severity, impact, type, likelihood, steps to recreate, expected result, actual result and probably much more. Makes me feel a bit awkward thinking about it.
In another place, we used a bug-tracking process that was established beyond our remit so we couldnāt change it.
And in my current setup, if we find a bug we add it to a dedicated Slack channel for our developer (@testingchef) to investigate/ask questions.
Taking a step back thereās often a debate across development teams about how to categorise an observation. Is it a bug, feature, idea, problem, issue, fault, defect etc?
Iād like to hear about your experiences with the places youāve worked at. How did you/do you categorise bugs? What did the bug process look like? Whatās been your favourite setup and why?
AI-generated replies will be deleted so donāt waste your time and MoTs time. We have better things to be doing with the community than reviewing AI-generated content.
Currently we keep it simple:
Create a ticket, which goes into the review with the PM.
Depending on current priorities, it goes in 3-4 bins: fix now, fix in a few iterations, backlog-set-and-forget, backlog-review-later. The priority is put against the general scope at the start and even during an iteration, so the ticket might get moved.
Sure there are a few flags most of which arenāt relevant, except for potential future statistics purposes.
Whatās important for us is that the summary and description is clear enough that the issue is easily placed in our mental models with a first quick look.
In one place (long ago) we used severity and priority like this: The severity was for the QA person to decide, depending on how bad the problem was. The priority was for the product manager to decide.
A good example about when a Sev-1 (Work cannot continue at all) is not a Prio-1 (Will be fix ASAP): One morning my PC wouldnāt boot - as it turned out the disk controller was broken. As there was no other computer I could work with ā Sev 1. However the IT support team rated it (relatively) low in priority, as they were dealing with another issue: WiFi on the C-level floor stopped working.
In most projects, we āonlyā used priority and issue types (bug, improvement, epic, task, new feature, story and others. I find these types less than ideal, especially because they overlap considerably. A bug ticket may turn out to be epic, be an improvement, require a new featureā¦
I provide a detailed description of how to reproduce the behaviour and if possible an automated test that does it. The devs can run it, see what expectation isnāt met, and know when we might consider the behaviour to be OK (again). ā Thatās not always easy (or even possible), but still striving to for this is a good way.
This also helped me to think hard about the specific circumstances ā¦ and to skip actually submitting the ticket when I realised that my expectation of the system behaviour was wrong.
Whatās the difference between these two? Are ābacklog-set-and-forgetā there because the team/project wants to capture all items ā perhaps useful to spot trends, count metrics, or something else?
things we might never do (in the current roadmap for the next 2-3 years it just doesnāt fit);
** sometimes these get closed due to triviality;
** other times these stay open, to know about them until a client/stakeholder asks for them;
I use Azure Board for bug management and tracking and have also worked with Jira Board.
The product I am working on doesnāt have formal requirements; I test it and report bugs based on reverse engineering and my understanding of the product.
If I feel the requirements need clarification or if Iām unsure about the expected output, I assign the bug to the client and mark it as āTriageā status.
and based on the clientās comments (e.g., āDeleteā button not implemented as per Clientās comment), we update the bug and convert it to a āTaskā. This task is then estimated and taken forward by the development team. Once the task is completed, it is assigned to the QA team for testing. If the task ticket is working as expected, I will move it to āCompletedā status with comments.
If not, I create a bug, link it to the task, and assign it to the developers. Yes, we have a process to link the test cases to tasks or bugs wherever applicable. If the bug are of low priority/ Severity, we place them in backlogs for later iterations.
We create bugs under specific module-wise user stories for better tracking.
hi, we use jira for project/defect management ā¦Our Application is built using microservice architecture , so when a defect is raised we usually categorize it based on feature tag and also a label to which service it belongs to ā¦ Helps us keep track which features/services are buggy
In my organization, We have set up different Jira boards. For stories, we have a separate board on which PM only creates stories and tasks. For testing, we have a separate board and a separate board for prod bugs, so the team is sure which ticket falls into which category. A separate board for a prod bug is required because Every Prod bug is investigated, RCA is analyzed and then it is decided whether it is a known issue or a new prod bug. Sometime such investigation takes several days so as there is separate board specifically for such issues it donāt cause much confusion and helps in keeping clarity.
Now in case a bug is converted and declared as a feature, then the bug ticket is marked as Abandoned and a separate task ticket is created by PM.
As far as any idea is concerned, if the idea is accepted as an improvement then a task ticket is created on the storyboard however the word āImprovementā is added as a prefix before writing the summary input field of the Jira ticket so that the team is clear that it is an improvement to any existing feature.
If there is any problem with any feature then we either raise it in the group chat in Teams or mention it on the PRD of the respective feature or module by tagging PMs.
I prefer to keep it simple, so yeah, some fields describe a bug, and there are Priority and Severity. These two fields are quite subjective (at least I prefer them like that - without strict policies, etc., because they only bring unnecessary complexity), and different aspects may affect whether it is, for example, a Minor or Major bug. Priority is something I prefer to discuss with the team and stakeholders, but Severity might also be affected by their point of view. I can even add some verbal explanations to categorize certain bugs/issues/tickets, such as āfix/implement it ASAP because later will be too lateā My general approach is to avoid complexity, keep things simple, avoid strict descriptions and rules, and communicate with the team and business
AI-generated replies will be deleted so donāt waste your time and MoTs time. We have better things to be doing with the community than reviewing AI-generated content.