What Does It Usually Mean for a Feature to be “Supported”?

Question

I'm currently working some testing for a particular area of an application. I had to write some automated tests for a particular feature but due to the circumstances, this was not easy to do. When I asked one of the other testers about it, he mentioned that the same features exist in a sister application our company produces but isn't documented anywhere (end-user documentation or otherwise). He also said that the feature doesn't typically get tested at all in the sister application and isn't usually tested in the application I work on. Apparently this feature isn't heavily used but removing it would require a fair bit of work so the benefit-cost ratio doesn't work out.

All of this has left me with some questions. Other than "The documentation says so" or "We told the client it is", what usually makes a feature "supported" versus an unsupported feature?

Answer 1

what usually makes a feature "supported" versus an unsupported feature?

Commitment by the developer. If some program happens to be able to import XML but the developer doesn't plan to support that feature going forward, users should expect it to break at any moment, or not to work at all. On the other hand, if the developer says that the feature is supported, users can expect that feature to be tested and to work properly. If the feature doesn't work, users can rightly complain that the software doesn't do what the developer says it does.

Answer 2

I usually take "supported" literally: It means the responsible party (programmer/group/company) intends to support users of the feature when they encounter problems with it. Support can be in the form of direct help, debugging, releasing bug fixes, providing documentation, etc. On the other hand, "Unsupported" tends to mean 'it may work, but don't complain to us if something goes wrong.'

Answer 3

Supported can mean anything from, we have full ISOxxxx accreditation for that fully tested feature which all our customers are using - through to - we think an intern worked on that a couple of years ago.

Unsupported can mean anything from, we haven't yet received full ISOxxxx accreditation for that fully tested feature which all our customers are using - through to - we think an intern worked on that a couple of years ago.

Answer 4

A feature is "supported" if the party responsible for the software's overall functionality asserts and takes responsibility for the correct behavior of the software when used in that particular way.

Think of it kind of like a prescription or OTC drug. The maker of that drug designed and intended it to have certain primary effects, targeting a certain "problem" (disease, syndrome, disorder, etc). However, doctors and patients may find that it has certain "side effects" which may actually be desirable. Diphenhydramine (Benadryl) was originally developed and marketed as an antihistamine, combating nasal allergies and other general histamine reactions. It was quickly discovered that it had the side effect of causing drowsiness. That's considered detrimental to a drug intended to be taken during the day, but both not having a runny nose and being drowsy is beneficial to getting a good night's sleep, so the drug began to be included in "PM" formulations of popular painkillers, pretty much solely for the sleep-inducing side effect. It's even in at least one drug that is intended 100% to be a sleep aid (Unisom). Nowadays with the introduction of "non-drowsy" OTC antihistamines, diphenhydramine is almost as commonly used as a sleep aid than as an antihistamine; the major remaining uses of it in its original intent are in children's medicines. In contrast, there are side effects that doctors have seen as beneficial, or diseases that show improvement with the medication, that weren't the drug maker's intent. Until the drug maker goes through the approval process with the FDA for this new use, the drug maker may not market the drug to doctors as being useful for this condition, and does not have any liability for damages as a result of this "off-script" use. Doctors can still prescribe it - they can prescribe pretty much anything for anything - but they carry full liability for any ill effects or other failure.

Software is similar (but without FDA oversight or drowsiness, dry mouth, heart attack, stroke, coma, death or halitosis). The product owner may have designed a piece of software to fill a certain specific need. Users of the software may then find that if you set it up a certain way, it does this other useful thing. The project owner may never have expected that, and in fact may consider it a bug. As such, they may not "support" the software being used in that way; if it fails to perform correctly in that configuration, the user is not entitled to the benefits of any warranty, nor will the developers try to fix the "problem". On the other hand, if that alternate usage is considered beneficial, the programmers may include that functionality, planning for it, testing its correctness and asserting that it will indeed perform correctly when used that way; they now "support" that usage.