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

I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...


8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


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


6

First, it is absolutely professional to ask for more information when you've made a number of attempts to reproduce the problem and haven't been able to do so. You've effectively eliminated the most obvious potential problems with your attempts to reproduce, so the cause is something less obvious: it could be the customer using a different configuration, it ...


4

Some thoughts here: how healthy is the situation where bugs are logged by project members other than the actual qa member who is the dedicated personnel for quality? This is normal - anyone can log a bug. The team decides which bugs are in scope for the project and which need to go into the main backlog. The team decides which bugs get fixed when ...


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


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

When you say that bug triage is impossible (or improbable), you need to determine the opportunity costs associated with that: In the case where no triage is performed, there is the probability that a single or multiple developers will attempt to fix the same bug. At minimum, there is wasted development time that could be focused on other areas. Worse, the ...


3

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

Anyone who has access to the application should be able to file bugs/defects. Defects should be filed in a bug tracker with a status new. New defects should be verified and extended (With at-least a reproduction path) Defect should be added at the top of the backlog (Keep a no defect policy when being Agile) Products Owners should monitor new incoming ...


2

I agree with the others, anyone should be able to enter bugs. One comment on: Especially if they are not well described with steps to reproduce? If the bugs being entered are not productive, I would invest some time those people to train them in the art of great bug writing. You just might make a great tester in the end.


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


2

Bug triage is very important, especially when time is limited. Bugs have different levels of severity. Examples include very high: someone may die as a result; high: the company may lose business; medium: the customer will be upset; low: there is a minor spelling mistake. The actual outcomes and severities depend upon the organisation. Bug triage is about ...


2

At my company around 150 Full time employees with 15 developers on staff, and a support team who receives all the inbound calls, if the bug is not easily reproducible, it is researched by a tier 3 support team. If they are unable to reproduce the issue, they will normally check with other system experts such as the QA team. If we are still unable to ...


2

This situation does happen occasionally with our application. What we do is to capture as much information as we currently know about the issue and to continue to collect information until we have a reproducible set of steps. It helps if the issue is duplicated at more than one site since we tend to get a little more insight that way. The issue remains an ...


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


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

This is going to be a bit unpopular, but I am going to have to buck the tide on the answers so far. I agree that it is important to allow everyone to submit potential defects and that system should be as clear, helpful, and accessible as possible. However, I have found that it is important to separate the "official" bug list that the team is working from the ...


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