Tag Info

New answers tagged

0

Our highest bug priority is called "system failure". So if a bug crashes the server or makes the whole application unuseable, like you cant login anymore, we use this priority. For this its regardless if the bug occures on beta, pre oder live. But such bugs are normally visible in early development. Bugs which onnly "crashes" parts of the application are ...


0

Although these two terms have been used to describe defects since the beginning of software development and testing, there are still many discussions on how to set these two defect terms. I have been in the testing field for over 20 years, using many different testing tools and in many different organizations both public and private from which I have ...


0

Apparently, in your company there are at least two teams. Your team needs some functionality from application, and the other team is responsible to deliver it. Priority is just a meaningless category to prioritize work globally. You can set your own priorities as needed inside your team. You tried to ask for help from other team. Seems that help is not ...


2

As others have said, if there isn't a consistent definition of what constitutes top priority across all teams, there will be disagreement over what constitutes a top priority bug. That said, I have a few thoughts to offer: Will this bug break core functionality if it is introduced to production? If the answer is "yes" then priority should be higher. Does ...


3

You need to take a step back and look at the whole picture- why did the dev lead objected to the P0 setting ? It is not because "it is not in production" (well, it is but there is a higher level reason for that) but because the company doesn't have an agreed and accepted definition for priority levels across all teams.


1

Recently, I found a P0 bug in the pre-production environment. I am the lead QA and I refused the deployment in production before correction. The bug made a simple action not work (classical one, used by every single person of my company each day). The priority of a bug is not due to where or how it is found, but the severity and the effect of the bug. In ...


2

I would open a new bug, and refer to the old one. I would also have a conversation with the development team about the duplication, more than just reporting the bug a second time. They might not have fixed the true root cause the first time, or you are doing something that they don't expect in your testing. A conversation could lead to better learning ...


10

I would always go for opening a new issue and linking it to the old one. The defect might look similar in its behavior, but its possible the cause is totally different. If possible let another developer fix this new issue. The added advantage of having one ticket with all the info is very slim, reducing the defect count is like giving management blindfolds, ...


0

You can do following in your given situation : 1 - If there are diff. build for ex: First you have test on local server and close bug and if that same bug found in staging / production server in same application then insert that bug as NEW. So that can help us to identify some root cause. 2 - If you closed bug in staging server and getting again on same ...


1

To echo others, it depends and I'd say that it largely depends on the culture at your company. It ultimately comes down to a trade-off between developer time and tester time. The more time you spend digging into the root cause of an issue, the less time you'll spend looking for other issues. However, you will save the developer some time because he/she ...


0

I won't take anything away from what has already been stated, but I noticed that your question implies that your company may still be in the "start up" phase. If your Marketing and Executive offices intend to go "IPO" ("Initial Public Offering" meaning: you'll be listed on the stock market), then you may have some work to do. Before that happens, you must ...


7

As others have said, it depends. My usual method works like this: I find something that doesn't seem right: If it's really obvious (a typo in a high-profile part of a site, an error message that gives the line of code that's failed), I'll check with a developer to see if they're working on that code right now (this is often the case in agile or other ...


8

It's not necessary for QA to do root-cause analysis for every defect they found. It's up to circumstances. And for the level of drill-down, I did not drill to the level of source-code when I tested a Unix binary application. But I did html/css root-cause analysis when I tested a website. As a view of user I represent, I access only the information that a ...


1

Nobody can really answer it since it depends. Depends on your qualifications, your and your team work load, the dev team work load, the complexity of the issue etc. I work now in a combined engineering type team and I still can't give a definite answer to your question, your best bet is to discuss this with your colleagues and managers.



Top 50 recent answers are included