0

This might be only a question of definition, but maybe there's a consensus?

Given the situation, software Foobar Plus is under construction, we're not working on an update, but on the first release of it.

Now, a specific feature(A) was implemented;

  • Feature(A) caused a unwanted behavior in feature(B).
  • It has no influence on feature(A), but is caused by it.
  • Feature(B) isn't implemented yet, the behavior got noticed due interpreting debug logs.

The question now is; is this unexpected behavior called a bug, or just a change in feature(B)'s environment?

Edit: This question isn't about blaming anyone but about finding the proper definition for this case.

|improve this question
  • Maybe not a software bug (because not apparent in current implementation), but definitely a design bug. Note a "work-around" in feature (B) could be considered "proper implementation of feature (B)" according to requirements – tofro Jan 28 '17 at 10:46
3

It depends

The meaning of the word "bug" is sometimes informal, sometimes formal, sometimes contentious, even, sometimes, defined by contract. I've worked on projects where we were charged penalties for each and every bug found after a certain date; in a situation like that, the definition is clearly spelled out in the contract.

Avoid the whole argument

If your situation isn't so rigorous, but people are still being contentious, I'd advise avoiding "bug" completely and lean toward using these alternative terms:

An implementation defect is present when expected behavior does not match actual behavior. Behavior can only be "expected" in the presence of a requirement-- no "I just don't like it!" kind of issues are allowed. Implementation defects are caused and resolved by developers.

A design defect is present when behavior matches the design, but the design does not meet the requirements. In other words, a mismapping occured when converting system requirements into derived software requirements. These are caused and resolved by architects or technical business analysts.

A requirements defect is present when behavior matches the requirements but the requirements do not match the mission statement of the application; in other words, there is an error in the traceability mapping between business requirements and system requirements. These are caused and resolved by stakeholders or business analysts. (Note: When these arise, it is important to update documentation and inform QA so they can update their test cases).

A requirements gap is present when a behavior is not inconsistent with stated requirements, but yet seems wrong and is probably something nobody thought of.

In your case, the feature B hasn't been implemented yet, so you do not have an implementation defect. It is probably a design defect or a requirements gap.

|improve this answer
  • Sometimes simple classification will work depending on the fact either the team found it or the user during UAT. – Piotr Gwiazda Jan 28 '17 at 10:34
2

If I understand you right, Feature B works unchanged, but because Feature A exists, the current behaviour of B isn't a good behaviour anymore. So it might be the case that the specification of feature B needs to change.

At one place where I worked they had no bugs, but "Change Requests". Precisely for that reason.

|improve this answer
  • Apparently feature B does not work at all, with or without feature A, because it is not implemented. – T. Verron Jul 30 '15 at 13:28
2

Unwanted or unexpected behaviour almost always starts out life as a bug.

If the code that is in question is required for feature A, then that would necessitate a change request for compatibility with feature B. It then morphs itself into a feature request.

If the code in question is incorrect, poorly implemented or has untested side effects, then it is a bug in feature A. Then it remains a bug. Sure, it may not have originally or noticeably broken feature A - e.g. memory scribblers etc., but it is a bug.

Log the issue, triage, reclassify if needed, assign it, fix it, test it.

|improve this answer
1

It can be both.

If Feature(A) caused some unwanted side-effects by implementation I would call it a bug

If Feature(A) caused some unwanted side-effects by design I would call it a a feature-change

|improve this answer
  • In any case, it is a design anti-pattern I'd say^^. – Sempie Jul 30 '15 at 12:16
  • To extend - if it's caused by the design of the requirement-specification I would go with feature-change no questions asked, but if it's caused by the design of the implementation I'd say it's a bit of a grey area and probably not worth thinking too much about as all the discussion really does is try to find someone to blame rather than fixing the problem :) – cwap Jul 30 '15 at 12:26
0

My definition of a bug is unexpected/non-compliant behavior discovered AFTER a feature was delivered. Anything else means the feature fails the definition of done. Unless it is determined that the feature will be passed because it met the specs and that it will be redefined in a future sprint/delivery.

For the most part if the implementation of a feature breaks another feature in the system, I would say the feature is not done. If the break is discovered after the feature is delivered then I would say it is a bug.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.