It's a fact of life that software is developed with limited resources. If you get more bugs than you can fix before the release date, some will have to be postponed. You might use this resolution for bugs that relate to features you're planning to implement in the future, or for bugs that you feel are unlikely to actually happen to real users (for example, crashing on a 10-million-character input in a text box is much more likely to happen in the test lab than in the real world).

If you find yourself using this resolution on serious bugs in core features that are part of what you're marketing for the current release, it's time to stop development and figure out how to adjust the feature set or the release date. Shipping code with known serious bugs is a good way to lose all of your customers.

If you know that you're targeting a bug fix or feature implementation for a particular release, there's an alternative to resolving the bug as postponed: you can just change the Fix For of the case to refer to the appropriate release. That way there's no chance that it will be forgotten. If you resolve the case as postponed, someone has to remember to reenter it into the system at the appropriate time.

0 0

Post a comment