Idea Details

Define the difference between a Defect and Enhancement

Last activity 05-29-2019 11:22 PM
Anon Anon's profile image
04-02-2015 11:40 AM

I would like to see the term(s) bug and enhancement clearly defined. This should then be shared with the support and user community. All to often I am told to submit an "idea" because of some seemingly?arbitrary mandate that seems to state to support folks that aside from completely obvious bugs, tell the customer to submit an idea.?


Examples of items that I don't feel I as a customer should have to submit for a vote:

All probe GUI's ?to fundamentally behave the same (being able to set the log file, rename profiles, message pool manager)?
Security issues/flaws -not ideas
Reverting back the old working functionality - not an idea
Not overwriting old probe defaults with new one it don't want - not an idea
Please stop adding new alerts that I don't want and cant configure - not an idea


Defining what is considered a bug and what is considered an enhancement would help everyone


05-30-2018 08:38 AM

We completely agree with Hub_KL. Removing existing functionality is extremely hard on long standing customers.



05-28-2018 08:18 AM


I would like to comment on this one:

"Reverting back the old working functionality - This depends on what was planned for the product by the Product team. A decision may have been made to remove the old functionality..."


Honestly I have no idea how a software provider could say something like this. You can't just remove a functionality as people may have put in a focal point of the operations. Many of us have external cusotmers and relay on functionality already provided  by the app. If CA removes a function becouse "product management decided to do so" you put us in very, very  difficult situation as we cannot deliver product for our customers.  This way of thinking undermines trust we have in stability of product development...


10-18-2016 06:47 PM

Posting an idea on the communities is like the tools is working as it should work but you want to modify it in a way according to your infrastructure. However, according to the techincal people who has worked on many tools, it is a bug and defect in the existing tool and need to look into the issue.


If we will post an idea then may be someone else would able to use the modified probes after re-configurations.


But i agree that there are some probes of older versions which works fine if we compare with the new version of probe. So honestly we don't know if it is kind of moving forward on some roadmap or going backward.

08-24-2016 08:35 AM

What I see here is the need to further define the difference between an "Enhancement/Feature Request" and a "Usability bug". While an aspect of the software (any software) may "Function as Designed" that does not necessarily mean it is functioning well or efficiently.


I believe that some of the points being raised by customers is more Usability concerns and not necessarily a Feature Enhancement Request.


Seems that there should be a third option here - Usability Enhancement - which is neither a traditional "bug" nor a feature request.

08-17-2015 09:28 AM

I too agree with the change from ER to Idea is a good solid one.   Promotes more sharing of experiences between the customers of CA.    However I also agree that a defect is a defect - not an idea to be voted and determined for a fix.    As a customer if we are looking to provide a service to our customers and the tools do not offer it in their current release ~ Idea's are solid ways to determine value add.   However when code is broken and not providing what the tool claims to support then that is a Defect and should be handled differently.

08-05-2015 09:32 AM

I would agree with you.  A definition that all understand including support would be the best.  Our experience has been support will help if you do not know how to do something or if you configured something incorrectly.  If however it is something which needs to go to development whether it is because it is a feature request or because something is not working properly as it is documented, we are told to enter an "idea".  That is why users are upset.  We do understand that not everyone wants everything to be the same.


Here we have been told to put in an idea for a probe which was returning an incorrect value based on documentation, best practices, support's own feelings, and our knowledge.  The problem was later fixed but we should never had been told to put in an idea.  Everyone acknowledged it was a bug which needed to be fixed.  Why were customers supposed to vote on fixing a bug?  That was a waste of everyone's time.


Someone else mentioned that in the ticketing system you can enter a "feature request".  This used to be used by Nimsoft.  It is not used by CA.  I suggest that they either remove the choice from the drop down or assign a CA person to turn the "feature request" into "ideas" for customers rather than telling customers who are using the CA ticketing system to do it themselves.

08-05-2015 04:26 AM

"Defining what is considered a bug and what is considered an enhancement would help everyone": Yes, it is! And that's the reason why I've voted for this.

To vote for it should not mean, that we no longer want to vote for "bug fixes". Why?

Probably many of us know bugs (or unlucky designs) that accompany us for years (or which have accompanied us for a long time).

And voting for  "Fix this bug" is a way to say "Come on, CA, here is more than one customer, who needs this fix."

Sometimes  this is necessary and it's good, that we have this possibility.

08-04-2015 12:31 PM

Yesterday I reported that billing probe (that we are required to use) is double counting our devices, thus double billing. The reason for this is by default the probe's database stores 1 months worth of data. The probe also determines uniqueness by a combination of name/source/origin. So for if example you had your origin misnamed or a robot running under a different hub in an HA scenario that month, systems get counted twice.


Per support:


"It takes a snapshot daily and at the end of the month, the billing probe builds a report for all the daily snapshots it finds for the previous month. If a robot gets moved around, it could show up under different hubs or origins every time the usage metering runs, so when the billing probe puts the report together, you get the same system multiple times. I would recommend creating an IDEA to be able to set usage metering to run once at the end of the month or to allow you to clean the database out on a time period of less then a month. "


So "working as designed" apparently is me performing the following every month, just I can not be (even more) over charged for the product.


You could reset the usage_metering database manaully, then rerun it.


Turn off the usage_metering probe, delete these 2 files in ...\Nimsoft\probes\service\usage_metering

usage_metering.h2.db and usage_metering.trace.db

then run the Ad Hoc Device metering Scan ( scan now).


So what's my idea then "Billing Probe to not over charge me as a customer"

08-04-2015 11:46 AM

In theory, I agree with you about the Ideas in Communities being an improvement.  In reality, most customers make limited use of CA communities, and even those who are active here, few will dig through all of the Ideas to ensure that they have voted on all of the ones impacting them.  Instead, they'll typically vote on ones that they see on the first page that look useful.  From what I've seen, the default sort seems to be based on score, so Ideas that will get the most votes are going to be the ones that . . . have the most votes.


And, that still doesn't address the issue where a customer runs into a problem that most people would call a bug, but they are then told that the system is "working as designed", because someone designed it to be broken.  Customers are then left having to submit their bug as a feature request and hope that it might get enough attention after a year or two to get noticed, at which point it might show up in the product after another year or two.

07-31-2015 04:52 AM

here is another good example.

Someone designed the range for Event codes in Spectrum up to 0xffffffff.

Another one designed that the Spectrum Rest API can handle Event Codes only up to 0x7fffffff.

(...Engineering confirmed this is FAD for the RestAPI...)


In order to get a common design an Idea has to be raised:

RESTful API supports 64bit data values

07-30-2015 12:12 PM

I should have clarified my comment was on why CA are using Ideas as the ER process.

Was really in reply to "SATipton 02-Apr-2015 16:20" comment.


In any case I saw the Idea and I really can't comment on another colleague's advice also I don't work on that product so can't advise.

07-30-2015 11:56 AM

So using this as an example:


Idea or defect:


Fix LDAP integration

07-30-2015 06:38 AM

Hi Everyone


I work for CA...


Noted the comments about the process of CA using Ideas in Communities for Product Enhancement Requests (ER).


Just wanted to say under the old process the ER was only visible by the client who created it.


Raising an Idea means all CA Customers can see it and vote on it.


This means CA has greater visibility in seeing what Most clients actually want in the next release, what has more impact....


I hope this makes sense.


Kind Regards


Barbara Marchant

07-30-2015 04:04 AM

I also think that if a bug is found, we shouldn't have to upvote it, If there is something wrong with a product and it is not working (or partially working), then CA should add it to the list of bugs to fix. This would definitely be a big plus for CA to show it's reactive to bugs.


Currently there are bugs which should have been fixed ages ago. I would prefer for a product to be bug free before any improvements are made. This is best for both CA and the customer.

07-29-2015 08:43 PM

I edited the idea and assigned it across all CA products of this Community.

07-29-2015 08:41 PM

I will try to comment on this topic as a Support Engineer. Simply put, a bug or a defect in the software is any function of behavior of the product that is not working as designed by the Product team. Taking bvloch's comments as an example:


  • Security issues/flaws - this should be a defect because no product should be designed to be vulnerable due security flaws.
  • Reverting back the old working functionality - This depends on what was planned for the product by the Product team. A decision may have been made to remove the old functionality in favor of a new one, some products may have a different development approach to always retain the old functionality.


The other two topics if they are part of the design I believe that we should at least give the customer the option to override these settings or behavior, but this would not necessarily make these items as bugs. That said, the word BUG from the dictionary can in fact give margin for many interpretations:


BUG: A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

05-13-2015 12:39 PM



Can you edit the Idea and assign it to every possible CA product?  This is definitely not just a UIM/Nimsoft issue.

05-13-2015 12:14 PM

Big agreement here.


I recently had a CA Spectrum support case opened because IP addresses weren't showing up on interfaces on Cisco Nexus 7k's and Cisco Catalyst 6500's.  Both of these are listed as fully supported devices, and showing me the IP configured on the interface in the interfaces tab is pretty basic functionality.  We discovered that the reason was because these interfaces are configured as part of a VRF (and increasingly common configuration for us and others).


Support came back and told us that it was working as designed, and it wasn't a bug.  If we wanted it "fixed", we had add a feature idea on the Communities page and hope that someone might look at it someday.


Now, I understand that from a developer perspective, you can make the argument that the code is working as written, and that it isn't a code bug.  Fine.  But, when I can't see an IP in Spectrum on a supported device, from a user perspective, that is a bug.  The function is broken for me.


Pushing these kinds of issues to the Community "ideas" gives customers the feeling of being ignored, and leaves you with the concern that getting your bug fixed "idea" implemented is at the whim of luck and chance.

04-02-2015 07:20 PM

+1. When opening a new case we can set the ticket type to "Feature Request" so why do I have to rewrite everything in the ideas section?

04-02-2015 07:20 PM

We so agree with this.? The entire "idea" system is silly.? This is something a start-up in someone's garage would do.? This is NOT what an company which is supposedly providing enterprise class monitoring would do.

04-02-2015 07:19 PM

I just had an issue with LDAP not working correctly in version 7.5 when for years it had been working in earlier version. I was told to submit an idea. So in other words, it's broke and just live with it.

04-02-2015 07:19 PM