How to determine bug severity level?
ambassador at fourthworld.com
Fri Jun 22 00:25:59 CDT 2007
Michael Binder wrote:
> For example: IF you have a list field set to allow multiple contiguous
> selected lines, AND you have not incorporated Ken Ray's workaround,
> THEN you have at least a cosmetic bug. If you then use the
> 'selectedlines' function to doSomething with the hilited lines, then
> you have a serious bug. (because the lines returned by the function are
> not the same as the hilited lines that the user sees).
I think I must have misunderstood something early on. When I ran the
recipe you'd posted I found that the hilitedLines always returned the
expected value, and only the old legacy HC option (the selectedLines)
fails to account for the discontiguous selection.
This was the recipe given:
> To demonstrate:
> 1) Create a new main stack.
> 2) Drag onto it a default scrolling list field from the tool pallete.
> 3) Add 5 more lines of text (choices 4-8).
> 4) Make the field tall enough so that you can see all 8 lines.
> 5) Set the multipleHilites of the field to true.
> 6) choose browse tool
> 7) select the first 3 lines of the list field
> 8) Click somewhere on the card so the field loses focus
> 9) Hold the shift key down and click on line 6
When I do that I find the hilitedLines consistenly gives me the answer
What did I miss?
> So, how would you rate this bug?
I'm with the rest of the gang: if a bug loses data or reports bad data
(not sure which is worse) it gets "Critical"; if it's holding up an app
from shipping it gets "Blocker".
If anyone on the team disagrees they'll tell you when they change the
severity, but at that point at least you know you have their attention.
I think it's wise to exercise prudence when using those two severity
ratings, but when warranted it would be a disservice to both RunRev and
their customers not to.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode