Comments on: Bug Fixing Report http://www.murraytwins.com/blog/?p=37 Personal log, Brian Murray Fri, 24 May 2013 21:45:28 +0000 http://wordpress.org/?v=2.2.2 By: Brian Murray http://www.murraytwins.com/blog/?p=37#comment-3538 Brian Murray Thu, 12 Mar 2009 22:45:35 +0000 http://www.murraytwins.com/blog/?p=37#comment-3538 The script is a part of the ubuntu-qa-tools project on Launchpad. The script is a part of the ubuntu-qa-tools project on Launchpad.

]]> By: Troy James Sobotka http://www.murraytwins.com/blog/?p=37#comment-3481 Troy James Sobotka Thu, 05 Mar 2009 22:59:49 +0000 http://www.murraytwins.com/blog/?p=37#comment-3481 Many years ago, before I had worked in the video game industry, I served some time as an entry level quality assurance type at the bigwig video game company. The way those types of firms deal with QA is an exercise in predatory precision. Their teams are extremely effective and deal with bugs and QA as though they were clinical surgeons - everything from bug formatting and database entry is all methodical. Mind you this is literally a decade ago and I can only assume their approach has become even more strict. This is fascinating stuff. I wonder if there is a way to put some heuristics into a script and pull out interesting information automatically that isn't apparent without a set of human eyes? Many years ago, before I had worked in the video game industry, I served some time as an entry level quality assurance type at the bigwig video game company.

The way those types of firms deal with QA is an exercise in predatory precision. Their teams are extremely effective and deal with bugs and QA as though they were clinical surgeons - everything from bug formatting and database entry is all methodical. Mind you this is literally a decade ago and I can only assume their approach has become even more strict.

This is fascinating stuff.

I wonder if there is a way to put some heuristics into a script and pull out interesting information automatically that isn’t apparent without a set of human eyes?

]]> By: Jef Spaleta http://www.murraytwins.com/blog/?p=37#comment-3479 Jef Spaleta Thu, 05 Mar 2009 16:59:10 +0000 http://www.murraytwins.com/blog/?p=37#comment-3479 Is the script publicly available and available for download? Is the script publicly available and available for download?

]]> By: Brian Murray http://www.murraytwins.com/blog/?p=37#comment-3478 Brian Murray Thu, 05 Mar 2009 16:27:23 +0000 http://www.murraytwins.com/blog/?p=37#comment-3478 I actually used your hacky graph script as a starting point for working with the changes mailing list, so thank you! The grey rows indicate that the bug is tagged with a regression- tag whether, it be regression-potential or regression-release. I'll try experimenting with the bug's creation date and see what that looks like. I actually used your hacky graph script as a starting point for working with the changes mailing list, so thank you!

The grey rows indicate that the bug is tagged with a regression- tag whether, it be regression-potential or regression-release.

I’ll try experimenting with the bug’s creation date and see what that looks like.

]]> By: Colin Watson http://www.murraytwins.com/blog/?p=37#comment-3465 Colin Watson Thu, 05 Mar 2009 09:54:16 +0000 http://www.murraytwins.com/blog/?p=37#comment-3465 This is great, thanks! One other useful measure would be rate of bug-fixing over time. I started on a <a href="http://people.ubuntu.com/~cjwatson/bugfix-history/" rel="nofollow">hacky graph</a> for this but haven't been keeping it up to date. What do the grey rows mean? The "days to fix" tends to not make a lot of sense in cases where the bug <em>task</em> was created much more recently than the bug itself. This happens when you notice that a bug is filed in the wrong place, and reassign and fix it more or less in one go, which at least for me is a fairly common kind of action. Perhaps it would make sense to consider only date_created on the bug rather than the bug_task? This is great, thanks! One other useful measure would be rate of bug-fixing over time. I started on a hacky graph for this but haven’t been keeping it up to date.

What do the grey rows mean?

The “days to fix” tends to not make a lot of sense in cases where the bug task was created much more recently than the bug itself. This happens when you notice that a bug is filed in the wrong place, and reassign and fix it more or less in one go, which at least for me is a fairly common kind of action. Perhaps it would make sense to consider only date_created on the bug rather than the bug_task?

]]>