Re: BUG or FEATURE


dumitru.corobceanu@xxxxxxxxx wrote:
How you decide if this is a bug or a feature. Of course, it's easy
when you get application crash or program does not follow the
specification - but what do you do when is about all small things that
makes program look /feel /work better /easier.
In case it's a company product for sale you can get a lot of
arguments, as it is described in "An Introduction to Scenario
Testing" by Cem Kaner, to make the product clean and nice - but what
if you were hired just for "do this".

Having a set of specification the product is created. Now, when it
comes to testing and reporting issues how you categorize "this is a
bug" and "this is a feature"
For example you have an application that manage OBJECTS and you have a
feature were you can select and delete all of them. No confirmation
message, is this a bug or a feature that needs to be implemented.
I've been arguing on this kind of stuff (small basics issues
/functionalities that are not described in specs) with developers on
many projects for to long. For the above example they'll say "there
is no message request in specification" and they are right there
isn't.

I remember last year was a thread width kind of the same problem (an
existing feature that was not requested), but in that case, the feature
was already implemented. In this case, I ask about the stuff that is
not done yet and solving these issues will take time which of course
will delay the product release.

What is the solution? Test only using specs as a check list and ignore
all that is bothering me. I couldn't find in any (by any I mean IEEE
and ISO) standards that will describe exactly and very detailed quality
demands of a software product.
Another solution would be to create an internal software quality
demands standard that would be approved by the management. But this is
very expensive solution; it will take a lot of time since this would
have to be adjusted for every project.

The great thing about a question like this is that it gets us out of
the realm of specific software testing techniques and into philosophy.

I've found that I am the happiest about my work, and the relationship
of my work to the rest of my life, when I assume that I've been hired
by a company to advocate for the end user. What would make the end
user's experience with the company's product better? What would the
end user prefer to see as the company's priorities in either
implementing new features or fixing existing bugs?

Whether the company completely agrees with my opinions is another
issue.

I've learned to care enough to keep reporting problems with enough
detail and supporting argument to make it clear what I'm talking about.
But I've learned to not care so much that I take it as a personal
assault every time the project manager decides not to fix immediately
something that I've reported.

Have you ever read "Zen and the Art of Motorcycle Maintenance"? I'm
not sure whether it would resonate with you. It is a (rather
watered-down and somewhat muddled) study of the search for quality,
against the backgroup of the American West and a complex and disturbed
narrator's introspections. Even with all its problems, though, it's a
great book to read as background material for a career in software QA.
One idea I like to pull out of the book and talk about is that being a
quality advocate is a lot like being a clergyman. You have some
obligations to the people you work for, in terms of how you arrange the
details of your work. But you have higher obligations as well. When
these obligations conflict, you have a duty to follow the higher
obligation and try to make it work.

I think a congregation understands this conflict of obligations, when
they hire a clergyman, much better than a software company does when
they hire a quality advocate. So you'll run into this conflict of
obligations all the time. Think to yourself, "how much is it worth
fighting over this issue?" and act accordingly.

At least this strategy has worked for me. I've been in this field
quite a while and it hasn't killed me yet.

--JMike
p.s. One specific conclusion to draw from this is that, if you find
that the way the company is having you work is too restrictive, is to
gently push for change that allows you to express end-user problems
more effectively. In the above case, if you find that the explicit
specification is too shallow to really capture the whole quality story,
keep on filing bugs that are against the implicit specification or
against the specification that you wish were in place. Let things sort
themselves out after that. You and your company will learn a lot from
the experience.

.

Relevant Pages

  • Re: split line removal
    ... all new feature developement until long standing bugs are fixed. ... bug free and never work exactly the way the you want it to. ... quality of the product. ... There are certainly plenty of marketing types that would like ...
    (comp.cad.solidworks)
  • Re: PID controllers
    ... Lots of electronic items are made in China these days and the quality ... What isn't made in China? ... few examples from the industrial temperature controller market: ... Some of the advanced feature are not needed to get a closer ...
    (alt.coffee)
  • Re: Number of genes as a complexity measure
    ... It is a *subjective* feature. ... In my example I was using female physical beauty. ... males are later shown a photograph of Susie, they will say, "that's ... synonyms for quality are "property, character, attribute", which mean ...
    (talk.origins)
  • Re: Need Help with the Boundary Surface Tool
    ... The feature cannot be created at all. ... Loft can't even be created with c2 on the profiles. ... Boundary works (except, as you mention below when internal control curves are needed), and many situations where boundary doesn't work. ... edges in order to attain a better quality surface. ...
    (comp.cad.solidworks)
  • Re: DAB quality (or not)
    ... > enough reason to provide lower audio quality on DAB than you get on FM, ... It would be interesting to have another survey asking which feature ... > digital radio, and by far the most attractive feature was CD-quality ...
    (uk.tech.broadcast)