On 21.06.2013 13:09, Sub Phil wrote:
Regarding "classification" of bugs (critical, etc.) and bug fixing.
The core question is how to increase the throughput of bug fixing, i.e.
increase the number of fixes?
If one analyse bug reporting process & fixing, it is usually done as
1/ User report bug
2/ Tester try to reproduce it, then
2.1/ confirm or not
2.2/ sets a priority
3/ Some developper will fix it when has time and very othen if feels like
it, instead of developping some new features (s)he likes.
This is a very bad way to handle bug and discourage reporter, tester and
possibly developper. Indeed, often bug are fixed weeks later, not months if
ever and priority are very subjective.
How to improve that?
1/ First by reducing time between bug reporting and fixing and only
delaying fixing when it's too ressource consumming.
Work on it as it is hot reported and user expect to verify the fix.
2/ By notifing bug reporter of current ressources (for instance, red flag
lack ressouce so handles only critical bugs)
How to improve the time between bug reporting and fixing?
By cracking down the problem to its core root.
Irrelevant of the bug seriousness, there are user familliar with bug
reporting and some not.
So the first role of the bug tester is to validate it and have a test
scenario.
When there is a test scenario, then 6 things are often short-circuited, but
would accelerate the bug fixing process.
0/ When lacking time, well how frequent in its USE does the bug appear,
i.e. is it rather of general use or rather specific to some expert user?
1/ Simplify the reproducable bug test case to its core form.
For instance, if it's a spreadsheet.
Are all columns usefull? No, delete the rest.
Are all lines usefull? No, delete the rest.
Is the formating relevant? No, remove it.
Is it file format specific?
Is it language specific?
Etc.
Snif the trail of the bug to find its root.
2/ Narrow down the process involved to generate the bug, in order to
identify the precise component
For example,
In the process to reproduce the bug, are they steps one can omit, what
about changing the order sequence.
3/ If applicable, make a run-time debug run to narrow down which component
of the code has the problem.
See my post on run-time debug & tracing tools.
Try to report something as
Crash when executing line 1234 of file blabla.c
4/ Set a priority according the IMPACT it has one the confidence one has in
the product.
Examples.
* Imagine Calc can't handle CSV files, with semi-colon as delimiter. Well,
annoying, but there are temporary work around.
* Now suppose Calc, take
https://issues.apache.org/ooo/show_bug.cgi?id=119836
Won't you fear to use pivot?
5/ Ideally, make a macro to run the test case.
All good ideas.
I would like to add another one. I am a developer. When I spend time
on fixing bugs then I sometimes wish there where a big list of all open
bugs that are sorted according to importance. I would go down the list
and grab a bug from the top that lies in the area of my expertise
(Impress, UI, Slideshow, Sidebar). Without such a list I have to
prioritize bugs by myself. And if I do that then I use my own judgement
of which bug is important and which is not.
Regards,
Andre
Yours,
Philippe
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
