| || |
What are the defects introduced during Bug Fixes Called. Are they just bugs or have a special name?
Some of the polite memebrs prefer to use phrase "enhancement" even for bugs. They never realize that bug and enhancement are not the same but to save their face they never accept a bug is bug unless someone wastes a lot of time and resources to show them that they are using wrong terminology.
Less polite but practical members use phrase "Incidences" for bugs under fix. They accept that bug need to be fixed at appropriate location in the code base. Thereby they are more closer to reality rather than all polite jargon which may not always be best for corporate environment.
I suggest you fall for "Incidence" paradigm rather than arguing with old polite memebrs that they are wasting their time to realise that bug and enhancement are not the same terms. Just use and propagate "Incidence" term for best practices at your current surroundings.
In my undestanding, the difference between bug and enhancement is huge. It's a difference of money (effort): the time spent to fix bugs is considered rework (which increased costs for the product) for same functionalities, so it deccrease the efficiency of the activity.Time spent for enhancement are also increses costs, but for new functionality, so doen't decrease the efficiency.
To say "the product doesn't work as it required" is not the same with "the product doesn't work this way because it was not required".
I saw the term "issue" used in different ways. I tryed to impose the use of this term for two different things: - for production incidents. This type of incident could have different reasons: it could be an operation problem, it could be a hardware failure or it could be caused by a "bug". Based on the analysis of incident a bug could be opened.
The second approach is to use this term by the testing team for every new problem identified. Only after the analysis stage this should be categorized as bug or enhancement.
One frequent "mistake" I saw it's the use of "enhancement" for "requirements bugs". There is many times a grey area. If a customer need/requirements was not translated accuratelly into requirements (or specification) the development usually categorize this as an enhancement. It's depend very much on the organization: there are business analists involved, or requirements are sent directly from the cutomer to development. There are requirements reviews and requirements management process ?
Partially this analysis may be valid in some cases but requirement reviews and requirement management processes are supposed to be short-term processes unless the product itself is evolving and moving towards saturation.
So I would say that one who is following for longer than expected may loose longer than usual. Standard product lifecycle dictates that all followups and requirement reviews beyond a certain specified time/deadline prove to be a wastage. Infact often most practical solution is worked out by dropping the features not feasible and ceasing the requirements. Just be careful that you are able to have good cost-benefit ratio if you are following any typical requirement.
While I appreciate the discussion/responses from Daniel and RKS, I think you both overlook the original question:
<font size="2" face="Verdana, Arial, Helvetica">Regardless of when it is introduced, it is a bug/defect/issue (whatever you want to call it [img]images/icons/smile.gif[/img] ) and should likely be addressed.
What are the defects introduced during Bug Fixes Called
Now the culture of your company will determine if it becomes an "enhancement" - where I work this term refers to something that is:
</font><ul type="square">[*]<font size="2" face="Verdana, Arial, Helvetica">Out of scope (i.e. not defined in the requirements)</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Minor problem that cannot be fixed under current time constraints and therefore deferred to the next release</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Major problem that is too complicated to resolve in current time constraints but where a viable work around is available until next release</font>[/list]<font size="2" face="Verdana, Arial, Helvetica">
Also the Business Unit must agree to delay fixes before they can be designated "enhancements".
[ 02-19-2004, 08:01 AM: Message edited by: swt88 ]
A defect which is the result of the fixing of another defect is commonly referred to as a "regression" error. That is why we do "regression testing", to verify that the fixes did not break anything that previously worked.
[i]...Sound trumpets! Every trumpet in the host! / Sixty thousand, on these words, sound, so high the mountains sound, and the valleys resound.</i] (The Song of Roland)
Thanks Charles. I was looking for the technical term...
If a developer fixed a bug and raised another bug, it is still a bug. If a developer fixed a bug and claimed that's how it should works that is a "feature".
If you find better answer post it here [img]images/icons/smile.gif[/img] I don't if the technical exist for this one.
IBM Certified Database Administrator
Sun Certified Java Programmer
Oracle Certified Associate