Recently i came across below article by Jean Baptiste , he works in Google ( AOSP, Android Open Source Project ) .
https://plus.google.com/112218872649456413744/posts/XQXX63yfVin
Which says :
===============================================================================================
When prioritizing bugs, the simplest criteria are the easiest ones to apply. I've seen organizations that needed multiple full-page arrays of rules about how a bug was supposed to be prioritized. I need at most 2 questions to determine the priority of a bug:
-Is this bug blocking another engineer right now? If the answer is "yes", this bug should be fixed immediately. If not, skip to the next question.
-If this was the only bug left, would we delay the release, or would we ship anyway? If the answer is "ship anyway", the bug isn't worth fixing for this release, and should be put as far out of sight as possible. Most probably, such bugs will never get fixed, as there'll almost always be more important tasks to handle.
In the end, there are only 3 possible bug priorities: "fix right now", "fix before shipping", and "don't bother". Anything that tries to be more precise adds some unnecessary stress and overhead.
================================================================================================
So according to him we have three priorities
1) P1 - Fix right now ( Blocker , Critical )
2) P2 - Fix before shipping ( Major, Normal)
3) P3 - Don't Bother ( Minor, Trivial , Enhancement )
Well he may be right , in terms of meeting deadlines and shipping out the product. But i have seen in many companies, a small issue when it is reported by internal team it is treated in "Don't Bother" category and no body fixes it. But when the same bug is reported by customers it becomes high priority bugs.
I do not have problem with P1 and P2 which is to be given high priority, but what about P3 bugs ? Do we just ignore them ? I think "No".
These are the bugs which can be like :
1) Spelling mistakes
2) Menu not proper
3) WEB/CLI command Error message not proper.
4) A new feature request.
5) When you do something specific "junk" values are displayed.
6) Some feature is not properly named, eg "DHCP Server" feature is named as "DHCP" which may create confusion whether the feature is DHCP SERVER, CLIENT or RELAY.
7) Addtional note/comments to be added in WEB/CLI for users to use features effectively.
8) Specific Browsers issues.
9) Something like "add" option is present but "delete" option is not present.
10) Some extra feature is added which is not valid for that product line.
I think these bugs are to be fixed, even if they seem small and trivial or are just enhancements. Again it all depend on deadlines and shipping date, but these are the bugs which makes product usable from customer point of view.
The testing can be done from different view points but the testing which is done keeping "Customers" in mind will always succeed. How customer will configure these features, how he/she will try to use them, how they will deploy them. In this process even if "small issues" comes it should be fixed to enhance the customer experience.
If you are saying that as a developer "i don't care" about "Speeling mitsakes" and let the product ship with it as it not "blokcing" other "Enginer" or it is not delaying the "sheeping" time,
I Disagree.
YMMV. (Your Mileage May Vary)
https://plus.google.com/112218872649456413744/posts/XQXX63yfVin
Which says :
===============================================================================================
When prioritizing bugs, the simplest criteria are the easiest ones to apply. I've seen organizations that needed multiple full-page arrays of rules about how a bug was supposed to be prioritized. I need at most 2 questions to determine the priority of a bug:
-Is this bug blocking another engineer right now? If the answer is "yes", this bug should be fixed immediately. If not, skip to the next question.
-If this was the only bug left, would we delay the release, or would we ship anyway? If the answer is "ship anyway", the bug isn't worth fixing for this release, and should be put as far out of sight as possible. Most probably, such bugs will never get fixed, as there'll almost always be more important tasks to handle.
In the end, there are only 3 possible bug priorities: "fix right now", "fix before shipping", and "don't bother". Anything that tries to be more precise adds some unnecessary stress and overhead.
================================================================================================
So according to him we have three priorities
1) P1 - Fix right now ( Blocker , Critical )
2) P2 - Fix before shipping ( Major, Normal)
3) P3 - Don't Bother ( Minor, Trivial , Enhancement )
Well he may be right , in terms of meeting deadlines and shipping out the product. But i have seen in many companies, a small issue when it is reported by internal team it is treated in "Don't Bother" category and no body fixes it. But when the same bug is reported by customers it becomes high priority bugs.
I do not have problem with P1 and P2 which is to be given high priority, but what about P3 bugs ? Do we just ignore them ? I think "No".
These are the bugs which can be like :
1) Spelling mistakes
2) Menu not proper
3) WEB/CLI command Error message not proper.
4) A new feature request.
5) When you do something specific "junk" values are displayed.
6) Some feature is not properly named, eg "DHCP Server" feature is named as "DHCP" which may create confusion whether the feature is DHCP SERVER, CLIENT or RELAY.
7) Addtional note/comments to be added in WEB/CLI for users to use features effectively.
8) Specific Browsers issues.
9) Something like "add" option is present but "delete" option is not present.
10) Some extra feature is added which is not valid for that product line.
I think these bugs are to be fixed, even if they seem small and trivial or are just enhancements. Again it all depend on deadlines and shipping date, but these are the bugs which makes product usable from customer point of view.
The testing can be done from different view points but the testing which is done keeping "Customers" in mind will always succeed. How customer will configure these features, how he/she will try to use them, how they will deploy them. In this process even if "small issues" comes it should be fixed to enhance the customer experience.
If you are saying that as a developer "i don't care" about "Speeling mitsakes" and let the product ship with it as it not "blokcing" other "Enginer" or it is not delaying the "sheeping" time,
I Disagree.
YMMV. (Your Mileage May Vary)
