Comments on: Assigning Priority to Bugs

By: Tim Hall

Tim Hall — Mon, 27 May 2013 15:22:20 +0000

I like that rule to prevent abuse a *lot*!

By: John P.

John P. — Mon, 27 May 2013 12:30:55 +0000

I recall an interesting approcah to priorities I saw once. An order could be given a “red” priority, which meant “drop everything else and do it now”. To stop it being abused, they ruled that the salesman who was responsible for the order had to stay with it all the time it was on the shop floor – on the basis that if the order was that important, then it deserved the salesman’s full attention. It worked well IIRC.

By: Michael Orton

Michael Orton — Fri, 24 May 2013 14:49:54 +0000

The users here used to put every bug down as priority 1. They were living in “the old days” when there were 13 people in the team. I simply explained that they now had one and a half people to work on the fixes and if they simply stuck everything in the top priority then we would choose which of those we would work on. Asking questions along the lines of “how much difference does this make to revenue?” helped, but really what they needed to know was that the priority setting was for their benefit rather than ours.

By: John P

John P — Fri, 24 May 2013 14:25:43 +0000

One of our customers simply ignores the low, medium & high priorities and just logs EVERYTHING as critical. Even the one that said the web address on the printed statement must be underlined. Why? Because that’s what it looked like when they printed the design they had made in Excel ….

By: Tim Hall

Tim Hall — Fri, 24 May 2013 12:47:26 +0000

The difference between a bug and a change request is highly subjective, and nothing good ever comes from a bureaucratic approach that places too much emphasis on that difference.

I once worked in an environment where developers’ performance appraisals (and hence bonuses) depended on the number of bugs found in their code. If there’s one thing more likely to politicise the entire fault logging process and get in the way of actually fixing issues…

By: Michael Orton

Michael Orton — Fri, 24 May 2013 11:36:40 +0000

We used to get a lot of bug reports which we would send back to the users and ask them to re-raise them a Change Requests.

To qualify as a bug the application must be performing at variance to its specification. If the business requirement changes then the fact that the code no longer meets the requirement is not a bug. The snag is that our department pays for time spent fixing bugs, but the user department has to fund Change Requests. Therefore it is in the users’ interest to raise everything as a bug.

This only matters at middle management levels, it’s all internal “funny money”, but when this application is outsourced next year the users will have to learn quickly as they will suddenly have to pay real money for their CRs and the IT team will bill everything they can because they need that real money.

By: Tim Hall

Tim Hall — Thu, 23 May 2013 20:28:45 +0000

A lot of the bugs that don’t get fixed but cause trouble further down the line are edge-cases that turn out not to be as obscure as first thought.

Spend a whole day earlier this week tracking down and isolating a bug that caused a wrong value in a report, then writing up a detailed bug report describing the problem.

By: Michael Orton

Michael Orton — Thu, 23 May 2013 20:15:40 +0000

It is now a while since we were in full scale development mode, but our bugs were rated 1 to 4, where 1 was “it doesn’t work” and 4 was “this text is the wrong colour”. By the last six months we were at 1: “it’s going to be fixed” 2 to 4 “it’s not going to be fixed”, then we sent the priority 1 bugs to the prioritisation meeting. The prioritisation meeting ended up asking “does this bug impact on the validity of the main exported file?” and only bugs which invalidated that file were fixed. A valid file was eventually sent on the due date, but the due date was extended a few months as so many other teams didn’t have their files ready to exchange.
Of course that was last year. Now we have cleared all the 2 and 3 level faults and many of the level 4′s. The application is due to be replaced next year, so I doubt there will be many more releases.

By: Jokin

Jokin — Thu, 23 May 2013 11:20:27 +0000

We use the word ‘Bug’ for all bugs, deviations, misunderstandings, fluctuation of reality… whatever, just bug.
We have a queue of bugs, 20 bugs with open status right now. We have 5 developers in our company, every week one of them has the support role, he deals with troubles from production and fixes bugs from the list, the support role iterates so all of them are aware of production pains and about existing bugs.

And that’s it.

As the tester over here, I do believe in what Antony Marcano (http://antonymarcano.com/blog/) once said about bug logs being a hidden technical debth backlog.

We could go faster, if every week this support dev was doing new features, but then we would not be doing better.