Tag Info

Hot answers tagged

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, ...


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 ...


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 ...


6

I would report the issue, but describe clearly that I cannot reproduce it. As a tester it is not my call to decide how much effort is put in reproducing the issue. I think we have signaling role. Risks Its nice if the report contains an estimated risk, do real users have problems and is it possible they get stuck and maybe cannot use a certain feature, ...


5

If you have specifications that say a confirmation must be displayed, the test fails. If you have user requirements or user expectations that there will be a confirmation dialog, the test fails. In the situation you describe, I would create a bug from the test, but it would have a lower severity rating because it doesn't interfere with functionality. The ...


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.


3

The problem should be reported, with a note in the report that you can't reproduce it consistently (or at all) and that you will update the report as more information is available. Your next steps should include some mix of the following strategies: If you can increase the level of logging, do so and leave the logging in place until you get a repeat of ...


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 ...


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 ...


2

It may depend on the strategy of your project, but i'd say this test is failed. If the confirmation is part of your specifications/functional need, you can't make this test pass. Imagine this is the only issue in your whole test plan, if you pass the test, then your indicators will be all green for this functionality. Thus, there is no reason to do rework, ...


2

When publishing data into the public you should always anonymize the data, not only log-files. Also e-mails, documents, etc... You could try the open-source Python based log-anon. This tool was designed to replace sensitive fields in customer's logs with anonymized values, while generating a lookup table. This is sometimes useful to comply with ...


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 ...


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 ...


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.


1

Globally, you want to determine the risk and take appropriate action (which may be no action). So you really want to know what the effect of the bug is, and how often and/or likely it occurs. If its rare and results on some minor UI anomaly, its not worth pursuing. If it happens every time on your landing page, or you're losing customer money, then at a ...


1

Report the bug. The developer(s) might not be willing or able to address the problem for one reason or another, but the developer(s) can't address the problem if it goes unreported. Give as much detail as you possibly can. I remember a bug I saw a few months ago which only occurred because the user was running Internet Explorer as a specific account in a ...


1

Apart from what others have suggested, you can also try 'Session Replay' tools. You get to see the exact actions performed by the users at the time when errors were logged in the backend. This has a great effect on developers. When they see this, they instantly believe that something is wrong and drive it to closure. I don't know if there are any ...


1

Raise it anyway and give as much detail as possible (time, date, error log, test evidence, etc.). If it affects something further down the line, this will cover your back if a project manager or stakeholder asks why something wasn't done about it. I've experienced that a few times, where something's not reproducible so the developer just says "I can't fix ...


1

I am unaware of any standard definition for "Software Reliability Report". And an internet search doesn't show anything either. So you have 2 options: Ask management what they want in the report, or if they don't know, ask them what the report is for and use your best judgement. Make something up. List of known defects, supported usage scenarios, ...


1

The severity is to know the impact of the issue on the health of the software whereas the priority is to order it for fixing. The crashes are always logged at highest severity . However if its in the main flow of the application, its priority will also be high whereas if the crash encounters in a very rare scenario , the priority is set low , generally.


1

Checklist for publishing a good bug report: Look for duplicates Check for accuracy in all elements of the bug report Role play as a different recipient (for example, a Test Manager) and ask if the bug report is really useful to them Make a list of mistakes in the past with bug reporting and run it through the report Check for attachments, their sizes and ...


1

I would separate the test case into 2: The first one ends with the confirmation message and the second one continues from there on. I would create a bug, link it to the first test case and keep the test case in 'ready', while I would close the second test case. If this is not a major requirement for you, then the test cases can be prioritized, so that ones ...



Only top voted, non community-wiki answers of a minimum length are eligible