Tag Info

Hot answers tagged

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

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

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

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


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

First, I would like to say that often just taking care of exception is enough. Maybe it's a forgotten corner case (sort a list, but forget it might be empty). Of course you know better when you can trust the developers to make sure that fix is correct. Then to your questions: It would be really nice to have the steps in each bug. It would be even better ...


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


3

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

Issue Reports (Bug Reports) are one of the main communication methods that QAers use. You are creating a statement to your stakeholders - "I have found what I think is a problem, and here's my clear explanation of what it is and how you can see it too. Please look into this". Understand the Audience for the Report It's important to know who is going to ...


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

In what problems they can be useful? cURL's output is the HTTP response, so I think they're equivalent. You might choose to capture the output with cURL if capturing via the browser requires a lot of typing and clicking. How cURL command is better from simple URL or JSON request to reproduce the issue? Did cURL help you isolate any defect or ...


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

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


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


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

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

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

A few thoughts to add to the suggestions others have made: Reproduction matters: Wherever possible I try to reproduce any customer-reported issues because there may be other problems involved that the customer didn't report - especially if the bug report itself contains only a stack dump. It might be that this scenario occurs only if a particular ...


1

It's possible the bug writers aren't collecting the right information because they don't understand what to include and when to include it. Common mistake for people who think writing bug reports is easy but don't understand the elements of a good bug report. As it happens I just wrote an article on How to Write a Good Bug Report. In the article I tried to ...


1

I like to think of "bugs" as having a three-part anatomy: Failure. An observed difference between the results that the system produces and the results we want it to produce. Fault. The error in the system that, under certain conditions, produces a failure. Conditions. The conditions under which the fault leads to a failure. Of these three pieces, the one ...



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