Tag Info

Hot answers tagged

9

A label is just a label. It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity* your stakeholders may take appropriate action. E.g. stop releasing the product ...


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

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


7

The severity of a bug is a measure of how important the bug is to the end user: how much it breaks, how badly it breaks things, how difficult it is to get work done with this bug in place. The priority of the bug is a measure of how important the bug is to the development team. This will take into effect the severity, but also the development time and ...


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


6

The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of: something introduced by the changes something that was there before and doesn't have much if any impact on the changes something that was there before and has a major negative impact on the changes The developers in the team ...


6

The ratings that I see in common use and have used historically are: Severity 1 - Critical issue, crash or data loss Severity 2 - Major issue, but no crash or data loss and no workaround Severity 3 - Issue, with no crash or data loss and a workaround exists. Severity 4 - Fit an finish issues. The main decision that needs to occur for each bug is "Are we ...


5

There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including: Type of application Your team size The level and frequency of "in the hallways" conversations between people on the team The number of bugs you have "hanging around" waiting to be taken care of etc. ...


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

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


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

First google Exploratory Testing. Some ideas for testing might be- yours, and your customer's expectations and needs (what is the program used for) similar programs (compare to other knowns) relevant standards, or de-facto and industry standards (from national or international standard bodies e.g. ISO/IEEE/FDA etc. other sources might be known practices) ...


3

Bug severity is the impact bug will have on the system which is basically derived from but not limited to 1]The probability of the user getting the issue 2]Reproducible rate 3]Is there any easy workaround/How easily user can recover from the impact of the bug 4]The application under test(ex : A bug of a status not updating in a certain rare scenario can be ...


3

As @vincebowdren says, start with screenshots. There are numerous simple screenshot tools (I've been using the Windows 7 snipping tool for some time now - I can use the mouse to draw a rough circle around a problem area or highlight something), many of them freeware. I'd recommend mapping a keyboard shortcut to start the screenshot tool, for speed. You ...


2

Screenshots. Take a screenshot of the document, edit the image to highlight the problem area, and add it as an attachment to your bug report along with the markdown document (unedited).


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

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


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

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

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.


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

Bug reports should be... ...Clear Bug reports should have: Precise, descriptive summaries. Informative, concise descriptions. A neutral tone, avoiding complaints or conjecture. ...Reproducible Bug reports should contain: The simplest steps to reproduce the issue, or... A failing test fixture for the bug. ...Specific Only publish one bug per ...


1

Sounds like a pretty awful situation. Below is my suggestions, First is the suggestion you gave, Secondly you could add a label field and that way at least your users get some autocomplete functionality that might alleviate some of the pain Thirdly you could add a multi-select, whereby you could always add version numbers and manage that yourself.


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


1

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


1

Let's step back a moment and try to look at this from a different perspective. If your team is using a defect tracking database to track bug backlog, then we should agree that the primary purpose of the defect tracking database is to triage new bugs/work as it comes in manage the 'triaged' backlog of bugs/work (assign, prioritize, etc the work) You ...


1

My 5 cents Blocker: The defect affects critical functionality or critical data. It does not have a workaround. Example: Cannot login, cannot upload data, Critical: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: All exceptions, security bugs Minor: The defect affects minor ...


1

I assume you asking because your bug tool supports both severity and priority. If that is true, you might check the tool's documentation. Whether or not to fix a bug is a function of multiple variables, e.g. how hard it might be to fix the bug, how often the bug will occur, and how detrimental the bug will be to the user when it occurs. It can be hard to ...



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