Usually there is a bug tracking system in which the reporter (tester) assignes a severity to the defect, and then a developer leader assigns a priority. Usually the usability issues are not as severe as crashes, for instance, and so are assigned more priority and fixed earlier. On the other hand, the usability/interface issues are postponed to a later phase "when the product is more stable"
Now something about the context. I am talking about a big size commercial application, and I am refering to an alfa version. The product is not officially released, it was already delivered to testing team, but there is a long way to go until it is beta ready (let's say about 6 months.
I think that in this scenario, interface and usability issues should be prioritized above other problems, like crashes or errors, provided that these are not blocking tests and development evolution.
Here are the reasons for this:
-Interface changes like uniformizations, tend to spread to many areas of the aplication, and the cost tends to be high. By fixing this earlier we are reducing the cost of the fix.
-Interface changes are likely to introduce unstability and break the code on many areas, so the sooner these major changes are done, the sooner these new defects can be fixed.
-Incorrect Labels cause confusion: testers and tech writers will have to talk to developers to understand the software, developers will have to do extra work to find, understand and fix things, etc. So this "minor" defect can increase the cost of software while fixing this would be very cheap. (I would include here the names used in the code, whose importance tends to be underestimated by the developers. I which they could count the defects caused by naming issues, and the time spent finding badly named variables, etc...)
Does anyone agree with me on this?
If so, any tips on how can we explain to leaders that "label is confuse" minor defect should be fixed earlier than that uggly "application crash" defect?
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment